# DSE Updates > The public, DSE-authored security and technology knowledge hub from Detection Systems & Engineering. DSE Updates exposes only governed, published DSE posts. It does not accept public submissions, votes, or comments. Time-sensitive facts are tied to named sources; DSE interpretation and recommendations are labeled separately. ## Canonical entry points - [Knowledge hub](https://update.dsesecurity.com/): Human-readable DSE post stream and topic channels. - [Editorial methodology](https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/): Scope, sourcing, review, and limitations. - [Official source register](https://update.dsesecurity.com/sources/): Human-readable provenance directory. - [Source register JSON](https://update.dsesecurity.com/sources.json): Machine-readable primary-source index. - [Public Read API](https://update.dsesecurity.com/api/v1/): Versioned JSON access to published posts. - [OpenAPI description](https://update.dsesecurity.com/api/v1/openapi.json): Machine-readable API operations and schemas. - [RSS feed](https://update.dsesecurity.com/feed/): Recent and meaningfully updated posts. - [JSON Feed](https://update.dsesecurity.com/feed.json): JSON Feed 1.1 representation. - [XML sitemap](https://update.dsesecurity.com/sitemap.xml): Complete canonical HTML inventory. - [Full Markdown corpus](https://update.dsesecurity.com/llms-full.txt): All published DSE posts in one text resource. - [Usage and citation policy](https://update.dsesecurity.com/usage/): Preferred citation and rights boundary. ## DSE channels - [Video Surveillance](https://update.dsesecurity.com/topic/video-surveillance/): HTML channel; [RSS](https://update.dsesecurity.com/topic/video-surveillance/feed/); [JSON Feed](https://update.dsesecurity.com/topic/video-surveillance/feed.json). - [Access Control](https://update.dsesecurity.com/topic/access-control/): HTML channel; [RSS](https://update.dsesecurity.com/topic/access-control/feed/); [JSON Feed](https://update.dsesecurity.com/topic/access-control/feed.json). - [IT](https://update.dsesecurity.com/topic/it/): HTML channel; [RSS](https://update.dsesecurity.com/topic/it/feed/); [JSON Feed](https://update.dsesecurity.com/topic/it/feed.json). - [Microsoft 365 & Identity](https://update.dsesecurity.com/topic/microsoft-365-identity/): HTML channel; [RSS](https://update.dsesecurity.com/topic/microsoft-365-identity/feed/); [JSON Feed](https://update.dsesecurity.com/topic/microsoft-365-identity/feed.json). - [Networks & Infrastructure](https://update.dsesecurity.com/topic/networks-infrastructure/): HTML channel; [RSS](https://update.dsesecurity.com/topic/networks-infrastructure/feed/); [JSON Feed](https://update.dsesecurity.com/topic/networks-infrastructure/feed.json). - [Cybersecurity](https://update.dsesecurity.com/topic/cybersecurity/): HTML channel; [RSS](https://update.dsesecurity.com/topic/cybersecurity/feed/); [JSON Feed](https://update.dsesecurity.com/topic/cybersecurity/feed.json). - [Business Continuity](https://update.dsesecurity.com/topic/business-continuity/): HTML channel; [RSS](https://update.dsesecurity.com/topic/business-continuity/feed/); [JSON Feed](https://update.dsesecurity.com/topic/business-continuity/feed.json). - [DSE World](https://update.dsesecurity.com/topic/dse-world/): HTML channel; [RSS](https://update.dsesecurity.com/topic/dse-world/feed/); [JSON Feed](https://update.dsesecurity.com/topic/dse-world/feed.json). ## Corpus facts - Published DSE posts: 1654 - Topic channels: 8 - Public access does not replace vendor instructions, an environment-specific assessment, or DSE support. - Crawler access does not grant a copyright license. Cite the canonical DSE post and preserve third-party source attribution. This llms.txt file is an optional machine-navigation aid. Canonical HTML, robots.txt, the XML sitemap, feeds, and the API remain the authoritative discovery surfaces. --- # Complete DSE post corpus --- # “ONVIF compatible” is not enough: verify the exact model, firmware, and profile > ONVIF conformance belongs to a specific listed product and firmware or software version. Marketing language, membership, or a related model is not equivalent evidence. - Canonical URL: https://update.dsesecurity.com/updates/verify-onvif-conformance-model-firmware-profile/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:15+00:00 - Modified: 2026-07-19T21:28:15+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 2 minutes ## What you need to know ONVIF conformance belongs to a specific listed product and firmware or software version. Marketing language, membership, or a related model is not equivalent evidence. ## Potentially affected Anyone specifying, purchasing, commissioning, updating, or auditing cameras, recorders, VMS clients, access-control products, analytics services, or other products that claim ONVIF support. ## DSE recommendation Match every required product and installed version to ONVIF’s authoritative registry, inspect its feature documents, and validate the intended multi-vendor workflow. ## Article ## What official conformance means Source fact: ONVIF identifies its Conformant Products database as the authoritative source for determining whether a product is officially conformant and which profiles it supports. Registration follows successful use of the relevant ONVIF test tool and submission of required documents by an ONVIF member manufacturer. Conformance is tied to a specific firmware or software version. It remains valid indefinitely for that registered version, but the installed version must match the database entry. ONVIF also requires each specific model in a family to be tested, registered, and listed individually. A database record can identify related products, but the registry expressly notes that related products have not necessarily been individually tested. Membership and conformance are different. Only qualifying ONVIF members can make conformance claims, yet membership alone does not make every product conformant. Products can use parts of ONVIF specifications without completing the conformance process, but they cannot properly claim ONVIF conformance on that basis. ## Read beyond the profile name ONVIF’s process requires implementation of all mandatory and applicable conditional features for a claimed profile, successful use of its test tools, and submission of a Declaration of Conformance, Feature List, and Interface Guide. A mandatory feature is required for the profile. A conditional feature is required when the product supports that capability, including through a proprietary method. Those documents are therefore more informative than a profile logo alone. Conformance does not certify image quality, analytic accuracy, storage capacity, cybersecurity hardening, availability, or every project-specific integration. It also does not eliminate the need to test a client and device together. A later firmware release may fix vulnerabilities while no longer matching the exact registered record, so both lifecycle and interoperability evidence need to be retained. ## DSE verification checklist DSE recommendation: This is DSE operational synthesis, not an additional ONVIF certification process. - Record manufacturer, full model, hardware revision, installed firmware or software, and product role. - Locate the exact record in the ONVIF database; do not substitute a family name or related-product listing. - Save the profile list, Feature List, Declaration of Conformance, Interface Guide, and test date. - Map mandatory and conditional features to the project’s written requirements. - Flag products whose installed version differs from the listed version and obtain manufacturer guidance. - Bench-test discovery, authentication, configuration, streams, events, metadata, recording, access decisions, and failure recovery as applicable. - Store the evidence with commissioning records and repeat the check before material firmware or client changes. ## Official references - [Conformant Products](https://www.onvif.org/conformant-products/) — ONVIF’s authoritative product and version registry. - [Conformance FAQ](https://www.onvif.org/conformance-faq/) — model, version, mandatory-feature, and conditional-feature boundaries. - [Conformance Process](https://www.onvif.org/profiles/conformance/) — test and document requirements for a claim. ## Primary reference - Name: ONVIF — Conformant Products - Authority: ONVIF - URL: https://www.onvif.org/conformant-products/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: ““ONVIF compatible” is not enough: verify the exact model, firmware, and profile,” DSE Security, https://update.dsesecurity.com/updates/verify-onvif-conformance-model-firmware-profile/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # A privacy operating model for video surveillance based on SIA’s 2025 Code > SIA’s 2025 Code organizes privacy responsibilities around purpose, impact assessment, minimization, accuracy, retention, security, access, transparency, and review. - Canonical URL: https://update.dsesecurity.com/updates/video-surveillance-privacy-operating-model-sia-code/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:39+00:00 - Modified: 2026-07-19T21:28:39+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Video Surveillance - Reading time: 2 minutes ## What you need to know SIA’s 2025 Code organizes privacy responsibilities around purpose, impact assessment, minimization, accuracy, retention, security, access, transparency, and review. ## Potentially affected Organizations that manufacture, design, install, own, operate, host, analyze, share, or support video surveillance and associated analytics or identifying metadata. ## DSE recommendation Create a documented privacy operating model with accountable roles and jurisdiction-specific legal review rather than treating technical configuration as compliance. ## Article ## Responsibilities begin before installation Source fact: SIA’s 2025 Data Privacy Code of Practice separates responsibilities among manufacturers, integrators, and end users. Manufacturers are asked to address secure defaults and upkeep, including patching, vulnerability communication, credential changes, access control, authentication, encryption, cloud-service security, and current hardening guidance. For integrators, SIA places privacy work in design and layout. A privacy impact assessment can identify concerns involving fields of view, analytics, viewing or exclusion zones, authentication, cloud or on-premises architecture, third parties, and contractual responsibilities before installation. End users establish the system’s purpose, justification, and operating scope. SIA describes them as the data controllers who retain ultimate responsibility even when a service provider handles data. ## Principles for ongoing operation The Code recommends a privacy impact assessment that examines how information is collected, used, shared, maintained, and retained. It presents privacy by design, regular review, transparency and notification, purpose limitation, and data minimization as core principles. It also calls for accurate metadata such as location, date, and time, particularly where evidentiary use matters. Storage should last only as long as reasonably necessary or legally required. Access to retained images should be restricted through clear rules stating who can access them, when, and for what purpose. Integrity and confidentiality measures can include digital signatures, watermarking, and encryption in transit and at rest. ## Legal and operational boundary SIA explicitly states that the Code is general information and not legal advice. It does not create a universal retention period, notice format, lawful basis, biometric rule, or sector-specific compliance decision. Requirements vary by jurisdiction, workforce relationship, use case, and the type of people or information captured. ## DSE privacy checklist DSE recommendation: This is DSE operational synthesis and should be completed with qualified counsel for applicable law. - Name the data controller, processors, system owner, privacy contact, and technical administrators. - Document each surveillance purpose, justification, location, field of view, data type, and intended user. - Complete and approve a privacy impact assessment before deployment or material analytic change. - Minimize collection through positioning, masks, exclusion zones, purpose-specific analytics, and disabled unnecessary audio. - Define jurisdiction- and purpose-based retention, preservation holds, deletion, export, and sharing rules. - Restrict and audit live view, search, export, administration, and third-party access. - Verify time, location, camera identity, encryption, integrity, notices, and complaint contact information. - Review the program with affected stakeholders on a stated cadence and after significant change. ## Official reference - [Data Privacy Code of Practice: Video Surveillance](https://www.securityindustry.org/wp-content/uploads/2025/06/SIA-Video-Code-of-Practice-2025.pdf) — SIA’s 2025 roles, assessment principles, operational controls, and legal disclaimer. ## Primary reference - Name: Security Industry Association — Data Privacy Code of Practice: Video Surveillance - Authority: Security Industry Association - URL: https://www.securityindustry.org/wp-content/uploads/2025/06/SIA-Video-Code-of-Practice-2025.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “A privacy operating model for video surveillance based on SIA’s 2025 Code,” DSE Security, https://update.dsesecurity.com/updates/video-surveillance-privacy-operating-model-sia-code/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # A production-safe update window for servers, networks, and endpoints > A repeatable update window reduces avoidable outages by defining scope, dependencies, success tests, communications, and recovery before the first system changes. - Canonical URL: https://update.dsesecurity.com/updates/production-safe-it-update-window/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-10T13:00:00+00:00 - Modified: 2026-07-19T19:06:30+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Information - Topics: IT - Reading time: 1 minutes ## What you need to know A repeatable update window reduces avoidable outages by defining scope, dependencies, success tests, communications, and recovery before the first system changes. ## Potentially affected Business servers, network infrastructure, endpoints, cloud-connected services, line-of-business applications, and the security platforms that depend on them. ## DSE recommendation Use a written change plan with owners, maintenance scope, prechecks, backups, monitoring, functional validation, rollback criteria, and documented follow-up. ## Article ## Define success before the change A maintenance window is easier to control when success is measurable. List the systems in scope, owners, dependencies, expected versions, customer-facing impact, validation steps, and the conditions that would trigger a rollback or escalation. ## Minimum change plan - Scope: exact devices, services, locations, and versions. - Dependencies: identity, DNS, storage, networks, certificates, integrations, and upstream services. - Protection: verified backups, configuration exports, snapshots where appropriate, and recovery credentials. - Communication: start, status, issue, and completion messages with named recipients. - Deployment: a representative pilot followed by controlled groups. - Validation: monitoring plus real business and security workflows. - Closure: exceptions, owners, due dates, and documentation updates. ## Validate the service, not just the device A server can be online while its application is unhealthy; a switch can respond while a camera VLAN is impaired; an endpoint can reboot while its security agent fails to reconnect. Close maintenance only after representative end-to-end workflows succeed and monitoring shows a stable state. ## Primary reference - Name: DSE Updates editorial methodology - Authority: DSE Security editorial guidance - URL: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “A production-safe update window for servers, networks, and endpoints,” DSE Security, https://update.dsesecurity.com/updates/production-safe-it-update-window/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Accept DNS configuration from IPv6 router advertisements only within option lifetimes > Use RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/accept-dns-configuration-from-ipv6-router-advertisements-only-within-option-lifetimes/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:45+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Accept DNS configuration from IPv6 router advertisements only within option lifetimes. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration](https://www.rfc-editor.org/rfc/rfc8106.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An RDNSS option’s Lifetime is the maximum time its advertised recursive-server addresses may be used; a zero lifetime removes them immediately. The research record locates this support at Section 5.1 (Recursive DNS Server Option). - A DNSSL option applies the same lifetime semantics to its advertised DNS search suffixes, including immediate withdrawal at zero. The research record locates this support at Section 5.2 (DNS Search List Option). - A host discards invalid RA DNS options and stores valid options in ordered repositories alongside information learned from other RAs and DHCP. The research record locates this support at Section 5.3.1 (Procedure in IPv6 Hosts). Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 5.1 (Recursive DNS Server Option), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 5.2 (DNS Search List Option), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5.3.1 (Procedure in IPv6 Hosts), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from Section 5.1 (Recursive DNS Server Option); Section 5.2 (DNS Search List Option); Section 5.3.1 (Procedure in IPv6 Hosts) to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration](https://www.rfc-editor.org/rfc/rfc8106.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8106.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Accept DNS configuration from IPv6 router advertisements only within option lifetimes,” DSE Security, https://update.dsesecurity.com/updates/accept-dns-configuration-from-ipv6-router-advertisements-only-within-option-lifetimes/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Accept focus across the required depth, not at one target point > A sharp test chart at one distance can hide unusable foreground or background detail. Commission lens choice and focus across the full operational zone. - Canonical URL: https://update.dsesecurity.com/updates/accept-focus-across-the-required-depth/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:36:07+00:00 - Modified: 2026-08-25T21:36:16+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Advisory - Topics: Video Surveillance - Reading time: 2 minutes ## What you need to know A sharp test chart at one distance can hide unusable foreground or background detail. Commission lens choice and focus across the full operational zone. ## Potentially affected Fixed, varifocal, box, and interchangeable-lens cameras expected to resolve subjects across a lane, lobby, corridor, perimeter, or other depth range. ## DSE recommendation Define near and far task planes, test both in day and low-light modes, and document any aperture, shutter, illumination, or focus tradeoff. ## Article Bottom line: camera focus should be accepted as a three-dimensional operational zone. A face, badge, vehicle, or package can be sharp at the commissioning marker while the places where incidents actually occur fall outside useful depth of field. ## Source fact: lens and scene geometry determine the useful image Axis’s [Lenses in surveillance](https://whitepapers.axis.com/en-us/lenses-in-surveillance) explains that field of view depends on focal length and image-sensor size. It describes depth of field as affected by factors including focal length, aperture, focus distance, and viewing conditions. It also warns that a lens must be compatible with the sensor; a mismatch can produce effects such as dark corners or an unintended telephoto-like crop. The settings interact. Opening an iris to gather light can reduce depth of field. Increasing focal length can narrow the scene and change the in-focus range. Digital sharpness cannot restore detail that was never optically resolved. ## Source boundary and applicability The paper provides optical principles and Axis product context, not an acceptance threshold for a security task. Actual results depend on lens and sensor tolerances, focus method, aperture control, temperature, housing window, illumination, shutter time, motion, compression, and viewing scale. Requirements must be defined for the real scene. ## Applicability questions - What must be observed or identified, and at which nearest and farthest points? - Does the iris change automatically between daylight and low light? - Can autofocus select a high-contrast background instead of the target zone? - Is the installed lens designed for the camera’s sensor size and resolution? - Do a dome, protective window, IR reflection, vibration, or temperature change the focus result? ## DSE recommendation: commission near, middle, and far task planes The following steps are DSE recommendations based on the cited source. Mark at least the nearest, nominal, and farthest positions at which the defined task must succeed. Place appropriate test targets at each plane and capture them simultaneously where possible. Run the test in daylight, the lowest intended illumination, IR mode if used, and any other condition that changes aperture or focus. Retrieve the recorded stream rather than relying only on the setup preview. If the full range cannot meet the task, adjust placement or lens, add illumination, narrow the operational zone, or add a targeted camera. Lock or monitor focus settings where the product permits, but preserve a controlled method for refocusing after maintenance. ## Verification and evidence Retain the task definition, scene drawing with distances, camera and lens models, sensor and mounting information, focus and exposure settings, retrieved clips or stills from every plane and lighting condition, and acceptance signatures. Repeat after lens, housing, camera, illumination, or scene changes. ## Official references - [Lenses in surveillance](https://whitepapers.axis.com/en-us/lenses-in-surveillance) – Axis Communications ## Primary reference - Name: Lenses in surveillance - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/lenses-in-surveillance - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Accept focus across the required depth, not at one target point,” DSE Security, https://update.dsesecurity.com/updates/accept-focus-across-the-required-depth/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Accept intelligent compression with incident scenes, not average savings > Content-aware compression can reduce bandwidth and storage, but averages do not prove that fast or complex incident detail survives. Test the tasks that matter. - Canonical URL: https://update.dsesecurity.com/updates/accept-intelligent-compression-with-incident-scenes/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:36:01+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Networks & Infrastructure, Video Surveillance - Reading time: 2 minutes ## What you need to know Content-aware compression can reduce bandwidth and storage, but averages do not prove that fast or complex incident detail survives. Test the tasks that matter. ## Potentially affected Axis camera systems using Zipstream or comparable content-aware compression to reduce video bitrate and storage. ## DSE recommendation Commission compression with repeatable high-motion, low-light, and fine-detail scenes, and approve the setting only after retrieved native video meets the defined task. ## Article Bottom line: storage savings are not an acceptance criterion for evidence quality. Content-aware compression makes decisions about where to spend bits; commissioning must show that those decisions preserve the operational detail required during difficult events. ## Source fact: Zipstream prioritizes selected image information The Axis paper [Axis Zipstream technology](https://whitepapers.axis.com/en-us/axis-zipstream-technology) describes vendor algorithms that analyze video in real time and preserve selected important detail while compressing other areas more heavily. Axis reports average bandwidth and storage savings for its technology and describes features such as a dynamic region of interest. An average across scenes does not predict a specific incident. A quiet lobby can compress very differently from rain, foliage, flashing light, crowds, vehicle motion, sensor noise, or simultaneous movement across the image. ## Source boundary and applicability The paper documents Axis technology and vendor test claims; it is not a guarantee of a fixed savings percentage or evidentiary result for any deployment. Results depend on camera model, AXIS OS version, codec, strength setting, frame rate, group-of-pictures behavior, scene, exposure, and VMS handling. Other manufacturers’ similarly named features can work differently. ## Applicability questions - Which subject detail must survive: face, plate, badge, hand action, package, clothing, or event sequence? - What are the most complex daytime and nighttime scenes? - Does the VMS preserve the camera stream or transcode it? - Which settings are changed by event mode, bandwidth policy, or storage pressure? - Is downstream analytics using the same compressed stream that investigators review? ## DSE recommendation: use a task-and-scene compression trial The following steps are DSE recommendations based on the cited source. Define repeatable incident actions at relevant distances, then record them with production lighting, shutter, resolution, frame rate, analytics, and compression. Include a quiet baseline plus the hardest credible motion and noise conditions. Retrieve the native archive and score the defined task without knowing which compression setting produced the sample when practical. Measure both quality and resource use: sustained and peak bitrate, storage per interval, recorder load, export result, and any visible artifact that affects the task. Select the lowest resource setting that consistently passes, preserve headroom for scene variation, and lock the accepted profile through change control. Include an independent reviewer who did not configure the camera. Ask that reviewer to complete the real observation or identification task from archived footage, not merely rate the image as attractive or sharp. ## Verification and evidence Retain the task criteria, scene script, camera and software versions, every tested configuration, native clips, blinded scores where used, bitrate traces, storage calculations, peak observations, and approval. Repeat when the scene, illumination, codec, firmware, recorder, analytics, or compression implementation changes. ## Official references - [Axis Zipstream technology](https://whitepapers.axis.com/en-us/axis-zipstream-technology) – Axis Communications ## Primary reference - Name: Axis Zipstream technology - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/axis-zipstream-technology - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Accept intelligent compression with incident scenes, not average savings,” DSE Security, https://update.dsesecurity.com/updates/accept-intelligent-compression-with-incident-scenes/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Accept low-light video by reproducing the scene—not by trusting the lux line > Minimum-lux specifications cannot prove that a camera will capture usable color, motion, faces, clothing, or vehicles in a real scene. Build acceptance tests around the operational task and reproduce the darkest credible conditions. - Canonical URL: https://update.dsesecurity.com/updates/accept-low-light-video-by-reproducing-the-scene/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:15:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Video Surveillance - Reading time: 3 minutes ## What you need to know Minimum-lux specifications cannot prove that a camera will capture usable color, motion, faces, clothing, or vehicles in a real scene. Build acceptance tests around the operational task and reproduce the darkest credible conditions. ## Potentially affected New and replacement surveillance cameras, lenses, illuminators, exterior and interior low-light scenes, camera profiles, recording streams, analytics, operator workstations, mobile clients, and exported evidence. ## DSE recommendation Define the decision each view must support, reproduce representative darkness and motion, test live and recorded video through the real client and export path, record settings and results, and schedule repeat verification after environmental or configuration change. ## Article ## Source facts: minimum illumination is not an acceptance result The Axis Communications [Lightfinder white paper](https://whitepapers.axis.com/en-us/lightfinder) explains that very-low-light performance depends on a combination of sensor, lens, system-on-chip, and image processing. It also notes that using available light efficiently can support shorter exposure and thereby reduce blur and noise. That is a system behavior under specific conditions, not proof that one minimum-lux number will satisfy an installed surveillance task. Axis’s [image-quality troubleshooting guide](https://help.axis.com/en-US/troubleshooting-image-quality) shows that aperture, shutter speed, gain, depth of field, wide dynamic range, color, reflections, and sunlight can change image usability. A longer exposure can brighten a static scene while blurring a moving person. Infrared illumination can reveal shapes while changing color information and creating reflections from domes, windows, rain, insects, or nearby surfaces. These are manufacturer educational sources, not a universal performance standard or a guarantee for another product. A datasheet test does not reproduce a site’s mounting height, lens, compression, motion, weather, lighting, client, or recording path. Whether footage is legally sufficient for identification is a fact-specific determination for investigators, counsel, and the relevant authority—not a claim that should be inferred from pixels or lux alone. ## DSE recommendation: accept the operational task in the real scene Write one concise purpose for each important view: detect a person crossing a boundary, recognize a known employee at an entrance, read a vehicle description, document a transaction, or reconstruct movement. Translate that purpose into observable acceptance criteria before adjusting the camera. “Looks good” is not repeatable; “an operator can distinguish the required jacket color while the subject walks through the marked zone” is testable. - Capture the baseline. Record mounting height, lens and field of view, focus, resolution, frame rate, shutter limits, gain limits, WDR, day/night switching, IR state, bitrate controls, compression, and recording profile. Photograph or measure the lighting arrangement and note reflective surfaces. - Reproduce credible darkness. Test during the darkest representative operating period, not at dusk when residual light makes the scene easier. Include ordinary signs, vehicle headlights, doors opening, lights cycling, wet pavement, and any nearby IR source that can change exposure. - Use representative motion. Move a consenting test subject or authorized vehicle through the near, middle, and far portions of the task zone at realistic speeds. Include movement toward and across the camera. Do not substitute a stationary chart for a motion requirement. - Inspect the whole path. Review live video, recorded playback, search thumbnails, mobile or remote clients if used, and an exported clip on an approved independent workstation. Confirm timestamps, continuity, color behavior, compression artifacts, and whether the detail survives export. - Challenge competing goals. Check whether a setting that reduces blur also makes shadows unusable, whether noise reduction removes small moving detail, whether WDR introduces artifacts, and whether added illumination creates glare or affects neighbors. Preserve a known-good profile before experimenting. - Record the decision. Save labeled sample clips, test conditions, results, exceptions, approver, and corrective work. If a task fails, change lighting, placement, lens, field of view, or camera selection rather than declaring the specification adequate. Repeat the test after vegetation growth, construction, lighting replacement, firmware or profile changes, camera movement, dome replacement, and seasonal conditions that materially alter the scene. Routine health monitoring can identify loss of video, but it cannot prove that a view still supports its intended decision. The acceptance record should state what was tested and what was not. It should never promise performance in every weather, lighting, distance, or subject condition. A defensible result is narrower and more valuable: under documented representative conditions, the installed and recorded system allowed trained reviewers to complete the defined task. ## Official references - Axis Communications, [Lightfinder](https://whitepapers.axis.com/en-us/lightfinder). - Axis Communications, [Troubleshooting guide for image quality](https://help.axis.com/en-US/troubleshooting-image-quality). ## Primary reference - Name: Axis Communications: Lightfinder white paper - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/lightfinder - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Accept low-light video by reproducing the scene—not by trusting the lux line,” DSE Security, https://update.dsesecurity.com/updates/accept-low-light-video-by-reproducing-the-scene/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Accept new fiber with both Tier 1 loss evidence and Tier 2 event evidence > Tier 1 OLTS testing proves total insertion loss, length, and polarity against the selected limit. Tier 2 OTDR testing adds event location, loss, and reflectance. Specify both where needed, test correctly, and receive native traces—not just a pass/fail PDF. - Canonical URL: https://update.dsesecurity.com/updates/fiber-tier-1-tier-2-acceptance-testing/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:07:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Networks & Infrastructure - Reading time: 4 minutes ## What you need to know Tier 1 OLTS testing proves total insertion loss, length, and polarity against the selected limit. Tier 2 OTDR testing adds event location, loss, and reflectance. Specify both where needed, test correctly, and receive native traces—not just a pass/fail PDF. ## Potentially affected New and renovated multimode and single-mode fiber links; campus backbones, data centers, telecommunications rooms, outside-plant runs, splices, connectors, patch panels, optical loss test sets, OTDRs, and project closeout records. ## DSE recommendation Define the standard, link model, fiber type, wavelengths, reference method, loss budget, Tier 2 scope, bidirectional requirements, native result format, naming convention, tester calibration, and remediation rules before field testing starts. ## Article ## Source facts: Tier 1 and Tier 2 are complementary measurements Fluke Networks’ [OTDR guidance](https://www.flukenetworks.com/blog/cabling-chronicles/otdr-your-ultimate-troubleshooter) distinguishes the two common acceptance layers. Tier 1 testing uses an optical loss test set (OLTS) to measure end-to-end insertion loss and commonly length and polarity at the specified wavelengths. The result is compared with the selected standard, application, or project limit. An OLTS provides the most accurate total insertion-loss measurement for acceptance. Tier 2 adds an optical time-domain reflectometer (OTDR). An OTDR launches light pulses and analyzes reflection and backscatter over distance, producing a trace and event table for connectors, splices, bends, breaks, and the end of the link. It can show where loss or reflectance occurs and identify a marginal component hidden inside an otherwise acceptable total-loss result. Tier 2 does not replace Tier 1. Fluke notes that OTDR-derived total loss is not as accurate or repeatable as the controlled OLTS insertion-loss measurement, particularly for multimode links with defined launch conditions. A complete Tier 2 acceptance therefore retains the Tier 1 OLTS result and adds OTDR characterization. Direction matters to OTDR event loss. Differences in fiber backscatter can make a splice appear to gain power in one direction or exaggerate its loss in the other. Bidirectional results are averaged to estimate the event correctly. Launch and tail fibers are needed to characterize the first and last connectors, which otherwise sit inside the instrument’s dead zones. The tested wavelengths must match the fiber, standard, application, and contract. Separately, ANSI/TIA-568.3-E is the current TIA optical-fiber cabling and component standard announced by the Telecommunications Industry Association in September 2022; the exact project edition and limits should be stated rather than implied. ## DSE recommendation: write the acceptance specification before the pull Put the test requirement in the design and contract before installation. For every link class, define: - link identifier, endpoints, pathway, fiber type, strand count, connector and polish, splice plan, and link model; - governing standard and edition, application limits where relevant, project loss budget, wavelengths, and pass/fail method; - Tier 1 OLTS configuration, reference method, test-reference cords, polarity and length requirements; - Tier 2 OTDR scope, both-direction requirement, launch and tail cords, event-loss and reflectance limits, and trace settings; - tester model, software version, calibration status, technician qualification, native result format, PDF report, and file naming; - inspection and cleaning procedure, failed-link remediation, retest, witness sampling, and final acceptance authority. At the start of testing, verify tester time, project limits, fiber and wavelength selection, reference method, cords, launch conditions, and calibration. Inspect and clean connector end faces before reference and measurement; a contaminated test cord can create bad results across an entire project. Preserve the reference result and tester configuration with the job record. - Run Tier 1 on every required strand. Capture insertion loss, length, and polarity at all specified wavelengths. Investigate marginal results rather than accepting a pass that leaves no allowance for aging, moves, or additional connections. - Run Tier 2 where specified. Test from both directions with appropriate launch and tail fibers. Review the trace and event table, not only the instrument’s overall badge. Reconcile the number and position of events with drawings and splice records. - Remediate the cause. Clean, reterminate, resplice, relieve a bend, repair damage, or correct polarity through an approved method, then rerun the complete required test. Do not edit a report or delete the failing direction. - Normalize the closeout package. Require one identifier across label, drawing, OLTS record, OTDR traces, splice record, panel schedule, and asset system. Receive native tester files so future engineers can reopen traces, plus durable human-readable reports. - Sample the evidence. Independently review all failures and marginal passes and witness a representative cross-section of distances, pathways, crews, panels, and fiber types before final acceptance. Keep baseline traces for future moves and troubleshooting. When a later outage occurs, comparison with the accepted event map can distinguish a new bend, splice, connector, or break from an original condition. The project is complete when the owner receives traceable proof of total link performance and component-level workmanship—not when light merely appears at the far end. ## Official references - Fluke Networks, [OTDR: Your Ultimate Troubleshooter](https://www.flukenetworks.com/blog/cabling-chronicles/otdr-your-ultimate-troubleshooter), August 11, 2025. - Telecommunications Industry Association, [TIA Issues Updated Optical Fiber Cabling Component Standard, ANSI/TIA-568.3-E](https://tiaonline.org/standardannouncement/tia-issues-updated-optical-fiber-cabling-component-standard-ansi-tia-568-3-e/), September 29, 2022. ## Primary reference - Name: Fluke Networks: OTDR—Your Ultimate Troubleshooter - Authority: Fluke Networks - URL: https://www.flukenetworks.com/blog/cabling-chronicles/otdr-your-ultimate-troubleshooter - Source publication date: 2025-08-11 ## Citation and use Preferred citation: “Accept new fiber with both Tier 1 loss evidence and Tier 2 event evidence,” DSE Security, https://update.dsesecurity.com/updates/fiber-tier-1-tier-2-acceptance-testing/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Accept UTF-8 headers only under internationalized mail syntax > Use RFC 6532 — Internationalized Email Headers to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/accept-utf-8-headers-only-under-internationalized-mail-syntax/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:10+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6532 — Internationalized Email Headers to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6532 — Internationalized Email Headers ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Accept UTF-8 headers only under internationalized mail syntax. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6532 — Internationalized Email Headers](https://www.rfc-editor.org/rfc/rfc6532.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Internationalized mail permits UTF-8 in header field bodies, while header field names remain ASCII-only. The research record locates this support at Section 3 (Changes to Message Header Fields). - UTF-8 header text should use NFC normalization and should not use NFKC when that would lose spelling distinctions. The research record locates this support at Section 3.1 (UTF-8 Syntax and Normalization). - A message/global message may be sent over SMTP only when the SMTPUTF8 extension authorizes that transport. The research record locates this support at Section 3.7 (The message/global Media Type). Only the traced statements above are asserted as source facts. Apply the review to sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 3 (Changes to Message Header Fields), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3.1 (UTF-8 Syntax and Normalization), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 3.7 (The message/global Media Type), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from Section 3 (Changes to Message Header Fields); Section 3.1 (UTF-8 Syntax and Normalization); Section 3.7 (The message/global Media Type) to the observed environment. Useful domain evidence includes sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 6532 — Internationalized Email Headers](https://www.rfc-editor.org/rfc/rfc6532.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6532 — Internationalized Email Headers - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6532.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Accept UTF-8 headers only under internationalized mail syntax,” DSE Security, https://update.dsesecurity.com/updates/accept-utf-8-headers-only-under-internationalized-mail-syntax/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Access control update readiness: protect the doors while changing the software > Access control maintenance requires more than installing an update. Teams must preserve door operation, credentials, schedules, alarms, integrations, and an auditable recovery path. - Canonical URL: https://update.dsesecurity.com/updates/access-control-update-readiness/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-11T09:30:00+00:00 - Modified: 2026-07-19T19:06:30+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 1 minutes ## What you need to know Access control maintenance requires more than installing an update. Teams must preserve door operation, credentials, schedules, alarms, integrations, and an auditable recovery path. ## Potentially affected Access-control servers, databases, operator workstations, controllers, readers, credential services, visitor systems, identity integrations, and connected alarm workflows. ## DSE recommendation Build a verified inventory, document fail-safe and fail-secure behavior, back up the platform and controller data, test the upgrade path, and validate every critical workflow after maintenance. ## Article ## Start with operational behavior Access control is both a technology platform and a physical operating system for a facility. A successful maintenance window must preserve the intended behavior of doors, credentials, schedules, alarms, elevators, intercoms, visitor workflows, and emergency procedures. ## Before the maintenance window - Record application, database, controller, reader, and firmware versions. - Confirm supported upgrade paths and licensing requirements with the manufacturer. - Verify platform, database, and configuration backups and document restoration steps. - Identify critical openings and document their fail-safe or fail-secure behavior. - Confirm how controllers operate if the management server is temporarily unavailable. - Coordinate with facility, security, IT, and life-safety stakeholders. ## After the change Validation should include more than a successful login. Test representative credentials, schedules, unlock and lockdown actions, forced-door and held-door alarms, operator acknowledgements, reporting, video or intercom integrations, and communications to remote controllers. Record the result and any exception before closing the change. Vendor-specific instructions always take priority. DSE field guidance is intended to help customers organize the operational checks around those instructions. ## Primary reference - Name: DSE Updates editorial methodology - Authority: DSE Security editorial guidance - URL: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Access control update readiness: protect the doors while changing the software,” DSE Security, https://update.dsesecurity.com/updates/access-control-update-readiness/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Account for both virtual Fibre Channel WWN sets before live migration > What Fibre Channel identity should be reviewed before migrating a VM with a virtual HBA? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-117-account-for-both-virtual-fibre-channel-wwn-sets-before-live-migration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:14+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What Fibre Channel identity should be reviewed before migrating a VM with a virtual HBA? ## Potentially affected Administrators connecting Hyper-V guests directly to Fibre Channel storage. ## DSE recommendation Create a mapping of the adapter’s two WWN sets to the authorized storage presentation on both hosts. ## Article ## Source facts Hyper-V virtual Fibre Channel gives a guest direct SAN access using a VM-associated World Wide Name. It relies on NPIV: starting a VM with a virtual HBA creates an NPIV port on the host, and stopping the VM removes it. The topology and SAN must support those ports. For live migration, each virtual adapter has two WWN sets and Hyper-V alternates between them. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/virtual-fibre-channel-for-hyper-v). ## Applicability Identify the guest workload, virtual HBA, physical ports, SAN, supported topology, and intended migration hosts. Review the complete platform requirements before adapting a virtual Fibre Channel example. ## DSE recommendation Create a mapping of the adapter’s two WWN sets to the authorized storage presentation on both hosts. Have the SAN owner review the mapping and confirm the intended LUN access. Include a maintenance and recovery decision for the workload before exercising a migration. ## Verification Validate guest storage access on the source host and after an approved migration to the destination. Record the active WWN identity and the LUNs actually visible at each step. Test the planned return move and investigate missing storage or unexpected access before authorizing routine migration of that workload. ## Official references [Microsoft Learn: Hyper-V Virtual Fibre Channel in Windows Server](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/virtual-fibre-channel-for-hyper-v). Source reviewed September 8, 2026. ## Primary reference - Name: Hyper-V Virtual Fibre Channel in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/virtual-fibre-channel-for-hyper-v - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Account for both virtual Fibre Channel WWN sets before live migration,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-117-account-for-both-virtual-fibre-channel-wwn-sets-before-live-migration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Account for coarser samples when reviewing older S2D performance history > How does the age of Storage Spaces Direct performance history affect its time resolution? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-157-account-for-coarser-samples-when-reviewing-older-s2d-performance-history/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:34+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know How does the age of Storage Spaces Direct performance history affect its time resolution? ## Potentially affected Administrators interpreting retained Storage Spaces Direct performance measurements on supported releases from Windows Server 2019 onward. ## DSE recommendation Label every chart or report with both the object scope and time resolution. ## Article ## Source facts Microsoft collects S2D performance history automatically and stores it on the cluster for up to a year. Performance history was introduced in Windows Server 2019; Windows Server 2016 does not provide it. Recent data is more detailed: the most recent hour has ten-second measurements, the day has five-minute measurements, and the week has fifteen-minute measurements. Older samples are merged using averaging or summation as appropriate. Some series are also aggregated from individual objects to parents, such as adapters to a server. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/performance-history). ## Applicability Identify the metric, object level, event time, requested timeframe, and sample granularity. Check whether the question requires a brief spike or a longer trend before relying on older retained data. ## DSE recommendation Label every chart or report with both the object scope and time resolution. Ask the investigator to distinguish a missing short-lived peak from a measurement that was never retained at that resolution. Preserve suitably detailed incident evidence promptly when a narrow timing question is expected. ## Verification Compare sample timestamps and aggregation level with the requested interval before interpreting the values. Where possible, reconcile a recent detailed period with its broader summary. Record the temporal limitation in the finding so an averaged historical value is not presented as proof that a short event did not occur. ## Official references [Microsoft Learn: Performance history for Storage Spaces Direct](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/performance-history). Source reviewed September 8, 2026. ## Primary reference - Name: Performance history for Storage Spaces Direct - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/performance-history - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Account for coarser samples when reviewing older S2D performance history,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-157-account-for-coarser-samples-when-reviewing-older-s2d-performance-history/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Account for scope removal when migrating DHCP failover partners > What must be checked before breaking a DHCP failover relationship during migration? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-060-account-for-scope-removal-when-migrating-dhcp-failover-partners/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:11+00:00 - Modified: 2026-09-08T18:20:21+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What must be checked before breaking a DHCP failover relationship during migration? ## Potentially affected Use this review when replacing both members of a DHCP failover arrangement. ## DSE recommendation Prepare a partner-and-scope worksheet and have another administrator verify the side from which the relationship will be removed. ## Article ## Source facts Microsoft’s failover-migration sequence breaks the existing relationship, exports and imports settings, and configures failover on the replacement servers. Deleting the relationship removes its member scopes from the partner DHCP server. The documented example moves a Windows Server 2022 failover deployment to Windows Server 2025, using specifically identified old and new servers. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/migrate-existing-dhcp-failover). ## Applicability Use this review when replacing both members of a DHCP failover arrangement. Identify every relationship, partner, and member scope before adapting the sequence. Treat the source’s server names as an example rather than deployment inputs. ## DSE recommendation Prepare a partner-and-scope worksheet and have another administrator verify the side from which the relationship will be removed. Assign owners for preserving settings, controlling the service transition, and testing the new pair. Record the expected scope inventory at each stage so deliberate removal is not confused with accidental loss. Keep the approved recovery decision available throughout the migration. ## Verification After each approved stage, compare the observed scope and relationship state with the worksheet. Test client lease behavior before accepting the new relationship, and include the selected failover exercise. Retain evidence from both replacement servers. Investigate missing scopes or an unexpected serving partner before retiring either original server. ## Official references [Microsoft Learn: Migrate existing DHCP failover deployment on Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/migrate-existing-dhcp-failover). Source reviewed September 8, 2026. ## Primary reference - Name: Migrate existing DHCP failover deployment on Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/migrate-existing-dhcp-failover - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Account for scope removal when migrating DHCP failover partners,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-060-account-for-scope-removal-when-migrating-dhcp-failover-partners/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Account for special identity groups in every Windows ACL review > Use Special Identity Groups to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/account-for-special-identity-groups-in-acl-review/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:42+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Special Identity Groups to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Special Identity Groups ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Account for special identity groups in every Windows ACL review. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Special Identity Groups](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-special-identities-groups) from Microsoft supports the following bounded statements: - Special identity groups provide a Windows mechanism for assigning access based on authentication or operating context. The research record locates this support at Opening overview. - The reference distinguishes identities such as Anonymous Logon, Authenticated Users, and authentication-authority asserted identities. The research record locates this support at Section: Default special identity groups. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles only where the source and recorded environment align. ## What the source does not establish Do not treat special identities as ordinary AD groups with manually managed membership. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section: Default special identity groups, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Opening overview; Section: Default special identity groups to the observed environment. Useful domain evidence includes directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Special Identity Groups](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-special-identities-groups) — Microsoft ## Primary reference - Name: Special Identity Groups - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-special-identities-groups - Source publication date: 2025-07-08 ## Citation and use Preferred citation: “Account for special identity groups in every Windows ACL review,” DSE Security, https://update.dsesecurity.com/updates/account-for-special-identity-groups-in-acl-review/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Activate Defender for Identity sensor v3 only after its prerequisite checks > Use Deploy the Defender for Identity sensor v3.x to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/activate-defender-for-identity-sensor-v3-after-prerequisites/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:40+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Deploy the Defender for Identity sensor v3.x to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Deploy the Defender for Identity sensor v3.x ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Activate Defender for Identity sensor v3 only after its prerequisite checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Deploy the Defender for Identity sensor v3.x](https://learn.microsoft.com/en-us/defender-for-identity/deploy/deploy-sensor-v3) from Microsoft supports the following bounded statements: - The sensor v3.x is deployed on supported domain controllers. The research record locates this support at Opening overview. - Microsoft directs administrators to complete prerequisite checks before activation and configure auditing and identity settings afterward. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This is the v3 deployment sequence, not an eligibility inventory or validation result for any particular domain controller. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Opening overview. Favor sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Deploy the Defender for Identity sensor v3.x](https://learn.microsoft.com/en-us/defender-for-identity/deploy/deploy-sensor-v3) — Microsoft ## Primary reference - Name: Deploy the Defender for Identity sensor v3.x - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/deploy-sensor-v3 - Source publication date: 2026-08-23 ## Citation and use Preferred citation: “Activate Defender for Identity sensor v3 only after its prerequisite checks,” DSE Security, https://update.dsesecurity.com/updates/activate-defender-for-identity-sensor-v3-after-prerequisites/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add NOAA Weather Radio as a tested independent alert path > Use locally verified NOAA Weather Radio reception and backup power as one independent path for hazardous-weather information. - Canonical URL: https://update.dsesecurity.com/updates/add-noaa-weather-radio-as-alert-path/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:28+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know Use locally verified NOAA Weather Radio reception and backup power as one independent path for hazardous-weather information. ## Potentially affected Facilities and operations exposed to weather or other hazards carried by NOAA Weather Radio ## DSE recommendation Install suitable receivers where reception is verified, configure relevant alerts, and exercise staff response without relying on Internet or mobile service. ## Article A weather app and email alert can share Internet, identity, mobile, or power dependencies. A properly received and powered NOAA Weather Radio adds a different path, but only a site test can show whether the signal and workflow are reliable enough to help. ## Source fact: [The National Weather Service](https://www.weather.gov/nwr/) describes NOAA Weather Radio All Hazards as a nationwide network of radio stations that broadcasts continuous weather information from nearby NWS offices. Broadcasts include official warnings, watches, forecasts, and other hazard information. Reception requires a suitable receiver or scanner in range of a transmitter. The NWS also notes that transmitter outages or degradation can occur. Coverage maps and a receiver’s presence therefore do not establish reliable indoor reception at a particular desk, server room, basement, or alternate site. NOAA Weather Radio is an additional alert source; it does not replace local emergency instructions, facility alarm systems, or other redundant warning channels. ## Boundary Coverage, alert content, transmitter availability, antenna placement, building construction, terrain, and local interference affect results. Specific Area Message Encoding and alert-selection features vary by receiver. A device may have battery backup but still lose time, configuration, audio output, or antenna effectiveness. Not every hazard or local protective-action message is carried through the same system, and people who cannot hear an audible alarm need accessible alternatives. ## Applicability questions - Which NWS transmitter and frequency serve each primary, alternate, warehouse, and field location? - Is reception clear in the occupied location and during adverse weather, not only beside a window on a fair day? - Which county or SAME codes and alert categories match the site’s risk and operating area? - How long will the receiver operate without utility power, and who replaces batteries? - Who hears or sees the alert outside staffed hours, and what action authority follows? ## DSE recommendation: Select a receiver appropriate to local signal, alert-selection, accessibility, external-antenna, and backup-power needs. Use NWS information to identify candidate transmitters, then test reception at the receiver’s intended location and at alternate sites. Configure only the geographic areas and event types required by the risk plan so routine alarms do not undermine attention. Record configuration and protect it from casual changes. Connect the alert to a short decision procedure: who validates the message, which operations are informed, where official detail is obtained, and who can change facility status. Test the receiver during scheduled weekly or monthly NWS test opportunities when locally available and permitted, while recognizing that absence of a test may have several causes. Include utility-power loss and an Internet/mobile outage in exercises. Provide visual, text, or other accessible notification paths alongside audio. ## Verification and evidence Keep receiver model, location, transmitter/frequency, geographic codes, alert selections, battery dates, antenna details, reception-test logs, and exercise results. Evidence should show that a received test reached the responsible role and produced the expected acknowledgment. Track transmitter-status reports during troubleshooting and maintain at least one other authoritative alert method because no single receiver or broadcast path is guaranteed. ## Official references - [National Weather Service: NOAA Weather Radio](https://www.weather.gov/nwr/) ## Primary reference - Name: NOAA Weather Radio All Hazards - Authority: www.weather.gov - URL: https://www.weather.gov/nwr/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add NOAA Weather Radio as a tested independent alert path,” DSE Security, https://update.dsesecurity.com/updates/add-noaa-weather-radio-as-alert-path/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add sensor onboarding and Test-MDIConfiguration to identity-platform reviews > Use Quarterly or ad-hoc operational guide for Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-sensor-onboarding-test-mdiconfiguration-identity-reviews/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:32+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Quarterly or ad-hoc operational guide for Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Quarterly or ad-hoc operational guide for Microsoft Defender for Identity ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Add sensor onboarding and Test-MDIConfiguration to identity-platform reviews. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Quarterly or ad-hoc operational guide for Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/ops-guide/ops-guide-quarterly) from Microsoft supports the following bounded statements: - Microsoft recommends periodically verifying that the server setup process installs Defender for Identity sensors on new domain controllers, AD CS servers, and AD FS servers. The research record locates this support at Review server setup process to include sensors. - Microsoft recommends periodically running Test-MDIConfiguration to check domain-controller audit policy settings because incorrect settings can create Event Log gaps and reduce Defender for Identity coverage. The research record locates this support at Check domain configuration via PowerShell. Keep the evidence boundary at these traced claims. They support a review of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The source is a quarterly or ad-hoc guide; local cadence, supported server roles, permissions, and remediation ownership still require an environment-specific operating procedure. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Review server setup process to include sensors, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Check domain configuration via PowerShell, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows are in and out of scope? - Which condition in Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from Review server setup process to include sensors; Check domain configuration via PowerShell through alert records, investigation timelines, analyst actions, tuning or exclusion approvals, remediation results, and case closure. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Quarterly or ad-hoc operational guide for Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/ops-guide/ops-guide-quarterly) — Microsoft ## Primary reference - Name: Quarterly or ad-hoc operational guide for Microsoft Defender for Identity - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/ops-guide/ops-guide-quarterly - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Add sensor onboarding and Test-MDIConfiguration to identity-platform reviews,” DSE Security, https://update.dsesecurity.com/updates/add-sensor-onboarding-test-mdiconfiguration-identity-reviews/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-ADCentralAccessPolicyMember: stage additions to adcentral access policy member with before-and-after evidence > Use Add-ADCentralAccessPolicyMember to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-adcentralaccesspolicymember-stage-additions-to-adcentral-access-policy-member-with-before-and/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:47+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-ADCentralAccessPolicyMember to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-ADCentralAccessPolicyMember ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Add-ADCentralAccessPolicyMember: stage additions to adcentral access policy member with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-ADCentralAccessPolicyMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adcentralaccesspolicymember?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Adds central access rules to a central access policy in Active Directory.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Add-ADCentralAccessPolicyMember cmdlet adds central access rules to a central access policy in Active Directory.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-159 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Add-ADCentralAccessPolicyMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adcentralaccesspolicymember?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-ADCentralAccessPolicyMember - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adcentralaccesspolicymember?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-ADCentralAccessPolicyMember: stage additions to adcentral access policy member with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/add-adcentralaccesspolicymember-stage-additions-to-adcentral-access-policy-member-with-before-and/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-ADComputerServiceAccount: stage additions to adcomputer service account with rollback checks > Use Add-ADComputerServiceAccount to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-adcomputerserviceaccount-stage-additions-to-adcomputer-service-account-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:24+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-ADComputerServiceAccount to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-ADComputerServiceAccount ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Add-ADComputerServiceAccount: stage additions to adcomputer service account with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-ADComputerServiceAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adcomputerserviceaccount?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Adds one or more service accounts to an Active Directory computer.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Add-ADComputerServiceAccount cmdlet adds one or more computer service accounts to an Active Directory computer.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-182 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Add-ADComputerServiceAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adcomputerserviceaccount?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-ADComputerServiceAccount - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adcomputerserviceaccount?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-ADComputerServiceAccount: stage additions to adcomputer service account with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/add-adcomputerserviceaccount-stage-additions-to-adcomputer-service-account-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-ADFineGrainedPasswordPolicySubject: stage additions to adfine grained password policy subject with bounded evidence > Use Add-ADFineGrainedPasswordPolicySubject to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-adfinegrainedpasswordpolicysubject-stage-additions-to-adfine-grained-password-policy-subject/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:31+00:00 - Modified: 2026-08-27T17:14:53+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-ADFineGrainedPasswordPolicySubject to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-ADFineGrainedPasswordPolicySubject ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Add-ADFineGrainedPasswordPolicySubject: stage additions to adfine grained password policy subject with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-ADFineGrainedPasswordPolicySubject](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adfinegrainedpasswordpolicysubject?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Applies a fine-grained password policy to one more users and groups.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Add-ADFineGrainedPasswordPolicySubject cmdlet applies a fine-grained password policy to one or more global security groups and users.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Within Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, which versions, roles, and configuration states define the review population? - Could Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-115 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Add-ADFineGrainedPasswordPolicySubject](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adfinegrainedpasswordpolicysubject?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-ADFineGrainedPasswordPolicySubject - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adfinegrainedpasswordpolicysubject?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-ADFineGrainedPasswordPolicySubject: stage additions to adfine grained password policy subject with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/add-adfinegrainedpasswordpolicysubject-stage-additions-to-adfine-grained-password-policy-subject/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-ADGroupMember: stage additions to adgroup member with rollback checks > Use Add-ADGroupMember to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-adgroupmember-stage-additions-to-adgroup-member-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:39+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-ADGroupMember to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-ADGroupMember ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Add-ADGroupMember: stage additions to adgroup member with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-ADGroupMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adgroupmember?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Adds one or more members to an Active Directory group.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Add-ADGroupMember cmdlet adds one or more users, groups, service accounts, or computers as new members of an Active Directory group.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to SYNOPSIS; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-167 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Add-ADGroupMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adgroupmember?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-ADGroupMember - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adgroupmember?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-ADGroupMember: stage additions to adgroup member with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/add-adgroupmember-stage-additions-to-adgroup-member-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-ADPrincipalGroupMembership: stage additions to adprincipal group membership with bounded evidence > Use Add-ADPrincipalGroupMembership to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-adprincipalgroupmembership-stage-additions-to-adprincipal-group-membership-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:36+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-ADPrincipalGroupMembership to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-ADPrincipalGroupMembership ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Add-ADPrincipalGroupMembership: stage additions to adprincipal group membership with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-ADPrincipalGroupMembership](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adprincipalgroupmembership?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Adds a member to one or more Active Directory groups.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Add-ADPrincipalGroupMembership cmdlet adds a user, group, service account, or computer as a new member to one or more Active Directory groups.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to SYNOPSIS; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-170 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Add-ADPrincipalGroupMembership](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adprincipalgroupmembership?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-ADPrincipalGroupMembership - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adprincipalgroupmembership?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-ADPrincipalGroupMembership: stage additions to adprincipal group membership with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/add-adprincipalgroupmembership-stage-additions-to-adprincipal-group-membership-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-ADResourcePropertyListMember: stage additions to adresource property list member with rollback checks > Use Add-ADResourcePropertyListMember to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-adresourcepropertylistmember-stage-additions-to-adresource-property-list-member-with-rollback/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:04+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-ADResourcePropertyListMember to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-ADResourcePropertyListMember ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Add-ADResourcePropertyListMember: stage additions to adresource property list member with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-ADResourcePropertyListMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adresourcepropertylistmember?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Adds one or more resource properties to a resource property list in Active Directory.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Add-ADResourcePropertyListMember cmdlet adds one or more resource properties to a resource property list in Active Directory.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from SYNOPSIS; DESCRIPTION to the observed environment. Useful domain evidence includes sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-202 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Add-ADResourcePropertyListMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adresourcepropertylistmember?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-ADResourcePropertyListMember - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/add-adresourcepropertylistmember?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-ADResourcePropertyListMember: stage additions to adresource property list member with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/add-adresourcepropertylistmember-stage-additions-to-adresource-property-list-member-with-rollback/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerConditionalForwarderZone: stage additions to dns server conditional forwarder zone with rollback checks > Use Add-DnsServerConditionalForwarderZone to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverconditionalforwarderzone-stage-additions-to-dns-server-conditional-forwarder-zone-with/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:44+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerConditionalForwarderZone to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerConditionalForwarderZone ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Add-DnsServerConditionalForwarderZone: stage additions to dns server conditional forwarder zone with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerConditionalForwarderZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverconditionalforwarderzone?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Add-DnsServerConditionalForwarderZone cmdlet adds a conditional forwarder to a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can select the master servers, forwarder time-out, recursion, host computer, replication scope, and directory partition for the conditional forwarder.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; DESCRIPTION. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-222 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Add-DnsServerConditionalForwarderZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverconditionalforwarderzone?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerConditionalForwarderZone - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverconditionalforwarderzone?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerConditionalForwarderZone: stage additions to dns server conditional forwarder zone with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverconditionalforwarderzone-stage-additions-to-dns-server-conditional-forwarder-zone-with/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerDirectoryPartition: stage additions to dns server directory partition with before-and-after evidence > Use Add-DnsServerDirectoryPartition to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverdirectorypartition-stage-additions-to-dns-server-directory-partition-with-before-and/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:27+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerDirectoryPartition to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerDirectoryPartition ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Add-DnsServerDirectoryPartition: stage additions to dns server directory partition with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerDirectoryPartition](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverdirectorypartition?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Add-DnsServerDirectoryPartition cmdlet creates a Domain Name System (DNS) application directory partition.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “After you install a DNS server, DNS creates an application directory partition for the service at the forest and domain levels.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-239 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Add-DnsServerDirectoryPartition](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverdirectorypartition?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerDirectoryPartition - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverdirectorypartition?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerDirectoryPartition: stage additions to dns server directory partition with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverdirectorypartition-stage-additions-to-dns-server-directory-partition-with-before-and/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerPrimaryZone: stage additions to dns server primary zone against recorded identity and DNS state > Use Add-DnsServerPrimaryZone to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverprimaryzone-stage-additions-to-dns-server-primary-zone-against-recorded-identity-and/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:48+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerPrimaryZone to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerPrimaryZone ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Add-DnsServerPrimaryZone: stage additions to dns server primary zone against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerPrimaryZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverprimaryzone?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Add-DnsServerPrimaryZone cmdlet adds a specified primary zone on a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can add an Active Directory-integrated forward lookup zone, an Active Directory-integrated reverse lookup zone, a file-backed forward lookup zone, or a file-backed reverse lookup zone.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-218 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Add-DnsServerPrimaryZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverprimaryzone?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerPrimaryZone - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverprimaryzone?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerPrimaryZone: stage additions to dns server primary zone against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverprimaryzone-stage-additions-to-dns-server-primary-zone-against-recorded-identity-and/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerQueryResolutionPolicy: stage additions to dns server query resolution policy with before-and-after evidence > Use Add-DnsServerQueryResolutionPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverqueryresolutionpolicy-stage-additions-to-dns-server-query-resolution-policy-with/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:02+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerQueryResolutionPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerQueryResolutionPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Add-DnsServerQueryResolutionPolicy: stage additions to dns server query resolution policy with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerQueryResolutionPolicy](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverqueryresolutionpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Adds a policy for query resolution to a DNS server.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Add-DnsServerQueryResolutionPolicy cmdlet adds a policy for query resolution to a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from SYNOPSIS; DESCRIPTION to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-204 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Add-DnsServerQueryResolutionPolicy](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverqueryresolutionpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerQueryResolutionPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverqueryresolutionpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerQueryResolutionPolicy: stage additions to dns server query resolution policy with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverqueryresolutionpolicy-stage-additions-to-dns-server-query-resolution-policy-with/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerRecursionScope: stage additions to dns server recursion scope with bounded evidence > Use Add-DnsServerRecursionScope to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverrecursionscope-stage-additions-to-dns-server-recursion-scope-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:21+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerRecursionScope to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerRecursionScope ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Add-DnsServerRecursionScope: stage additions to dns server recursion scope with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerRecursionScope](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverrecursionscope?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Add-DnsServerRecursionScope cmdlet adds a recursion scope on a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “Recursion scopes are unique instances of a group of settings that control recursion on a DNS server.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-245 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Add-DnsServerRecursionScope](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverrecursionscope?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerRecursionScope - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverrecursionscope?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerRecursionScope: stage additions to dns server recursion scope with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverrecursionscope-stage-additions-to-dns-server-recursion-scope-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerResourceRecord: stage additions to dns server resource record with bounded evidence > Use Add-DnsServerResourceRecord to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverresourcerecord-stage-additions-to-dns-server-resource-record-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:01+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerResourceRecord to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerResourceRecord ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Add-DnsServerResourceRecord: stage additions to dns server resource record with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerResourceRecord](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresourcerecord?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Adds a resource record of a specified type to a specified DNS zone.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Add-DnsServerResourceRecord cmdlet adds a resource record for a Domain Name System (DNS) zone on a DNS server.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from SYNOPSIS; DESCRIPTION to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-205 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Add-DnsServerResourceRecord](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresourcerecord?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerResourceRecord - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresourcerecord?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerResourceRecord: stage additions to dns server resource record with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverresourcerecord-stage-additions-to-dns-server-resource-record-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerResourceRecordDnsKey: stage additions to dns server resource record dns key with rollback checks > Use Add-DnsServerResourceRecordDnsKey to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverresourcerecorddnskey-stage-additions-to-dns-server-resource-record-dns-key-with/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:39+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerResourceRecordDnsKey to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerResourceRecordDnsKey ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Add-DnsServerResourceRecordDnsKey: stage additions to dns server resource record dns key with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerResourceRecordDnsKey](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresourcerecorddnskey?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Adds a type DNSKEY resource record to a DNS zone.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Add-DnsServerResourceRecordDNSKEY cmdlet adds DNSKEY resource record to a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from SYNOPSIS; DESCRIPTION to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-227 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Add-DnsServerResourceRecordDnsKey](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresourcerecorddnskey?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerResourceRecordDnsKey - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresourcerecorddnskey?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerResourceRecordDnsKey: stage additions to dns server resource record dns key with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverresourcerecorddnskey-stage-additions-to-dns-server-resource-record-dns-key-with/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerResponseRateLimitingExceptionlist: stage additions to dns server response rate limiting exceptionlist with bounded evidence > Use Add-DnsServerResponseRateLimitingExceptionlist to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverresponseratelimitingexceptionlist-stage-additions-to-dns-server-response-rate-limiting/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:51+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerResponseRateLimitingExceptionlist to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerResponseRateLimitingExceptionlist ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Add-DnsServerResponseRateLimitingExceptionlist: stage additions to dns server response rate limiting exceptionlist with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerResponseRateLimitingExceptionlist](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresponseratelimitingexceptionlist?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Add-DnsServerResponseRateLimiting cmdlet adds a Response Rate Limiting (RRL) exception list on the DNS server.” The research record locates this support at DESCRIPTION. - At Example 1: Add a domain to an RRL exception list, Microsoft states: “This command adds an RRL exception for the domain contoso.com.” The research record locates this support at Example 1: Add a domain to an RRL exception list. Keep the evidence boundary at these traced claims. They support a review of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Add a domain to an RRL exception list, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; Example 1: Add a domain to an RRL exception list through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-215 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Add-DnsServerResponseRateLimitingExceptionlist](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresponseratelimitingexceptionlist?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerResponseRateLimitingExceptionlist - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverresponseratelimitingexceptionlist?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerResponseRateLimitingExceptionlist: stage additions to dns server response rate limiting exceptionlist with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverresponseratelimitingexceptionlist-stage-additions-to-dns-server-response-rate-limiting/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerRootHint: stage additions to dns server root hint with rollback checks > Use Add-DnsServerRootHint to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverroothint-stage-additions-to-dns-server-root-hint-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:19+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerRootHint to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerRootHint ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Add-DnsServerRootHint: stage additions to dns server root hint with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerRootHint](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverroothint?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Add-DnsServerRootHint cmdlet adds root hints on a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can add root hints by specifying the DNS name server and IP address, or you can use the InputObject parameter to specify a DnsServerRootHint object.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; DESCRIPTION. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-247 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Add-DnsServerRootHint](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverroothint?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerRootHint - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverroothint?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerRootHint: stage additions to dns server root hint with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverroothint-stage-additions-to-dns-server-root-hint-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerSigningKey: stage additions to dns server signing key with before-and-after evidence > Use Add-DnsServerSigningKey to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserversigningkey-stage-additions-to-dns-server-signing-key-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:32+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerSigningKey to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerSigningKey ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Add-DnsServerSigningKey: stage additions to dns server signing key with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerSigningKey](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserversigningkey?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Add-DnsServerSigningKey cmdlet adds a Key Signing Key (KSK) or Zone Signing Key (ZSK) key to a Domain Name System (DNS) signed zone.” The research record locates this support at DESCRIPTION. - At Example 1: Add a KSK to a DNS zone, Microsoft states: “This command adds a KSK to the DNS signed-zone corp.contoso.com.” The research record locates this support at Example 1: Add a KSK to a DNS zone. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Add a KSK to a DNS zone, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations DESCRIPTION; Example 1: Add a KSK to a DNS zone adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-234 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Add-DnsServerSigningKey](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserversigningkey?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerSigningKey - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserversigningkey?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerSigningKey: stage additions to dns server signing key with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserversigningkey-stage-additions-to-dns-server-signing-key-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerStubZone: stage additions to dns server stub zone with bounded evidence > Use Add-DnsServerStubZone to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverstubzone-stage-additions-to-dns-server-stub-zone-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:46+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerStubZone to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerStubZone ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Add-DnsServerStubZone: stage additions to dns server stub zone with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerStubZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverstubzone?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “A stub zone is a copy of a Domain Name System (DNS) zone that contains only resource records that identify the DNS servers for that zone.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can add either a forward lookup zone or a reverse lookup zone.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-220 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Add-DnsServerStubZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverstubzone?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerStubZone - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverstubzone?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerStubZone: stage additions to dns server stub zone with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverstubzone-stage-additions-to-dns-server-stub-zone-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerTrustAnchor: stage additions to dns server trust anchor under AD/DNS change control > Use Add-DnsServerTrustAnchor to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsservertrustanchor-stage-additions-to-dns-server-trust-anchor-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:35+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerTrustAnchor to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerTrustAnchor ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Add-DnsServerTrustAnchor: stage additions to dns server trust anchor under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerTrustAnchor](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsservertrustanchor?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Add-DnsServerTrustAnchor cmdlet adds a trust anchor (DNSKEY record or DS record) to a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “If no trust anchor is present, the cmdlet creates one.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations DESCRIPTION; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-231 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Add-DnsServerTrustAnchor](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsservertrustanchor?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerTrustAnchor - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsservertrustanchor?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerTrustAnchor: stage additions to dns server trust anchor under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/add-dnsservertrustanchor-stage-additions-to-dns-server-trust-anchor-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerVirtualizationInstance: stage additions to dns server virtualization instance with rollback checks > Use Add-DnsServerVirtualizationInstance to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsservervirtualizationinstance-stage-additions-to-dns-server-virtualization-instance-with/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:54+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerVirtualizationInstance to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerVirtualizationInstance ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Add-DnsServerVirtualizationInstance: stage additions to dns server virtualization instance with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerVirtualizationInstance](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsservervirtualizationinstance?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Add-DnsServerVirtualizationInstance cmdlet adds a virtualization instance to a DNS Server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “A Virtualizaton instance is a logical partition in a DNS Server that is capable of hosting zones and zone scopes independently.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from DESCRIPTION; DESCRIPTION to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-272 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Add-DnsServerVirtualizationInstance](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsservervirtualizationinstance?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerVirtualizationInstance - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsservervirtualizationinstance?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerVirtualizationInstance: stage additions to dns server virtualization instance with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/add-dnsservervirtualizationinstance-stage-additions-to-dns-server-virtualization-instance-with/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerZoneDelegation: stage additions to dns server zone delegation against recorded identity and DNS state > Use Add-DnsServerZoneDelegation to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverzonedelegation-stage-additions-to-dns-server-zone-delegation-against-recorded-identity/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:33+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerZoneDelegation to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerZoneDelegation ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Add-DnsServerZoneDelegation: stage additions to dns server zone delegation against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerZoneDelegation](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverzonedelegation?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Adds a new delegated DNS zone to an existing zone.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Add-DnsServerZoneDelegation cmdlet adds a zone delegation to a Domain Name System (DNS) zone.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-233 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Add-DnsServerZoneDelegation](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverzonedelegation?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerZoneDelegation - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverzonedelegation?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerZoneDelegation: stage additions to dns server zone delegation against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverzonedelegation-stage-additions-to-dns-server-zone-delegation-against-recorded-identity/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Add-DnsServerZoneTransferPolicy: stage additions to dns server zone transfer policy under AD/DNS change control > Use Add-DnsServerZoneTransferPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/add-dnsserverzonetransferpolicy-stage-additions-to-dns-server-zone-transfer-policy-under-ad-dns/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:00+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Add-DnsServerZoneTransferPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Add-DnsServerZoneTransferPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Add-DnsServerZoneTransferPolicy: stage additions to dns server zone transfer policy under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Add-DnsServerZoneTransferPolicy](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverzonetransferpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Add-DnsServerZoneTransferPolicy cmdlet adds a zone transfer policy to a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “A policy determines zone transfers based on criteria that you specify in the policy.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations DESCRIPTION; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-206 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Add-DnsServerZoneTransferPolicy](https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverzonetransferpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Add-DnsServerZoneTransferPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/add-dnsserverzonetransferpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Add-DnsServerZoneTransferPolicy: stage additions to dns server zone transfer policy under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/add-dnsserverzonetransferpolicy-stage-additions-to-dns-server-zone-transfer-policy-under-ad-dns/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Adjust Defender for Identity alert thresholds only after accounting for learning periods > Use Adjust alert thresholds to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/adjust-identity-alert-thresholds-after-learning-periods/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:40+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Adjust alert thresholds to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Adjust alert thresholds ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Adjust Defender for Identity alert thresholds only after accounting for learning periods. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Adjust alert thresholds](https://learn.microsoft.com/en-us/defender-for-identity/advanced-settings) from Microsoft supports the following bounded statements: - Some Defender for Identity alerts use learning periods to build activity profiles and distinguish legitimate from suspicious behavior. The research record locates this support at Threshold behavior explanation. - The Adjust alert thresholds page changes alert volume, and Recommended test mode or Medium or Low settings can trigger alerts immediately even before a learning period completes. The research record locates this support at Threshold customization and trigger behavior. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions only where the source and recorded environment align. ## What the source does not establish Lowering or raising a threshold changes signal volume and can affect false positives or missed detections; document, test, and review every change. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Threshold behavior explanation, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Threshold customization and trigger behavior, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations Threshold behavior explanation; Threshold customization and trigger behavior adjacent to the sanitized artifacts used for comparison. Prefer sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Adjust alert thresholds](https://learn.microsoft.com/en-us/defender-for-identity/advanced-settings) — Microsoft ## Primary reference - Name: Adjust alert thresholds - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/advanced-settings - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Adjust Defender for Identity alert thresholds only after accounting for learning periods,” DSE Security, https://update.dsesecurity.com/updates/adjust-identity-alert-thresholds-after-learning-periods/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Adopt ML-DSA with signature lifecycle and interoperability evidence > FIPS 204 specifies ML-DSA for digital signatures. Production use also depends on formats, identity binding, key protection, verification support, archival needs, revocation, performance, and current errata. - Canonical URL: https://update.dsesecurity.com/updates/ml-dsa-signature-lifecycle-interoperability/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:33:56+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know FIPS 204 specifies ML-DSA for digital signatures. Production use also depends on formats, identity binding, key protection, verification support, archival needs, revocation, performance, and current errata. ## Potentially affected Organizations planning post-quantum signatures for software, documents, devices, protocols, certificates, artifacts, or long-lived verification workflows. ## DSE recommendation Map the complete signature and verification lifecycle, use current supported profiles and implementations, test exact formats and relying parties, monitor errata, and preserve algorithm-agility and rollback. ## Article Bottom line: a signature algorithm is one element of a trust system. Before adopting ML-DSA, identify who signs, how that identity is established, where the private key lives, what exact object and context are signed, who verifies it, how long verification must work, and how keys and algorithms are changed. ## Source fact: what FIPS 204 specifies [FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) specifies ML-DSA, a module-lattice-based set of algorithms for generating and verifying digital signatures. NIST describes digital signatures as mechanisms used to detect unauthorized modification and authenticate the claimed signatory, with potential evidentiary use by a recipient. The standard states that ML-DSA is believed to be secure against an adversary with a large-scale quantum computer. The NIST page included a July 31, 2026 planning note pointing to several minor issues in an errata spreadsheet for correction in a future update or revision. Implementers should review the current errata rather than relying only on the original publication file. ## What the source does not establish FIPS 204 does not bind a public key to a person, organization, device, software publisher, or business authority. It does not protect a private key from theft, define every file or protocol format, preserve a signature and its validation data forever, or certify a product implementation. A verified signature proves only what the validation process and trusted context support. It does not prove that signed content is accurate, safe, authorized for use, or free of malicious behavior. ## Applicability questions - What object, canonical representation, metadata, and context are covered by the signature? - How is the signatory’s public key bound to an identity and authority trusted by each verifier? - Which implementations, parameter sets, formats, certificates, protocols, and relying systems must interoperate? - How are signing keys generated, protected, rotated, recovered if applicable, revoked, and destroyed? - What evidence must remain available years later to validate the signature under the policy in force at signing? ## DSE recommendation: design the relying workflow The following steps are DSE recommendations based on the cited source. - Inventory signature use cases, signers, relying parties, objects, formats, trust anchors, retention periods, legal or contractual needs, and current algorithms. - Select only a current supported profile and implementation. Review FIPS 204, current errata, applicable protocol specifications, and product documentation before approval. - Define key custody and signing authorization separately. Constrain which identity and process can request a signature and which content is presented for approval. - Test exact artifact formats and every required verifier, including error handling, altered data, wrong keys, revoked or retired identities, and mixed-algorithm transition states. - Preserve verification context appropriate to the use case without asserting indefinite validity. Document time, policy, trust material, software versions, and archival dependencies. - Maintain algorithm agility, rollback, and re-signing or migration decisions for long-lived assets. ## Verification and evidence Retain the use-case and trust model, standards and errata review, supported profile, implementation versions, key-ceremony or service evidence, authorization tests, cross-platform verification matrix, negative tests, performance results, archival validation test, approval, and transition plan. ## Official references - [FIPS 204 — Module-Lattice-Based Digital Signature Standard](https://csrc.nist.gov/pubs/fips/204/final) — National Institute of Standards and Technology; published August 13, 2024; review current errata - [NIST FAQ for Post-Quantum Cryptography FIPS](https://csrc.nist.gov/projects/post-quantum-cryptography/faqs) — National Institute of Standards and Technology; living guidance ## Primary reference - Name: FIPS 204 — Module-Lattice-Based Digital Signature Standard - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/fips/204/final - Source publication date: 2024-08-13 ## Citation and use Preferred citation: “Adopt ML-DSA with signature lifecycle and interoperability evidence,” DSE Security, https://update.dsesecurity.com/updates/ml-dsa-signature-lifecycle-interoperability/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Adopt ML-KEM only through supported, testable protocol implementations > FIPS 203 specifies ML-KEM for establishing shared secret keys. Adoption still requires a supported protocol binding, implementation, parameter choice, key lifecycle, interoperability test, and rollback plan. - Canonical URL: https://update.dsesecurity.com/updates/ml-kem-supported-protocol-adoption/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:33:57+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know FIPS 203 specifies ML-KEM for establishing shared secret keys. Adoption still requires a supported protocol binding, implementation, parameter choice, key lifecycle, interoperability test, and rollback plan. ## Potentially affected Organizations planning post-quantum key-establishment changes in products, protocols, services, development roadmaps, or procurement requirements. ## DSE recommendation Inventory long-lived confidentiality needs and dependencies, follow current protocol and product guidance, test exact implementations and parameters, monitor errata, and avoid claiming quantum-safe operation from an algorithm name alone. ## Article Bottom line: FIPS 203 standardizes a key-encapsulation mechanism; it does not by itself define how every application or protocol should deploy it. Use ML-KEM only through a current, supported implementation and protocol design whose interoperability, performance, key handling, downgrade behavior, and recovery have been tested. ## Source fact: what FIPS 203 specifies [FIPS 203](https://csrc.nist.gov/pubs/fips/203/final) specifies ML-KEM, a module-lattice-based key-encapsulation mechanism. NIST explains that a KEM can, under specified conditions, allow two parties to establish a shared secret over a public channel, after which symmetric cryptography can support functions such as encryption and authentication. The standard defines three ML-KEM parameter sets. The NIST page included a November 17, 2025 planning note identifying an issue intended for correction in a future update or revision and pointing readers to an errata spreadsheet. That visible maintenance status should be included in implementation review. ## What the source does not establish FIPS 203 does not certify a product implementation, protocol integration, key-management design, or production deployment. “Uses ML-KEM” does not establish that negotiation resists downgrade, that randomness and implementation are sound, that shared secrets are handled correctly, or that the application protects data after key establishment. The standard also does not mean every system must migrate on the same schedule. Priority depends on data confidentiality lifetime, exposure, protocol roadmaps, supplier support, regulatory or contractual direction, performance, and the ability to update again. ## Applicability questions - Which data must remain confidential for long enough that future cryptanalytic capability matters to the decision? - Which exact protocol or product profile defines how ML-KEM is negotiated and combined with other mechanisms? - Which parameter set and implementation are supported by every required endpoint and intermediary? - How are randomness, shared secrets, identities, certificates, logging, and failure handled? - Can the organization detect downgrade, interoperate during transition, revoke a release, and return to a known supported state? ## DSE recommendation: move through supported layers The following steps are DSE recommendations based on the cited source. - Inventory cryptographic use, data lifetime, endpoints, protocols, libraries, appliances, suppliers, and replacement constraints. Identify the systems that cannot change quickly. - Follow the current protocol, regulator, platform, and vendor documentation for integration. Do not design an ad hoc wire format or claim conformance from the primitive alone. - Review the current FIPS 203 page and errata before design approval and release. Record the document and implementation versions used. - Test exact endpoint combinations for negotiation, parameter selection, failure, performance, monitoring, key lifecycle, interoperability, and downgrade behavior. - Stage adoption with bounded pilots, measurable success criteria, and rollback. Preserve classical or hybrid behavior only as directed by the applicable protocol and supplier guidance. - Document the limited claim supported by evidence: algorithm, implementation, protocol, versions, configuration, and test date. ## Verification and evidence Retain the cryptographic inventory, data-lifetime rationale, standards and errata review, protocol profile, supplier support statement, implementation version, parameter and configuration record, interoperability matrix, performance and failure results, downgrade tests, approval, and rollback evidence. ## Official references - [FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://csrc.nist.gov/pubs/fips/203/final) — National Institute of Standards and Technology; published August 13, 2024; review current errata - [NIST Post-Quantum Cryptography project](https://csrc.nist.gov/projects/post-quantum-cryptography) — National Institute of Standards and Technology; living project page ## Primary reference - Name: FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/fips/203/final - Source publication date: 2024-08-13 ## Citation and use Preferred citation: “Adopt ML-KEM only through supported, testable protocol implementations,” DSE Security, https://update.dsesecurity.com/updates/ml-kem-supported-protocol-adoption/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Advertise BGP capabilities in OPEN before using an optional feature > Use RFC 5492 — Capabilities Advertisement with BGP-4 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/advertise-bgp-capabilities-in-open-before-using-an-optional-feature/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:44+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 5492 — Capabilities Advertisement with BGP-4 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 5492 — Capabilities Advertisement with BGP-4 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Advertise BGP capabilities in OPEN before using an optional feature. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 5492 — Capabilities Advertisement with BGP-4](https://www.rfc-editor.org/rfc/rfc5492.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A BGP speaker advertises supported capabilities in the Capabilities Optional Parameter of its OPEN message. The research record locates this support at Section 3 (Overview of Operations). - A capability may be used on a peering only after both peers have advertised support for it. The research record locates this support at Section 3 (Overview of Operations), bilateral advertisement rule. - An unrecognized received capability must be ignored; it must not trigger an Unsupported Capability notification or terminate the session. The research record locates this support at Sections 3 (Overview of Operations) and 5 (Extensions to Error Handling). Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 3 (Overview of Operations), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Overview of Operations), bilateral advertisement rule, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 3 (Overview of Operations) and 5 (Extensions to Error Handling), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from Section 3 (Overview of Operations); Section 3 (Overview of Operations), bilateral advertisement rule; Sections 3 (Overview of Operations) and 5 (Extensions to Error Handling) to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 5492 — Capabilities Advertisement with BGP-4](https://www.rfc-editor.org/rfc/rfc5492.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 5492 — Capabilities Advertisement with BGP-4 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5492.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Advertise BGP capabilities in OPEN before using an optional feature,” DSE Security, https://update.dsesecurity.com/updates/advertise-bgp-capabilities-in-open-before-using-an-optional-feature/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Advertise OSPF maximum metrics when a router must remain non-transit > Use RFC 6987 — OSPF Stub Router Advertisement to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/advertise-ospf-maximum-metrics-when-a-router-must-remain-non-transit/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:43+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6987 — OSPF Stub Router Advertisement to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6987 — OSPF Stub Router Advertisement ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Advertise OSPF maximum metrics when a router must remain non-transit. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6987 — OSPF Stub Router Advertisement](https://www.rfc-editor.org/rfc/rfc6987.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An OSPF router that must remain reachable but avoid transit advertises MaxLinkMetric on every non-stub link in its router-LSA. The research record locates this support at Section 2 (Solutions). - MaxLinkMetric is the 16-bit all-ones value 0xffff and signals that the advertised link should not carry transit traffic. The research record locates this support at Section 3 (Maximum Link Metric). - Unlike clearing the OSPF R-bit, MaxLinkMetric can leave the router usable as transit when it is the only remaining path. The research record locates this support at Section 4 (Deployment Considerations). Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 2 (Solutions), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Maximum Link Metric), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4 (Deployment Considerations), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Section 2 (Solutions); Section 3 (Maximum Link Metric); Section 4 (Deployment Considerations) to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 6987 — OSPF Stub Router Advertisement](https://www.rfc-editor.org/rfc/rfc6987.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6987 — OSPF Stub Router Advertisement - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6987.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Advertise OSPF maximum metrics when a router must remain non-transit,” DSE Security, https://update.dsesecurity.com/updates/advertise-ospf-maximum-metrics-when-a-router-must-remain-non-transit/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Aggregate SMTP TLS policy outcomes into daily JSON reports > Use RFC 8460 — SMTP TLS Reporting to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:09+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8460 — SMTP TLS Reporting to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8460 — SMTP TLS Reporting ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Aggregate SMTP TLS policy outcomes into daily JSON reports. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8460 — SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An SMTP TLS aggregate report is I-JSON containing report metadata, applied policy, aggregate session counts, and optional per-failure details. The research record locates this support at Section 4 (Reporting Schema). - A report should cover one UTC day, and senders should delay delivery to avoid overloading the report processor. The research record locates this support at Section 4.1 (Report Time Frame). - TLS reports may be delivered as email or by HTTP POST, using the transport-specific formats defined for each route. The research record locates this support at Section 5 (Report Delivery). Only the traced statements above are asserted as source facts. Apply the review to sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 4 (Reporting Schema), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4.1 (Report Time Frame), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5 (Report Delivery), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from Section 4 (Reporting Schema); Section 4.1 (Report Time Frame); Section 5 (Report Delivery) to the observed environment. Useful domain evidence includes sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 8460 — SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8460 — SMTP TLS Reporting - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8460.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Aggregate SMTP TLS policy outcomes into daily JSON reports,” DSE Security, https://update.dsesecurity.com/updates/aggregate-smtp-tls-policy-outcomes-into-daily-json-reports/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Align Azure Update Manager schedules with each machine's patch orchestrator > Azure Update Manager scheduled patching uses maintenance configurations and requires compatible machine orchestration; a visible schedule can fail to patch a machine whose orchestration state does not match. - Canonical URL: https://update.dsesecurity.com/updates/azure-update-manager-schedule-orchestration-alignment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:56+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 2 minutes ## What you need to know Azure Update Manager scheduled patching uses maintenance configurations and requires compatible machine orchestration; a visible schedule can fail to patch a machine whose orchestration state does not match. ## Potentially affected Azure virtual machines and Azure Arc-enabled servers managed through Azure Update Manager. ## DSE recommendation Inventory machine type and orchestration mode, set supported customer-managed scheduling, test maintenance scope and classifications, and reconcile deployment logs with guest patch state. ## Article Bottom line: Azure Update Manager can assess and install updates immediately or through a recurring maintenance configuration. Microsoft documents patch-orchestration prerequisites for scheduled patching. A schedule assigned in Azure is not proof that a guest received, installed, and successfully restarted for the intended updates. ## Source fact: what Microsoft documents Microsoft’s [Update Manager orchestration guide](https://learn.microsoft.com/en-us/azure/update-manager/updates-maintenance-schedules) describes automatic VM guest patching, hotpatching where applicable, Windows automatic updates, and scheduled patching. Azure Update Manager uses maintenance configurations for recurring schedules. For Azure VMs, Microsoft says scheduled patching requires the patch orchestration property to be set to Customer Managed Schedules. The page warns that failing to align orchestration can cause schedules not to patch the VMs. Azure Arc-enabled servers have a different support boundary; the document states that several Azure VM automatic orchestration options are not supported for Arc-enabled servers. Classification, timing, assessment, reboot, guest configuration, and maintenance scope all influence the observed result. ## What the source does not establish A compliant Azure assignment does not guarantee the package installed, the guest rebooted, the application recovered, or a vendor supports the patch. Update Manager does not determine the business maintenance window, workload failover order, application validation, or rollback. Assessment results can change as repositories, classifications, supersedence, and machine connectivity change. ## Applicability questions - Is each machine an Azure VM or Arc-enabled server, and which Windows or Linux patch mode applies? - What is the current patch orchestration property and who else manages updates inside the guest? - Which classifications, repositories, exclusions, hotpatch support, reboot behavior, and maintenance window are intended? - Are availability sets, zones, clusters, load balancers, databases, and application dependencies sequenced safely? - How does an offline, failed, or long-running machine reenter the update process? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Inventory machine type, OS, patch source, orchestration mode, maintenance assignment, owner, and workload consequence. - Align Azure VM orchestration with Microsoft’s scheduled-patching prerequisite and document the distinct Arc behavior. - Pilot maintenance configurations with explicit scope, classifications, window, reboot choice, and exclusions. Avoid dynamic scope without owner and preview controls. - Coordinate drain, failover, application stop and start, backup, and post-update validation outside the patch engine where required. - Reconcile assessment, deployment, guest package state, reboot state, and application health after every run. ## Verification and evidence - Preserve machine inventory, orchestration property, maintenance configuration, scope, classification, window, and approval. - Capture assessment and deployment logs plus guest OS evidence of installed updates and restart. - Record service drain, client transaction, application health, and recovery tests. - Alert on machines with missed, failed, stale, or conflicting orchestration and track them to verified closure. ## Official references - [Update options and orchestration in Azure Update Manager](https://learn.microsoft.com/en-us/azure/update-manager/updates-maintenance-schedules) — Microsoft ## Primary reference - Name: Update options and orchestration in Azure Update Manager - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/update-manager/updates-maintenance-schedules - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Align Azure Update Manager schedules with each machine's patch orchestrator,” DSE Security, https://update.dsesecurity.com/updates/azure-update-manager-schedule-orchestration-alignment/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Align extinguisher placement, inspection, and training with the response policy > Extinguishers, evacuation policy, employee expectations, hazard selection, monthly visual inspections, annual maintenance, and training must describe the same operating model. A mounted cylinder alone does not establish readiness. - Canonical URL: https://update.dsesecurity.com/updates/align-extinguisher-readiness-with-response-policy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:13:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity - Reading time: 4 minutes ## What you need to know Extinguishers, evacuation policy, employee expectations, hazard selection, monthly visual inspections, annual maintenance, and training must describe the same operating model. A mounted cylinder alone does not establish readiness. ## Potentially affected Workplaces with portable fire extinguishers, employees expected or permitted to use them, evacuation-only locations, designated response personnel, extinguisher vendors, safety coordinators, inspections, and training records. ## DSE recommendation Choose and document the employee fire-response policy, verify extinguisher type and distribution for actual hazards, conduct monthly visual inspections and annual maintenance, control post-use service, and train the people whose role includes use. ## Article ## Source facts: the equipment and the employee policy are connected OSHA’s [29 CFR 1910.157](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.157) applies to the placement, use, maintenance, and testing of portable fire extinguishers provided for employee use in general industry. The rule contains different provisions for workplaces where extinguishers are available for employee use, where only designated employees may use them, and where a compliant written policy requires immediate total evacuation and extinguishers are not made available, subject to other applicable requirements. Where provided, approved extinguishers must be mounted, located, and identified so they are readily accessible without exposing employees to possible injury. Distribution depends on the class and extent of anticipated fire hazards. OSHA requires visual inspection monthly and an annual maintenance check, with the annual maintenance date recorded. Hydrostatic test intervals vary by extinguisher type, and damaged or corroded units can require testing sooner. When extinguishers are provided for employee use, OSHA requires education on the general principles of use and hazards of incipient-stage firefighting at initial employment and at least annually. Employees designated to use firefighting equipment under the emergency action plan require equipment-appropriate training initially and annually. Other adopted fire codes, hazard-specific OSHA rules, insurer requirements, and the authority having jurisdiction may add requirements. ## DSE recommendation: make one coherent extinguisher operating model Start with the emergency policy. State whether all employees evacuate, whether a named group may use extinguishers, or whether trained employees may choose to address an incipient-stage fire under defined conditions. Align the emergency action plan, signs, orientation, drills, equipment availability, and supervisor expectations. No employee should discover during smoke or alarm that management assumed a different role. - Build a qualified hazard inventory. Map ordinary combustibles, flammable liquids, energized electrical equipment, commercial cooking, combustible metals, lithium-ion battery concentrations, and special hazards. Have the responsible fire-protection or safety professional select approved equipment, ratings, locations, and travel distances for the actual occupancy and applicable rules. - Inspect the location monthly. Confirm the extinguisher is present, visible or properly identified, readily accessible, correctly mounted, and not blocked by stock, furniture, doors, carts, displays, or vehicles. Check obvious physical condition, operating instructions, tamper indication, pressure indication where provided, and whether the hazard or room use changed. Follow the manufacturer and applicable standard for the exact inspection criteria. - Control maintenance separately. Track annual maintenance, hydrostatic testing, internal maintenance where applicable, agent or component recalls, and replacement units. Use qualified service providers. A monthly visual check is not annual maintenance, and a service tag is not proof the path to the extinguisher remains clear. - Treat any discharge as an event. Remove used or partially discharged equipment from readiness, provide suitable temporary coverage, arrange qualified recharge or replacement, investigate why it was used, and restore the cabinet, mount, seal, and record. Do not return a cylinder because it still feels heavy. - Teach decision boundaries. Training should cover alarm and notification, evacuation priority, the organization’s authorization, incipient-stage limitations, extinguisher selection, escape path, smoke and toxic exposure, when not to fight, and how to report any use. Practical instruction must be controlled by qualified personnel and consistent with the site plan. - Exercise the handoffs. Test how an employee reports a missing or discharged unit, how facilities supplies temporary protection, how a contractor documents service, and how safety verifies restoration. Include nights, weekends, remote spaces, vehicles, and leased areas where ownership is often unclear. Keep an inventory with identifier, location, type and rating, responsible owner, monthly inspection, annual maintenance, hydrostatic-test status, defects, temporary replacement, and closure evidence. Trend blocked units, damaged cabinets, repeated seal failures, late maintenance, changing hazards, and training gaps. Do not use this checklist to decide that a particular extinguisher, placement, or employee response is compliant. That determination belongs to the applicable authorities and qualified professionals. DSE’s operating objective is narrower and practical: the written response policy, installed equipment, inspection evidence, maintenance, and employee behavior must all agree before the first alarm. ## Official references - Occupational Safety and Health Administration, [29 CFR 1910.157, Portable fire extinguishers](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.157). - OSHA, [Portable Fire Extinguishers: Fire Extinguisher Use](https://www.osha.gov/etools/evacuation-plans-procedures/emergency-standards/portable-extinguishers/use). ## Primary reference - Name: OSHA 29 CFR 1910.157: Portable Fire Extinguishers - Authority: Occupational Safety and Health Administration - URL: https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.157 - Source publication date: 2002-11-07 ## Citation and use Preferred citation: “Align extinguisher placement, inspection, and training with the response policy,” DSE Security, https://update.dsesecurity.com/updates/align-extinguisher-readiness-with-response-policy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Allocate BGP Large Community fields before encoding policy > Use RFC 8092 — BGP Large Communities Attribute to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/allocate-bgp-large-community-fields-before-encoding-policy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:42+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8092 — BGP Large Communities Attribute to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8092 — BGP Large Communities Attribute ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Allocate BGP Large Community fields before encoding policy. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8092 — BGP Large Communities Attribute](https://www.rfc-editor.org/rfc/rfc8092.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A BGP Large Community is a 12-octet value containing a four-octet Global Administrator and two four-octet operator-defined local fields. The research record locates this support at Section 3 (BGP Large Communities Attribute). - The Global Administrator should be an ASN whose owner defines the two local fields; reserved ASNs are not recommended for that role. The research record locates this support at Section 3 (BGP Large Communities Attribute), field allocation. - The attribute is malformed only when its nonzero length is not a multiple of 12; duplicate values are removed and do not make it malformed. The research record locates this support at Section 6 (Error Handling). Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 3 (BGP Large Communities Attribute), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (BGP Large Communities Attribute), field allocation, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 6 (Error Handling), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Section 3 (BGP Large Communities Attribute); Section 3 (BGP Large Communities Attribute), field allocation; Section 6 (Error Handling) to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 8092 — BGP Large Communities Attribute](https://www.rfc-editor.org/rfc/rfc8092.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8092 — BGP Large Communities Attribute - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8092.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Allocate BGP Large Community fields before encoding policy,” DSE Security, https://update.dsesecurity.com/updates/allocate-bgp-large-community-fields-before-encoding-policy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Allocate cloud cost before asking teams to optimize it > Cloud optimization requests fail when spend cannot be tied to an accountable product, service, environment, or owner. Build allocation rules, metadata compliance, and explicit shared-cost treatment before setting savings targets. - Canonical URL: https://update.dsesecurity.com/updates/finops-cloud-cost-allocation-ownership/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:59:00+00:00 - Modified: 2026-08-11T14:48:24+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Cloud optimization requests fail when spend cannot be tied to an accountable product, service, environment, or owner. Build allocation rules, metadata compliance, and explicit shared-cost treatment before setting savings targets. ## Potentially affected Public-cloud accounts, subscriptions, projects, resource groups, services, billing exports, discounts, commitments, shared platforms, network and security services, finance, engineering, product owners, and procurement. ## DSE recommendation Define allocation dimensions and owners, map existing account hierarchy, enforce required metadata at provisioning, publish unallocated and shared-cost treatment, reconcile billing data, and establish showback before optimization targets. ## Article ## Source facts: allocation creates accountability for cost and usage The [FinOps Foundation Allocation capability](https://www.finops.org/framework/capabilities/allocation/) defines allocation as the strategies used to assign and share technology cost and usage through accounts, tags, labels, hierarchy, and other metadata. Its purpose is to give product managers, engineers, finance, and other stakeholders a transparent view of the costs for which they are responsible. The framework identifies three connected strategies. An allocation strategy maps costs into the organization’s reporting dimensions. A tagging and hierarchy strategy defines naming, accounts, projects, subscriptions, resource groups, tags, labels, and derived metadata. A shared-cost strategy determines how common services—such as central networking, security tooling, support, or platforms—are funded or apportioned. Allocation does not require every cost to be split with false precision. The Foundation describes direct mapping, fixed or proportional shared allocation, proxy metrics based on usage, and an explicit “informed ignore” decision in which some shared cost remains centrally funded. The appropriate detail increases with the decision the organization needs to make. Showback, chargeback, budgets, forecasts, and unit economics all depend on consistent definitions rather than a universal tag applied without context. Useful measures in the framework include the percentage of cost allocated directly, unallocated cost percentage, metadata compliance, stakeholder notifications for missing data, and response time to investigate unidentified spend. These measures treat allocation as an operating capability, not a one-time cleanup of a monthly invoice. ## DSE recommendation: make ownership resolvable from every billing line Start with the questions leaders actually need answered: cost by business unit, customer-facing product, application, environment, technical owner, cost center, or lifecycle. Create a controlled dictionary for each dimension, including valid values, system of record, owner, and effective date. Do not ask engineering teams to populate fields that finance and product leadership have not defined. - Map high-level containers first. Assign every cloud account, subscription, project, management group, folder, and billing profile to an owner and purpose. This immediately allocates large portions of spend and provides a fallback when resource-level metadata is absent. - Define minimum resource metadata. Require stable identifiers such as application or service ID, environment, owner group, cost center, and data or criticality class where useful. Prefer directory groups and service records over a person’s display name, which becomes stale after role changes. - Enforce near creation. Add policy, infrastructure-as-code validation, catalog defaults, and deployment checks that prevent or rapidly flag missing values. Preserve original provider billing data and store any enrichment rules separately so allocations remain explainable. - Name shared-cost policy. List every meaningful shared pool and choose central funding, equal split, proportional spend, measured consumption, or another approved driver. Document who benefits, who approves the method, how discounts and commitments are handled, and when the rule is reviewed. - Reconcile the ledger. Confirm that allocated, shared, tax, support, adjustment, credit, and unallocated amounts total the authoritative bill for the same period and cost basis. Avoid mixing list, amortized, and effective cost in a single comparison. - Publish showback before chargeback. Give owners time to challenge mappings, fix metadata, and understand shared allocation before financial transfers depend on the report. Track disputes to the underlying rule rather than editing a dashboard total by hand. Set optimization targets only after owners can reproduce their baseline. Track total allocation coverage, direct versus derived allocation, unallocated age, metadata-policy compliance, shared-cost percentage, dispute count, and reconciliation variance. Savings should be measured against an agreed cost basis and paired with service, performance, security, and resilience guardrails. Allocation does not save money by itself; it makes the person who can safely change consumption visible and gives that person a trustworthy number to act on. ## Official references - FinOps Foundation, [Allocation](https://www.finops.org/framework/capabilities/allocation/), living FinOps Framework guidance reviewed August 11, 2026. ## Primary reference - Name: FinOps Foundation Framework: Allocation - Authority: www.finops.org - URL: https://www.finops.org/framework/capabilities/allocation/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Allocate cloud cost before asking teams to optimize it,” DSE Security, https://update.dsesecurity.com/updates/finops-cloud-cost-allocation-ownership/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Allocate finite VMQ resources to the intended Hyper-V interfaces > Which interfaces should receive VMQ priority when hardware queue capacity is limited? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-166-allocate-finite-vmq-resources-to-the-intended-hyper-v-interfaces/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:25+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which interfaces should receive VMQ priority when hardware queue capacity is limited? ## Potentially affected Administrators evaluating VMQ-capable physical adapters on Hyper-V hosts. ## DSE recommendation Compare the available queues with the interfaces requesting them. ## Article ## Source facts VMQ uses hardware filtering to deliver external packet data to virtual adapters. On supported hardware, a requesting virtual adapter receives a dedicated physical-adapter queue. Not every adapter supports VMQ, and supported adapters have a finite, hardware-dependent queue count. Microsoft checks support and count with Get-NetAdapterVmq. Its recommendation increases VMQ weight for interfaces with heavy inbound traffic, such as storage or migration interfaces. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/failover-cluster-network-recommendations). ## Applicability Identify the physical adapters, driver capabilities, virtual interfaces, current weights, and actual inbound workload. Review VMQ support for the installed platform rather than assuming every host has the same queue inventory. ## DSE recommendation Compare the available queues with the interfaces requesting them. Have the virtualization owner identify which measured inbound workloads justify priority, and preserve the current weights before adjustment. Keep queue allocation separate from a bandwidth cap or an RSS processor-profile change. ## Verification Inspect the resulting queue allocation while representative inbound workloads run. Compare host processing and application behavior with the baseline, recording which interfaces receive queues. Resolve a missing queue or unexpected allocation before copying the weight settings to other hosts with different adapters. ## Official references [Microsoft Learn: Network recommendations for a Hyper-V cluster](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/failover-cluster-network-recommendations). Source reviewed September 8, 2026. ## Primary reference - Name: Network recommendations for a Hyper-V cluster - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/failover-cluster-network-recommendations - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Allocate finite VMQ resources to the intended Hyper-V interfaces,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-166-allocate-finite-vmq-resources-to-the-intended-hyper-v-interfaces/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Allocate Hyper-V CPU groups with a shared budget in mind > How should a CPU-group allocation be tested when virtual machines compete for processor time? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-032-allocate-hyper-v-cpu-groups-with-a-shared-budget-in-mind/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:39+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should a CPU-group allocation be tested when virtual machines compete for processor time? ## Potentially affected Use this review when evaluating CPU groups on a supported Hyper-V host. ## DSE recommendation Define the service objective for each group and explain why its virtual machines belong together. ## Article ## Source facts Hyper-V CPU groups provide host processor allocation and isolation controls for guest virtual machines. Microsoft documents CPU-group administration through the Host Compute Service. The hypervisor enforces a computed group cap representing a share of processor capacity. Group members share that budget, and a single active VM can use the entire allocation available to its group. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-cpugroups). ## Applicability Use this review when evaluating CPU groups on a supported Hyper-V host. Identify the intended group members, service classes, and workload priorities. Check the current management interface and requirements before adopting an example configuration. ## DSE recommendation Define the service objective for each group and explain why its virtual machines belong together. Compare expected activity when one member is busy with activity when several members compete. Have workload owners agree on acceptance criteria and on the significance of any competing demand. Record the original group assignments and approved restoration plan before piloting a new allocation. ## Verification Test an individual busy VM and an agreed multi-VM contention scenario. Record the group configuration, host conditions, and application results for both. Verify that the actual membership matches the proposed service classes. Resolve any unexpected performance result before increasing membership or treating a group cap as an application-level guarantee. ## Official references [Microsoft Learn: Virtual Machine Resource Controls](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-cpugroups). Source reviewed September 8, 2026. ## Primary reference - Name: Virtual Machine Resource Controls - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-cpugroups - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Allocate Hyper-V CPU groups with a shared budget in mind,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-032-allocate-hyper-v-cpu-groups-with-a-shared-budget-in-mind/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Allocate one coherent address plan for a Hyper-V NAT host > How should VM and container address ranges be planned for a shared Windows NAT instance? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-190-allocate-one-coherent-address-plan-for-a-hyper-v-nat-host/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:01+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should VM and container address ranges be planned for a shared Windows NAT instance? ## Potentially affected Administrators configuring WinNAT connectivity for Hyper-V VMs and containers. ## DSE recommendation Reserve a host-level address plan that shows the overall internal prefix and the ranges assigned by each service. ## Article ## Source facts Microsoft documents a limit of one NAT network per host in this Hyper-V setup. A VM connects to the NAT network through the internal virtual switch created by the procedure. When VMs and containers share one NAT, the internal prefix must cover their assigned ranges, and the configuration must avoid reusing addresses. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/setup-nat-network). ## Applicability List the VMs, containers, and applications already managing addresses on the host. Inspect existing NAT and switch configuration before adding another network. Review the documented WinNAT limits alongside the intended topology rather than choosing an isolated range for each tool. ## DSE recommendation Reserve a host-level address plan that shows the overall internal prefix and the ranges assigned by each service. Name the owner of every allocation and the procedure for adding another VM or container. Preserve current switch and NAT settings before the pilot. Require an address-collision check before an application is allowed to introduce its own range. ## Verification Verify that each test endpoint uses the intended switch and a unique address inside the approved range. Exercise the required outbound connection from both a VM and a container when both are in scope. Record the effective NAT configuration and any unexpected address assignment before accepting the shared-host design. ## Official references [Microsoft Learn: Set up a NAT network](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/setup-nat-network). Source reviewed September 8, 2026. ## Primary reference - Name: Set up a NAT network - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/setup-nat-network - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Allocate one coherent address plan for a Hyper-V NAT host,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-190-allocate-one-coherent-address-plan-for-a-hyper-v-nat-host/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Answer nearby public chemical-hazard requests and post-accident meeting duties > Use 40 CFR 68.210 - Availability of information to the public to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/answer-nearby-public-chemical-hazard-requests-and-post-accident-meeting-duties/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:51+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.210 - Availability of information to the public to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.210 - Availability of information to the public ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Answer nearby public chemical-hazard requests and post-accident meeting duties. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.210 – Availability of information to the public](https://www.ecfr.gov/current/title-40/section-68.210) from Environmental Protection Agency via eCFR supports the following bounded statements: - A stationary source must hold a public meeting within 90 days after an RMP-reportable accident with a known offsite impact and provide the accident information required by section 68.42(b). The research record locates this support at 40 CFR 68.210(b) (eCFR anchor p-68.210(b)). - A stationary source must provide requested paragraph (d) chemical-hazard information within 45 days and retain records of public requesters for five years. The research record locates this support at 40 CFR 68.210(g) and 68.210(h), read with 40 CFR 68.210(d) (eCFR anchors p-68.210(g) and p-68.210(h)). The source support ends with the statements listed above. Use them to examine essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This is limited to 40 CFR 68.210, including its request eligibility, classified-information, language, and notification conditions. It does not authorize disclosure prohibited by other law. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.210(b) (eCFR anchor p-68.210(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.210(g) and 68.210(h), read with 40 CFR 68.210(d) (eCFR anchors p-68.210(g) and p-68.210(h)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from 40 CFR 68.210(b) (eCFR anchor p-68.210(b)); 40 CFR 68.210(g) and 68.210(h), read with 40 CFR 68.210(d) (eCFR anchors p-68.210(g) and p-68.210(h)) to the observed environment. Useful domain evidence includes business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [40 CFR 68.210 – Availability of information to the public](https://www.ecfr.gov/current/title-40/section-68.210) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.210 - Availability of information to the public - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.210 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Answer nearby public chemical-hazard requests and post-accident meeting duties,” DSE Security, https://update.dsesecurity.com/updates/answer-nearby-public-chemical-hazard-requests-and-post-accident-meeting-duties/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply BGP path selection before advertising a chosen route > Use RFC 4271 — A Border Gateway Protocol 4 (BGP-4) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/apply-bgp-path-selection-before-advertising-a-chosen-route/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:41+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4271 — A Border Gateway Protocol 4 (BGP-4) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4271 — A Border Gateway Protocol 4 (BGP-4) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Apply BGP path selection before advertising a chosen route. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4271 — A Border Gateway Protocol 4 (BGP-4)](https://www.rfc-editor.org/rfc/rfc4271.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - BGP first assigns each feasible received route a policy-derived preference, then selects one best route per destination for the Loc-RIB. The research record locates this support at Sections 9.1.1 (Phase 1) and 9.1.2 (Phase 2). - A route with an unresolvable NEXT_HOP is excluded from selection, and the chosen route is re-evaluated when next-hop reachability or IGP cost changes. The research record locates this support at Section 9.1.2 (Phase 2: Route Selection). - Only after selection does Phase 3 apply per-peer export policy and place eligible routes in each Adj-RIB-Out for advertisement. The research record locates this support at Section 9.1.3 (Phase 3: Route Dissemination). Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Sections 9.1.1 (Phase 1) and 9.1.2 (Phase 2), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 9.1.2 (Phase 2: Route Selection), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 9.1.3 (Phase 3: Route Dissemination), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from Sections 9.1.1 (Phase 1) and 9.1.2 (Phase 2); Section 9.1.2 (Phase 2: Route Selection); Section 9.1.3 (Phase 3: Route Dissemination) to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 4271 — A Border Gateway Protocol 4 (BGP-4)](https://www.rfc-editor.org/rfc/rfc4271.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4271 — A Border Gateway Protocol 4 (BGP-4) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4271.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Apply BGP path selection before advertising a chosen route,” DSE Security, https://update.dsesecurity.com/updates/apply-bgp-path-selection-before-advertising-a-chosen-route/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply cruise-terminal screening rules to covered people, baggage, and property > Use 33 CFR 105.500 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/apply-cruise-terminal-screening-rules-to-covered-people-baggage-and-property/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:44+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.500 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.500 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Apply cruise-terminal screening rules to covered people, baggage, and property. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.500 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.500) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, this subpart establishes cruise ship terminal screening programs within the Facility Security Plans to ensure that prohibited items are not present within the secure areas that have been designated for screened persons, baggage, and personal effects, and are not brought onto cruise ships interfacing with the terminal. The research record locates this support at 33 CFR 105.500(b) (eCFR anchor p-105.500(b)). - Under 33 CFR 105, the rule requires that no later than October 15, 2018, cruise ship terminal owners or operators submit, for each terminal, a terminal screening program (TSP) that conforms with the requirements in section 105.505 to the cognizant COTP for review and approval. The research record locates this support at 33 CFR 105.500(c)(1) (eCFR anchor p-105.500(c)(1)). The source support ends with the statements listed above. Use them to examine credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.500(b) (eCFR anchor p-105.500(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.500(c)(1) (eCFR anchor p-105.500(c)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from 33 CFR 105.500(b) (eCFR anchor p-105.500(b)); 33 CFR 105.500(c)(1) (eCFR anchor p-105.500(c)(1)) to the observed environment. Useful domain evidence includes approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [33 CFR 105.500 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.500) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.500 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.500 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Apply cruise-terminal screening rules to covered people, baggage, and property,” DSE Security, https://update.dsesecurity.com/updates/apply-cruise-terminal-screening-rules-to-covered-people-baggage-and-property/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply Defender for Office 365 preset policies without overprotecting the wrong users > Built-in, Standard, and Strict preset security policies provide Microsoft-maintained email-protection settings. Correct licensing, precedence, targeting, quarantine support, and mail-flow testing still matter. - Canonical URL: https://update.dsesecurity.com/updates/defender-office-365-preset-policy-safe-rollout/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:53+00:00 - Modified: 2026-07-19T21:27:53+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Built-in, Standard, and Strict preset security policies provide Microsoft-maintained email-protection settings. Correct licensing, precedence, targeting, quarantine support, and mail-flow testing still matter. ## Potentially affected Exchange Online organizations using built-in email protection, Exchange Online Protection, or Microsoft Defender for Office 365 Plan 1 or Plan 2. ## DSE recommendation Inventory custom threat policies, map licensed recipients, pilot Standard and tightly scoped Strict protection, validate policy precedence and quarantine impact, and expand with support coverage. ## Article ## Source fact: what Microsoft documents Microsoft documents three preset email-protection profiles in cloud organizations: Built-in protection, Standard protection, and Strict protection. Preset policies combine recommended settings across multiple threat policies. Most Standard and Strict settings are not individually configurable because Microsoft maintains the profile. Standard is intended to balance protection and disruption, while Strict uses more aggressive settings for highly targeted or higher-risk users. Built-in protection provides baseline Safe Links and Safe Attachments coverage for eligible cloud-mailbox recipients who are not otherwise covered by Standard, Strict, or custom Safe Links and Safe Attachments policies. Policy precedence determines which settings apply when assignments overlap. Microsoft documents up to 350 protected users for user-impersonation protection in Standard or Strict. Mailbox intelligence provides other impersonation protection, but previous sender-recipient communication can affect user-impersonation behavior. ## Licensing and applicability Built-in and Exchange Online Protection features apply to cloud mailboxes as documented, while Defender for Office 365 features require Plan 1, Plan 2, or another subscription that includes them. If only part of the organization is licensed, Microsoft directs administrators to target eligible recipients and exclude recipients who are not eligible. Available settings, trials, government-cloud behavior, unified RBAC, Exchange role groups, and policy precedence should be confirmed in the current tenant. ## DSE recommendation: production-safe operational steps - Export existing anti-malware, anti-spam, anti-phishing, Safe Links, Safe Attachments, quarantine, transport, and allow/block settings with owners and assignments. - Map each recipient to current Defender licensing. Do not use portal availability as proof that every targeted mailbox has the required entitlement. - Identify high-risk users who need Strict and the administrators who will review and release false positives. Place ordinary pilot users in Standard. - Review policy precedence before assignment. Remove overlapping or contradictory custom targeting only after the effective result is verified. - Configure impersonation targets and trusted senders narrowly. Avoid broad allowlisting that bypasses other detection. - Test legitimate automated senders, partner mail, bulk mail, attachments, links, quarantine notifications, user submissions, administrator release, and message trace. - Measure false positives, quarantine volume, release time, user reports, and confirmed detections before expanding. Maintain a rollback assignment and staffed support path. DSE recommends documenting why a custom policy remains when a preset profile is available. Some applications have valid delivery needs, but a customization should be the narrowest supported exception with an owner and review date. Because Microsoft can update preset recommendations, revalidate business-critical mail flows after documented service changes. A successful rollout protects every intended licensed recipient, keeps high-impact review work supportable, and retains evidence that important business mail still flows. A higher quarantine count by itself is not proof of better protection. ## Official reference [Preset security policies in cloud organizations](https://learn.microsoft.com/en-us/defender-office-365/preset-security-policies) — profiles, permissions, licensing targeting, configuration, precedence, and validation. ## Primary reference - Name: Microsoft Learn: Preset security policies in cloud organizations - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-office-365/preset-security-policies - Source publication date: 2026-07-03 ## Citation and use Preferred citation: “Apply Defender for Office 365 preset policies without overprotecting the wrong users,” DSE Security, https://update.dsesecurity.com/updates/defender-office-365-preset-policy-safe-rollout/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply DNAME substitution below an owner without aliasing the owner itself > Use RFC 6672 — DNAME Redirection in the DNS to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/apply-dname-substitution-below-an-owner-without-aliasing-the-owner-itself/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:55+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6672 — DNAME Redirection in the DNS to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6672 — DNAME Redirection in the DNS ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Apply DNAME substitution below an owner without aliasing the owner itself. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6672 — DNAME Redirection in the DNS](https://www.rfc-editor.org/rfc/rfc6672.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - DNAME substitution replaces only the whole suffix labels that match the DNAME owner with the labels in the DNAME target. The research record locates this support at Section 2.2 (The DNAME Substitution). - A DNAME redirects names below its owner; unlike a CNAME, it does not redirect the DNAME owner name itself. The research record locates this support at Section 2.3 (DNAME Owner Name Matching the QNAME). - When a server applies DNAME substitution, it includes the DNAME and synthesizes a CNAME whose owner is the query name. The research record locates this support at Section 3.1 (CNAME Synthesis). Keep the evidence boundary at these traced claims. They support a review of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2.2 (The DNAME Substitution), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.3 (DNAME Owner Name Matching the QNAME), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 3.1 (CNAME Synthesis), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations Section 2.2 (The DNAME Substitution); Section 2.3 (DNAME Owner Name Matching the QNAME); Section 3.1 (CNAME Synthesis) adjacent to the sanitized artifacts used for comparison. Prefer zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 6672 — DNAME Redirection in the DNS](https://www.rfc-editor.org/rfc/rfc6672.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6672 — DNAME Redirection in the DNS - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6672.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Apply DNAME substitution below an owner without aliasing the owner itself,” DSE Security, https://update.dsesecurity.com/updates/apply-dname-substitution-below-an-owner-without-aliasing-the-owner-itself/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply fine-grained password policy to the intended AD principals > Use Configure fine grained password policies for Active Directory Domain Services in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/apply-fine-grained-password-policy-to-intended-principals/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:18+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Configure fine grained password policies for Active Directory Domain Services in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Configure fine grained password policies for Active Directory Domain Services in Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Apply fine-grained password policy to the intended AD principals. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Configure fine grained password policies for Active Directory Domain Services in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/fine-grained-password-policies) from Microsoft supports the following bounded statements: - Fine-grained password policies allow multiple password and lockout policies within one domain. The research record locates this support at Opening overview. - Different policy restrictions can be applied to different user sets, including stricter settings for privileged accounts. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Scope this brief to AD DS fine-grained policy; it does not cover Microsoft Entra password protection. No current deployment state or change approval follows from the source alone. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Configure fine grained password policies for Active Directory Domain Services in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/fine-grained-password-policies) — Microsoft ## Primary reference - Name: Configure fine grained password policies for Active Directory Domain Services in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/fine-grained-password-policies - Source publication date: 2025-06-16 ## Citation and use Preferred citation: “Apply fine-grained password policy to the intended AD principals,” DSE Security, https://update.dsesecurity.com/updates/apply-fine-grained-password-policy-to-intended-principals/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply non-power-reactor physical-protection requirements to the actual facility > Use 10 CFR 73.60 - Physical protection at non-power reactors to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/apply-non-power-reactor-physical-protection-requirements-to-the-actual-facility/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:41+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.60 - Physical protection at non-power reactors to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.60 - Physical protection at non-power reactors ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Apply non-power-reactor physical-protection requirements to the actual facility. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.60 – Physical protection at non-power reactors](https://www.ecfr.gov/current/title-10/section-73.60) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, in addition to the fixed-site requirements set forth in this section and in section 73.67, the Commission may require, depending on the individual facility and site conditions, any alternate or additional measures deemed necessary to protect against radiological sabotage at non-power reactors licensed to operate at or above a power level of 2 megawatts thermal. The research record locates this support at 10 CFR 73.60(f) (eCFR anchor p-73.60(f)). - Under 10 CFR 73, the rule requires that intrusion alarms, physical barriers, and other devices used for material protection be maintained in operable condition. The research record locates this support at 10 CFR 73.60(d)(1) (eCFR anchor p-73.60(d)(1)). Only the traced statements above are asserted as source facts. Apply the review to access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths after confirming that the source and deployed context match. ## What the source does not establish NRC regulation for defined non-power reactors; material, facility, license conditions, exemptions, plans, and protected security information require qualified review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.60(f) (eCFR anchor p-73.60(f)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.60(d)(1) (eCFR anchor p-73.60(d)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to 10 CFR 73.60(f) (eCFR anchor p-73.60(f)); 10 CFR 73.60(d)(1) (eCFR anchor p-73.60(d)(1)) and to observable material such as asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [10 CFR 73.60 – Physical protection at non-power reactors](https://www.ecfr.gov/current/title-10/section-73.60) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.60 - Physical protection at non-power reactors - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.60 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Apply non-power-reactor physical-protection requirements to the actual facility,” DSE Security, https://update.dsesecurity.com/updates/apply-non-power-reactor-physical-protection-requirements-to-the-actual-facility/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply passenger and ferry facility controls to unattended vehicles and screening areas > Use 33 CFR 105.285 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/apply-passenger-and-ferry-facility-controls-to-unattended-vehicles-and-screening-areas/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:03+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.285 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.285 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Apply passenger and ferry facility controls to unattended vehicles and screening areas. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.285 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.285) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, passenger and ferry facilities must segregate unchecked people and personal effects from those already checked. The research record locates this support at 33 CFR 105.285(a)(1), read with 33 CFR 105.285(a) (eCFR anchor p-105.285(a)(1)). - Under 33 CFR 105, passenger and ferry facilities must screen unaccompanied vehicles before loading them on passenger vessels. The research record locates this support at 33 CFR 105.285(a)(3), read with 33 CFR 105.285(a) (eCFR anchor p-105.285(a)(3)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths and the conditions the source actually describes. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.285(a)(1), read with 33 CFR 105.285(a) (eCFR anchor p-105.285(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.285(a)(3), read with 33 CFR 105.285(a) (eCFR anchor p-105.285(a)(3)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations 33 CFR 105.285(a)(1), read with 33 CFR 105.285(a) (eCFR anchor p-105.285(a)(1)); 33 CFR 105.285(a)(3), read with 33 CFR 105.285(a) (eCFR anchor p-105.285(a)(3)) adjacent to the sanitized artifacts used for comparison. Prefer asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [33 CFR 105.285 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.285) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.285 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.285 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Apply passenger and ferry facility controls to unattended vehicles and screening areas,” DSE Security, https://update.dsesecurity.com/updates/apply-passenger-and-ferry-facility-controls-to-unattended-vehicles-and-screening-areas/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply Safeguards Information marking and reproduction controls to every copy > Use 10 CFR 73.22 - Protection of Safeguards Information: Specific requirements to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/apply-safeguards-information-marking-and-reproduction-controls-to-every-copy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:53+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.22 - Protection of Safeguards Information: Specific requirements to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.22 - Protection of Safeguards Information: Specific requirements ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Apply Safeguards Information marking and reproduction controls to every copy. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.22 – Protection of Safeguards Information: Specific requirements](https://www.ecfr.gov/current/title-10/section-73.22) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, documents or other matter containing Safeguards Information, when transmitted outside an authorized place of use or storage, must be packaged in two sealed envelopes or wrappers to preclude disclosure of the presence of protected information. The research record locates this support at 10 CFR 73.22(f)(1) (eCFR anchor p-73.22(f)(1)). - Under 10 CFR 73, safeguards Information may be reproduced to the minimum extent necessary consistent with need without permission of the originator. The research record locates this support at 10 CFR 73.22(e) (eCFR anchor p-73.22(e)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths and the conditions the source actually describes. ## What the source does not establish NRC regulation governing protected information; the brief must avoid reproducing protected operational details and must be reviewed by authorized security and legal personnel. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 10 CFR 73.22(f)(1) (eCFR anchor p-73.22(f)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.22(e) (eCFR anchor p-73.22(e)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from 10 CFR 73.22(f)(1) (eCFR anchor p-73.22(f)(1)); 10 CFR 73.22(e) (eCFR anchor p-73.22(e)) to the observed environment. Useful domain evidence includes asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [10 CFR 73.22 – Protection of Safeguards Information: Specific requirements](https://www.ecfr.gov/current/title-10/section-73.22) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.22 - Protection of Safeguards Information: Specific requirements - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.22 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Apply Safeguards Information marking and reproduction controls to every copy,” DSE Security, https://update.dsesecurity.com/updates/apply-safeguards-information-marking-and-reproduction-controls-to-every-copy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply secure-development practices to the AI model lifecycle, not only the application > NIST's SSDF community profile adds AI-model-specific considerations to the broader secure-development framework. Include data, model, evaluation, release, integration, and response paths in scope. - Canonical URL: https://update.dsesecurity.com/updates/ai-model-secure-development-lifecycle/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:11+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know NIST's SSDF community profile adds AI-model-specific considerations to the broader secure-development framework. Include data, model, evaluation, release, integration, and response paths in scope. ## Potentially affected Producers, integrators, acquirers, and operators of generative AI or dual-use foundation models and the systems that depend on them. ## DSE recommendation Extend secure-development ownership and evidence across model data, artifacts, evaluations, dependencies, releases, integrations, monitoring, and withdrawal; do not treat the model as an opaque dependency outside change control. ## Article Bottom line: an AI-enabled application can inherit risk from the model and its development lifecycle even when the surrounding application follows conventional secure-development practices. Treat model data, code, weights, evaluations, packaging, release, integration, monitoring, and retirement as governed production assets. ## Source fact: what the NIST profile adds [NIST SP 800-218A](https://csrc.nist.gov/pubs/sp/800/218/a/final) is a community profile that augments the practices and tasks in SSDF version 1.1 with AI-model-specific practices, tasks, recommendations, considerations, notes, and references. NIST identifies producers of AI models, producers of systems that use those models, and acquirers of those systems as intended audiences. The profile is designed to be used together with SP 800-218, not as a replacement for it. The publication’s scope is generative AI and dual-use foundation model development across the software development lifecycle. That supports widening normal software-assurance work to include model-specific assets and processes. ## What the source does not establish The profile does not certify a model, declare an AI system safe, or guarantee that an evaluation predicts every production behavior. It does not eliminate the need for use-case risk assessment, privacy review, security architecture, human oversight, supplier diligence, or incident response. It also does not establish that every AI feature warrants the same controls. Applicability depends on whether the organization develops a model, fine-tunes one, retrieves data for one, integrates an external service, or only consumes a bounded feature—and on what decisions or actions the system can influence. ## Applicability questions - Which party owns the base model, adaptations, data, evaluation harness, application, and operating service? - Which artifacts can change behavior, and how are their versions and provenance recorded? - What sensitive, regulated, customer, or licensed material can enter training, tuning, retrieval, prompts, or logs? - Which evaluations must pass for the intended use, and what conditions fall outside those tests? - How can a model, adapter, tool, data source, or release be disabled or rolled back? ## DSE recommendation: extend the evidence chain The following steps are DSE recommendations based on the cited source. - Draw the complete model-system lifecycle, including data sources, preparation, training or tuning, model registry, evaluations, packaging, external services, retrieval sources, tools, deployment, monitoring, and retirement. - Assign owners and immutable identifiers to consequential artifacts. Record provenance, approvals, dependencies, licenses, integrity checks, and the environment in which an evaluation ran. - Define release criteria tied to the intended use. Include security, privacy, abuse, reliability, and operational tests without presenting any single test as proof of universal safety. - Constrain integrations around the model. Apply current identity and authorization at tool and data boundaries, validate outputs before consequential use, and keep approval outside the model for high-impact actions. - Monitor for changes in behavior, dependencies, provider terms, source permissions, and observed incidents. Give alerts an owner and response path. - Practice withdrawal: revoke access, disable a tool or model version, preserve evidence, restore a prior release, and notify affected owners. ## Verification and evidence Select one production AI feature and trace its model and application versions, data and dependency records, evaluation results, approvals, deployment record, permission tests, monitoring, known limitations, and rollback rehearsal. Record gaps as owned work rather than converting uncertainty into a claim of assurance. ## Official references - [NIST SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models](https://csrc.nist.gov/pubs/sp/800/218/a/final) — National Institute of Standards and Technology; finalized July 26, 2024 - [NIST SP 800-218 — Secure Software Development Framework Version 1.1](https://csrc.nist.gov/pubs/sp/800/218/final) — National Institute of Standards and Technology ## Primary reference - Name: NIST SP 800-218A — Secure Software Development Practices for Generative AI and Dual-Use Foundation Models - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/218/a/final - Source publication date: 2024-07-26 ## Citation and use Preferred citation: “Apply secure-development practices to the AI model lifecycle, not only the application,” DSE Security, https://update.dsesecurity.com/updates/ai-model-secure-development-lifecycle/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply sensitive, Exchange, and honeytoken identity tags for their documented detections > Use Defender for Identity entity tags in Microsoft Defender to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/apply-sensitive-exchange-and-honeytoken-tags-for-documented-detections/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:43+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Defender for Identity entity tags in Microsoft Defender to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Defender for Identity entity tags in Microsoft Defender ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Apply sensitive, Exchange, and honeytoken identity tags for their documented detections. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Defender for Identity entity tags in Microsoft Defender](https://learn.microsoft.com/en-us/defender-for-identity/entity-tags) from Microsoft supports the following bounded statements: - Defender for Identity supports tagging accounts as sensitive or honeytokens and tagging devices as Exchange servers. The research record locates this support at Opening tag overview. - Some detections depend on the sensitive tag, while any sign-in from a tagged honeytoken account triggers an alert. The research record locates this support at Sensitive and honeytoken tag descriptions. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions and the conditions the source actually describes. ## What the source does not establish Tags affect investigation and detection context; validate ownership and avoid normal use of honeytoken accounts. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening tag overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sensitive and honeytoken tag descriptions, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from Opening tag overview; Sensitive and honeytoken tag descriptions to the observed environment. Useful domain evidence includes sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Defender for Identity entity tags in Microsoft Defender](https://learn.microsoft.com/en-us/defender-for-identity/entity-tags) — Microsoft ## Primary reference - Name: Defender for Identity entity tags in Microsoft Defender - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/entity-tags - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Apply sensitive, Exchange, and honeytoken identity tags for their documented detections,” DSE Security, https://update.dsesecurity.com/updates/apply-sensitive-exchange-and-honeytoken-tags-for-documented-detections/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply SRV priority before weight when selecting a service endpoint > Use RFC 2782 — A DNS RR for specifying the location of services (DNS SRV) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/apply-srv-priority-before-weight-when-selecting-a-service-endpoint/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:54+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2782 — A DNS RR for specifying the location of services (DNS SRV) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2782 — A DNS RR for specifying the location of services (DNS SRV) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Apply SRV priority before weight when selecting a service endpoint. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2782 — A DNS RR for specifying the location of services (DNS SRV)](https://www.rfc-editor.org/rfc/rfc2782.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An SRV record identifies a service endpoint with priority, weight, port, and target fields. The research record locates this support at Section The format of the SRV RR. - A client first selects reachable SRV targets with the lowest priority value, then uses weight to choose among targets at that priority. The research record locates this support at Section Usage rules. - Within one priority group, a target’s selection chance is proportional to its weight relative to the sum of that group’s weights. The research record locates this support at Section Usage rules, weighted selection procedure. Keep the evidence boundary at these traced claims. They support a review of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section The format of the SRV RR, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section Usage rules, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section Usage rules, weighted selection procedure, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state and sanitize protected material before retention. ## Verification and evidence Keep the source locations Section The format of the SRV RR; Section Usage rules; Section Usage rules, weighted selection procedure adjacent to the sanitized artifacts used for comparison. Prefer zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 2782 — A DNS RR for specifying the location of services (DNS SRV)](https://www.rfc-editor.org/rfc/rfc2782.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2782 — A DNS RR for specifying the location of services (DNS SRV) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2782.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Apply SRV priority before weight when selecting a service endpoint,” DSE Security, https://update.dsesecurity.com/updates/apply-srv-priority-before-weight-when-selecting-a-service-endpoint/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Apply the IDNA bidirectional rule before accepting right-to-left labels > Use RFC 5893 — Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/apply-the-idna-bidirectional-rule-before-accepting-right-to-left-labels/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:53+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 5893 — Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 5893 — Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Apply the IDNA bidirectional rule before accepting right-to-left labels. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 5893 — Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)](https://www.rfc-editor.org/rfc/rfc5893.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An IDNA label passes the Bidi Rule only if all six conditions in the rule are satisfied. The research record locates this support at Section 2 (The Bidi Rule). - The first character determines direction: R or AL makes an RTL label, while L makes an LTR label. The research record locates this support at Section 2 (The Bidi Rule), condition 1. - An RTL label cannot contain both European-number and Arabic-number Bidi properties. The research record locates this support at Section 2 (The Bidi Rule), condition 4. Keep the evidence boundary at these traced claims. They support a review of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2 (The Bidi Rule), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2 (The Bidi Rule), condition 1, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2 (The Bidi Rule), condition 4, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations Section 2 (The Bidi Rule); Section 2 (The Bidi Rule), condition 1; Section 2 (The Bidi Rule), condition 4 adjacent to the sanitized artifacts used for comparison. Prefer zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 5893 — Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)](https://www.rfc-editor.org/rfc/rfc5893.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 5893 — Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5893.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Apply the IDNA bidirectional rule before accepting right-to-left labels,” DSE Security, https://update.dsesecurity.com/updates/apply-the-idna-bidirectional-rule-before-accepting-right-to-left-labels/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Ask cybersecurity questions before buying a network-connected security device > Procurement should evaluate how a connected product will be configured, updated, supported, monitored, reset, and retired—not only whether it performs its primary function. - Canonical URL: https://update.dsesecurity.com/updates/security-device-procurement-cybersecurity/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:04:47+00:00 - Modified: 2026-07-19T19:04:47+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know Procurement should evaluate how a connected product will be configured, updated, supported, monitored, reset, and retired—not only whether it performs its primary function. ## Potentially affected Organizations selecting cameras, controllers, readers, intercoms, gateways, sensors, appliances, management cards, or other connected physical-security products. ## DSE recommendation Add cybersecurity and lifecycle questions to requirements, require evidence for vendor answers, and evaluate deployment and exit costs before approval. ## Article ## Procurement creates a long-lived security dependency NIST IR 8259 Rev. 1 describes foundational cybersecurity activities that IoT product manufacturers should consider before products are sold. It focuses on making products more securable and giving customers cybersecurity information they need. Buyers can use that perspective to ask whether a network-connected security product can be governed throughout its useful life. NIST does not certify products through this publication, and this checklist does not establish that any device is secure, compatible, or suitable for a particular facility. It is a structured way to collect evidence before a purchase creates an operational dependency. ## Define the environment and required outcome Describe the product’s intended role, network location, users, data, integrations, availability requirement, expected service life, and management model. Identify whether it will communicate with cloud services, mobile applications, identity providers, video or access platforms, or vendor support systems. Requirements should distinguish mandatory capabilities from preferences and name the team responsible after installation. ## Ask for lifecycle evidence - Identification: How are the model, hardware revision, software version, and device identity inventoried? - Configuration and access: Which settings, roles, accounts, authentication methods, certificates, and administrative interfaces are available? - Updates: How are security updates delivered, authenticated, documented, installed, and recovered if deployment fails? - Support: What support period, end-of-support notice, security advisory, and vulnerability-reporting process is documented? - Visibility: Which security, administrative, health, and time-synchronized logs or alerts can authorized operators obtain? - Data: What information is stored, transmitted, exported, backed up, or sent to a vendor service, and how can it be deleted? - Retirement: What supported process removes credentials, customer data, licenses, cloud associations, and management records? Request current manuals, policy pages, release notes, advisory examples, and supported integration documentation. A questionnaire response without a product document, demonstration, or contractual commitment may be difficult to rely on years later. ## Evaluate the operating cost, not only acquisition Consider the tools and labor needed for inventory, secure configuration, certificate and account management, firmware deployment, configuration backup, log collection, monitoring, and replacement. Determine whether required functions depend on a subscription or external service and what happens when that service changes or ends. Confirm how responsibilities are divided among DSE, the customer, the manufacturer, another integrator, and any cloud provider. ## Validate before standardizing Use a representative evaluation to test documented workflows in the intended architecture. Confirm onboarding, authentication, least-privilege roles, logging, time, update and rollback behavior, backup or export, integrations, and reset or decommissioning. Record exact hardware and software versions because results from one combination should not be generalized to another. Finally, maintain a decision record: requirements, evidence, exceptions, approvers, support assumptions, and an exit plan. Good procurement does not promise that risk disappears. It gives future operators the information and supported controls needed to manage risk deliberately. ## Primary reference - Name: NIST IR 8259 Rev. 1 — Foundational Cybersecurity Activities for IoT Product Manufacturers - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/ir/8259/r1/final - Source publication date: 2026-04-20 ## Citation and use Preferred citation: “Ask cybersecurity questions before buying a network-connected security device,” DSE Security, https://update.dsesecurity.com/updates/security-device-procurement-cybersecurity/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assess CUI safeguards with evidence, depth, and coverage chosen up front > SP 800-171A Rev. 3 supplies flexible assessment procedures for SP 800-171 requirements. Define scope, assessor independence, evidence methods, depth, coverage, and finding rules before testing. - Canonical URL: https://update.dsesecurity.com/updates/cui-assessment-depth-coverage-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:33:54+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know SP 800-171A Rev. 3 supplies flexible assessment procedures for SP 800-171 requirements. Define scope, assessor independence, evidence methods, depth, coverage, and finding rules before testing. ## Potentially affected Organizations and assessors planning internal, third-party, or government-sponsored assessments of NIST SP 800-171 Rev. 3 security requirements. ## DSE recommendation Create an assessment plan tied to the authorized CUI boundary, choose depth and coverage intentionally, collect reproducible evidence, distinguish design from operation, and track findings through verified closure. ## Article Bottom line: an assessment result is only interpretable when its boundary, evidence, methods, sample, depth, coverage, assessor role, and date are clear. A control narrative or screenshot can support a conclusion, but neither automatically proves that the safeguard is designed correctly and operating across the full CUI environment. ## Source fact: what NIST SP 800-171A provides [NIST SP 800-171A Revision 3](https://csrc.nist.gov/pubs/sp/800/171/a/r3/final) provides assessment procedures and a methodology for evaluating the security requirements in SP 800-171. NIST states that the procedures are flexible and can be customized to organizational and assessor needs. Assessments may be independent, third-party, or government-sponsored and can use varying degrees of rigor through customer-defined depth and coverage attributes. This flexibility makes planning visible: two assessments of the same requirement may not provide the same assurance if their scope, depth, coverage, evidence, or independence differs. ## What the source does not establish SP 800-171A does not determine the applicable contract, define the CUI boundary, accredit every assessor, or by itself establish a particular certification outcome. Completing a worksheet does not prove that evidence is authentic, representative, current, or sufficient. This draft does not interpret contractual scoring, certification, or regulatory rules. Those must be confirmed from the governing authority and current program documentation. Sensitive assessment artifacts can themselves reveal security information and require controlled handling. ## Applicability questions - What agreement, requirement set, system boundary, and assessment objective are authoritative? - Who is the customer for the assessment, and what independence or qualification is required? - Which examination, interview, and test methods will be used for each objective? - What depth and coverage are necessary for the risk and required conclusion? - How will samples represent sites, systems, roles, shifts, components, and time periods? ## DSE recommendation: plan before collecting artifacts The following steps are DSE recommendations based on the cited source. - Freeze the assessment basis: applicable SP 800-171 revision, authorized boundary, requirements, organizational components, shared services, suppliers, dates, and exclusions. - Define assessor roles, independence, access, evidence handling, conflict resolution, and reporting authority. Confirm any external program requirements separately. - Tailor procedures intentionally. Record the selected methods, depth, coverage, samples, and rationale for every requirement or assessment objective. - Seek multiple evidence types where warranted. Compare documented design, responsible-person explanation, configuration or record examination, and observed or tested operation. - Time-bind conclusions. Note evidence dates, versions, environments, exceptions, temporary states, and changes occurring during the assessment. - Track findings to root condition, owner, planned action, due date, residual risk decision, retest, and verified closure. Do not erase the original finding when remediation occurs. ## Verification and evidence Retain the approved assessment plan, boundary and requirement baseline, evidence request list, chain-of-custody or access controls where needed, interview and test records, samples, assessor work papers, findings, management responses, retest results, and final report. A reviewer should be able to reconstruct how each conclusion was reached. ## Official references - [NIST SP 800-171A Rev. 3 — Assessing Security Requirements for Controlled Unclassified Information](https://csrc.nist.gov/pubs/sp/800/171/a/r3/final) — National Institute of Standards and Technology; published May 2024 - [NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/171/r3/final) — National Institute of Standards and Technology ## Primary reference - Name: NIST SP 800-171A Rev. 3 — Assessing Security Requirements for Controlled Unclassified Information - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/171/a/r3/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assess CUI safeguards with evidence, depth, and coverage chosen up front,” DSE Security, https://update.dsesecurity.com/updates/cui-assessment-depth-coverage-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assess mirror-accelerated parity against the workload write pattern > What should a workload test examine before choosing mirror-accelerated parity? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-025-assess-mirror-accelerated-parity-against-the-workload-write-pattern/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:46+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What should a workload test examine before choosing mirror-accelerated parity? ## Potentially affected Use this review when evaluating the mixed layout for a supported storage design. ## DSE recommendation Ask the application owner to supply a representative sustained workload rather than only a short demonstration. ## Article ## Source facts Microsoft describes mirror-accelerated parity as a ReFS volume arrangement in Storage Spaces Direct that combines mirror and parity resiliency. Mirroring favors write performance while consuming capacity for copies; parity favors capacity efficiency but requires parity calculations when writing. ReFS moves data between the regions, accepting incoming writes in mirror storage and moving colder data into parity storage. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/refs/mirror-accelerated-parity). ## Applicability Use this review when evaluating the mixed layout for a supported storage design. Record the application’s actual write pattern, capacity needs, and acceptance targets. Check the source’s requirements before applying its performance explanation. ## DSE recommendation Ask the application owner to supply a representative sustained workload rather than only a short demonstration. Include the periods that matter operationally, such as ingestion or maintenance. Compare the proposed layout with the alternative under consideration using the same acceptance criteria. Record available capacity and the chosen mirror/parity allocation with each observation. ## Verification Run the approved test for the agreed duration and preserve both application-level timings and storage observations. Look at behavior throughout the run rather than reporting only its fastest interval. Document whether the workload and free-space conditions matched the plan. Treat the observed result as evidence for that configuration, and review it again if the workload changes. ## Official references [Microsoft Learn: Mirror-accelerated parity](https://learn.microsoft.com/en-us/windows-server/storage/refs/mirror-accelerated-parity). Source reviewed September 8, 2026. ## Primary reference - Name: Mirror-accelerated parity - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/refs/mirror-accelerated-parity - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assess mirror-accelerated parity against the workload write pattern,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-025-assess-mirror-accelerated-parity-against-the-workload-write-pattern/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assess whether controls produce the intended outcome—not whether they exist > A policy, screenshot, or enabled setting proves only part of a control. Build assessment procedures around what must be examined, interviewed, and tested, then record whether implementation is correct, operating as intended, and producing the required outcome. - Canonical URL: https://update.dsesecurity.com/updates/assess-controls-for-intended-outcomes-not-existence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:35:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity - Reading time: 3 minutes ## What you need to know A policy, screenshot, or enabled setting proves only part of a control. Build assessment procedures around what must be examined, interviewed, and tested, then record whether implementation is correct, operating as intended, and producing the required outcome. ## Potentially affected Security and privacy controls, internal assurance, audit preparation, risk owners, system owners, assessors, compliance evidence, remediation plans, inherited controls, and authorization decisions. ## DSE recommendation Choose a control set and scope, define assessment objectives and methods, collect representative evidence from multiple sources, rate findings consistently, and connect every weakness to ownership and risk response. ## Article ## Source facts: control assessment is objective-driven NIST Special Publication 800-53A Revision 5 supplies a methodology and procedures for assessing security and privacy controls in systems and organizations. The procedures correspond to NIST SP 800-53 Revision 5 and are intended to be customized for the organization, system life cycle, risk tolerance, and purpose of the assessment. They are a starting point, not a mandatory script for every environment. An assessment procedure contains objectives and potential assessment methods and objects. The three methods are examine, interview, and test. An assessor might examine policies, designs, configurations, records, or logs; interview people with responsibilities or knowledge; and test mechanisms, processes, or safeguards under defined conditions. Depth addresses the rigor and detail of the work. Coverage addresses its scope or breadth. NIST frames the determination around whether controls are implemented correctly, operating as intended, and producing the desired outcome with respect to requirements. A finding should result from the evidence obtained against an assessment objective. The publication also emphasizes an assessment plan, rules for assessor independence, tailoring, evidence collection, and analysis of results. ## DSE recommendation: write the assessment plan before collecting evidence Define the decision the assessment must support. State the systems, business processes, locations, time period, control implementations, inherited services, and exclusions. Identify the governing control statement and each organization-defined parameter. Name the assessor, evidence custodians, system owner, risk owner, and person authorized to accept results. For each objective, choose methods that can reveal different failure modes. A policy examination may show that a requirement was approved; an interview may show whether responsibility is understood; a test may show whether the mechanism actually prevents, detects, or recovers from the event. Do not substitute one convenient screenshot for all three questions. ## DSE recommendation: make evidence representative and reproducible - Define the population. Identify all accounts, devices, sites, transactions, exceptions, or changes to which the control should apply. - Select coverage deliberately. Include high-risk cases, ordinary cases, inherited components, recent changes, failed transactions, exceptions, and time periods that represent real operation. Record how samples were chosen. - Protect provenance. Capture source, collection time, query or test steps, tool version, relevant scope, and custodian. Preserve sensitive evidence with appropriate access and retention. - Test safely. Define constraints, expected effects, stop conditions, rollback, communications, and maintenance windows before a test can alter production or expose protected information. - Resolve contradictions. When a policy, interview, configuration, and observed result disagree, investigate the discrepancy instead of selecting the most favorable artifact. ## DSE recommendation: report determinations that can drive action For every objective, record the determination, evidence, scope, limitations, and assessor rationale. Distinguish absence of evidence from evidence of failure. State whether the weakness is isolated, systematic, inherited, intermittent, or not testable under current constraints. Avoid a single percentage that hides high-consequence failures behind many low-value passes. Translate findings into owned actions with risk, affected assets, interim safeguards, target evidence, due date, and closure authority. Reassessment should verify the corrected outcome, not merely the presence of a ticket. Track accepted weaknesses separately from corrected ones, including the accepting authority, rationale, expiration, and monitoring condition. Require an independent check when the person who implemented a high-impact control also supplies its closure evidence. Preserve approved plans, evidence indexes, findings, responses, and final decisions so another qualified reviewer can reproduce the path from requirement to conclusion. A mature assessment does not reward the largest evidence folder; it gives decision-makers justified confidence—or a precise account of where confidence is missing. ## Official references - National Institute of Standards and Technology, [SP 800-53A Revision 5: Assessing Security and Privacy Controls in Information Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/53/a/r5/final), January 25, 2022, including the current release information on the publication page; reviewed August 11, 2026. ## Primary reference - Name: NIST SP 800-53A Rev. 5: Assessing Security and Privacy Controls - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/53/a/r5/final - Source publication date: 2022-01-25 ## Citation and use Preferred citation: “Assess whether controls produce the intended outcome—not whether they exist,” DSE Security, https://update.dsesecurity.com/updates/assess-controls-for-intended-outcomes-not-existence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign a qualified person or position to manage each covered risk-management process > Use 40 CFR 68.15 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/assign-a-qualified-person-or-position-to-manage-each-covered-risk-management-process/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:19+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.15 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.15 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Assign a qualified person or position to manage each covered risk-management process. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.15 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.15) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the owner or operator assign a qualified person or position that has the overall responsibility for the development, implementation, and integration of the risk management program elements. The research record locates this support at 40 CFR 68.15(b) (eCFR anchor p-68.15(b)). - Under 40 CFR 68, the rule requires that the owner or operator of a stationary source with processes subject to Program 2 or Program 3 develop a management system to oversee the implementation of the risk management program elements. The research record locates this support at 40 CFR 68.15(a) (eCFR anchor p-68.15(a)). The source support ends with the statements listed above. Use them to examine critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 40 CFR 68.15(b) (eCFR anchor p-68.15(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.15(a) (eCFR anchor p-68.15(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from 40 CFR 68.15(b) (eCFR anchor p-68.15(b)); 40 CFR 68.15(a) (eCFR anchor p-68.15(a)) to the observed environment. Useful domain evidence includes facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [40 CFR 68.15 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.15) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.15 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.15 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assign a qualified person or position to manage each covered risk-management process,” DSE Security, https://update.dsesecurity.com/updates/assign-a-qualified-person-or-position-to-manage-each-covered-risk-management-process/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign cruise-terminal screening staffing, equipment, and oversight to the owner or operator > Use 33 CFR 105.510 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/assign-cruise-terminal-screening-staffing-equipment-and-oversight-to-the-owner-or-operator/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:50+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.510 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.510 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Assign cruise-terminal screening staffing, equipment, and oversight to the owner or operator. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.510 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.510) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that in addition to the requirements of section 105.200, the owner or operator of a cruise ship terminal ensure that screening is conducted in accordance with this subpart and an approved TSP. The research record locates this support at 33 CFR 105.510(b), read with the unnumbered introductory paragraph of 33 CFR 105.510 (eCFR anchor p-105.510(b)). - Under 33 CFR 105, the rule requires that in addition to the requirements of section 105.200, the owner or operator of a cruise ship terminal ensure that procedures are established for reporting and handling prohibited items that are detected during the screening process. The research record locates this support at 33 CFR 105.510(d), read with the unnumbered introductory paragraph of 33 CFR 105.510 (eCFR anchor p-105.510(d)). Keep the evidence boundary at these traced claims. They support a review of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.510(b), read with the unnumbered introductory paragraph of 33 CFR 105.510 (eCFR anchor p-105.510(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.510(d), read with the unnumbered introductory paragraph of 33 CFR 105.510 (eCFR anchor p-105.510(d)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 33 CFR 105.510(b), read with the unnumbered introductory paragraph of 33 CFR 105.510 (eCFR anchor p-105.510(b)); 33 CFR 105.510(d), read with the unnumbered introductory paragraph of 33 CFR 105.510 (eCFR anchor p-105.510(d)). Favor approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [33 CFR 105.510 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.510) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.510 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.510 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assign cruise-terminal screening staffing, equipment, and oversight to the owner or operator,” DSE Security, https://update.dsesecurity.com/updates/assign-cruise-terminal-screening-staffing-equipment-and-oversight-to-the-owner-or-operator/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign exclusive-area security duties through written airport-operator agreements > Use 49 CFR 1542.111 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/assign-exclusive-area-security-duties-through-written-airport-operator-agreements/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:36+00:00 - Modified: 2026-08-27T13:09:39+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.111 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.111 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Assign exclusive-area security duties through written airport-operator agreements. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.111 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.111) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, TSA may approve an amendment to an airport security program under which an aircraft operator or foreign air carrier that has a security program under part 1544 or 1546 of this chapter assumes responsibility for specified security measures for all or portions of the secured area, AOA, or SIDA, including access points, as provided in section 1542.201, section 1542.203, or section 1542.205. The research record locates this support at 49 CFR 1542.111(a) (eCFR anchor p-1542.111(a)). - Under 49 CFR 1542, the rule requires that this agreement contain the following: a description, a map, and, where appropriate, a diagram of the boundaries and pertinent features of each area, including individual access points, over which the aircraft operator or foreign air carrier will exercise exclusive security responsibility. The research record locates this support at 49 CFR 1542.111(b)(1), read with 49 CFR 1542.111(b) (eCFR anchor p-1542.111(b)(1)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths and the conditions the source actually describes. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 49 CFR 1542.111(a) (eCFR anchor p-1542.111(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.111(b)(1), read with 49 CFR 1542.111(b) (eCFR anchor p-1542.111(b)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and sanitize protected material before retention. ## Verification and evidence Keep the source locations 49 CFR 1542.111(a) (eCFR anchor p-1542.111(a)); 49 CFR 1542.111(b)(1), read with 49 CFR 1542.111(b) (eCFR anchor p-1542.111(b)(1)) adjacent to the sanitized artifacts used for comparison. Prefer asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [49 CFR 1542.111 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.111) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.111 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.111 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assign exclusive-area security duties through written airport-operator agreements,” DSE Security, https://update.dsesecurity.com/updates/assign-exclusive-area-security-duties-through-written-airport-operator-agreements/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign forward and reverse DNS updates between DHCPv4 client and server > Use RFC 4702 — The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/assign-forward-and-reverse-dns-updates-between-dhcpv4-client-and-server/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:52+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4702 — The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4702 — The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Assign forward and reverse DNS updates between DHCPv4 client and server. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4702 — The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option](https://www.rfc-editor.org/rfc/rfc4702.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - In the DHCPv4 Client FQDN option, S requests server responsibility for the A-record update, N requests no server updates, and O reports that the server overrode the requested S value. The research record locates this support at Section 2.1 (The Flags Field). - A client requesting server-performed forward updates sets S to 1 and sets O and N to 0 in its Client FQDN option. The research record locates this support at Section 3.3 (Client Desires Server to Do DNS Updates). - When the server returns N=1, the client may originate its own DNS updates after receiving DHCPACK and completing its final parameter checks. The research record locates this support at Section 3.4 (Client Desires No Server DNS Updates). Keep the evidence boundary at these traced claims. They support a review of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2.1 (The Flags Field), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3.3 (Client Desires Server to Do DNS Updates), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 3.4 (Client Desires No Server DNS Updates), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations Section 2.1 (The Flags Field); Section 3.3 (Client Desires Server to Do DNS Updates); Section 3.4 (Client Desires No Server DNS Updates) adjacent to the sanitized artifacts used for comparison. Prefer zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 4702 — The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option](https://www.rfc-editor.org/rfc/rfc4702.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4702 — The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4702.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assign forward and reverse DNS updates between DHCPv4 client and server,” DSE Security, https://update.dsesecurity.com/updates/assign-forward-and-reverse-dns-updates-between-dhcpv4-client-and-server/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign one accountable owner for DNS supporting AD DS > Use DNS for AD DS Owner Role to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/assign-accountable-owner-for-dns-supporting-ad-ds/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:09+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use DNS for AD DS Owner Role to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of DNS for AD DS Owner Role ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Assign one accountable owner for DNS supporting AD DS. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [DNS for AD DS Owner Role](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/assigning-the-dns-for-ad-ds-owner-role) from Microsoft supports the following bounded statements: - The forest owner assigns a person or group to own DNS for the AD DS forest. The research record locates this support at Opening overview. - That owner is responsible for DNS design and coordinates delegation of the forest-root DNS name when an existing DNS service is used. The research record locates this support at Opening overview. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles only where the source and recorded environment align. ## What the source does not establish Role assignment does not replace documented change authority or separation of duties. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from Opening overview; Opening overview to the observed environment. Useful domain evidence includes directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [DNS for AD DS Owner Role](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/assigning-the-dns-for-ad-ds-owner-role) — Microsoft ## Primary reference - Name: DNS for AD DS Owner Role - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/assigning-the-dns-for-ad-ds-owner-role - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Assign one accountable owner for DNS supporting AD DS,” DSE Security, https://update.dsesecurity.com/updates/assign-accountable-owner-for-dns-supporting-ad-ds/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign ownership for Device Health Attestation reports > What does a Device Health Attestation report cover, and who should interpret it? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-012-assign-ownership-for-device-health-attestation-reports/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:59+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What does a Device Health Attestation report cover, and who should interpret it? ## Potentially affected Use this review when evaluating a DHA reporting arrangement. ## DSE recommendation Define who operates the attestation service and who decides what a returned report means for device access. ## Article ## Source facts Microsoft documents an on-premises Device Health Attestation server role beginning with Windows Server 2016. The DHA service validates a device’s TPM and PCR logs and issues an attestation report. The cloud-service description explains that the report represents how the device started, using TPM-protected data, and is delivered to the requesting MDM server over a protected channel. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/security/device-health-attestation). ## Applicability Use this review when evaluating a DHA reporting arrangement. Identify whether the proposed service is hosted locally or in the cloud, the requesting management system, and the applicable device requirements in the current source. ## DSE recommendation Define who operates the attestation service and who decides what a returned report means for device access. Write down the fields that matter to that decision and how a missing report will be handled. Keep the device identity and report time with each reviewed result. Obtain a separate policy decision before turning an observed attestation result into an access restriction. ## Verification Use an approved test device to follow a request through report receipt and administrative review. Check that the report belongs to the intended device and observation. Exercise the agreed missing-report handling and record the outcome. Retain any uncertainty about the service configuration or interpretation for the responsible management-system owner. ## Official references [Microsoft Learn: Device Health Attestation](https://learn.microsoft.com/en-us/windows-server/security/device-health-attestation). Source reviewed September 8, 2026. ## Primary reference - Name: Device Health Attestation - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/device-health-attestation - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assign ownership for Device Health Attestation reports,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-012-assign-ownership-for-device-health-attestation-reports/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign primary computers before expanding roaming user data > How should primary-computer assignments constrain Folder Redirection and roaming profiles? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-040-assign-primary-computers-before-expanding-roaming-user-data/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:31+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know How should primary-computer assignments constrain Folder Redirection and roaming profiles? ## Potentially affected Use this review when users have designated workstations and the organization wants to limit where roaming data is applied. ## DSE recommendation Create a user-to-computer mapping that the business owner can review. ## Article ## Source facts Microsoft describes primary-computer support as a way to control which computers use Folder Redirection and Roaming User Profiles. Administrators designate a user’s primary computers through the msDs-PrimaryComputer attribute using the computers’ distinguished names. For a new deployment, Microsoft recommends establishing this support before enabling the redirection or profile policies, so user data is not first copied to nonprimary computers. Microsoft requires pairing primary-computer support for Roaming User Profiles with primary-computer support for Folder Redirection. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-primary-computers). ## Applicability Use this review when users have designated workstations and the organization wants to limit where roaming data is applied. Identify users, approved computers, and the owner responsible for changes to those assignments. ## DSE recommendation Create a user-to-computer mapping that the business owner can review. Include shared workstations, replacement devices, and temporary assignments in that decision. Test the intended order of policy deployment before expanding it. Define how support staff will update assignments when hardware changes and how they will recognize a missing or incorrect primary-computer entry. ## Verification Test a representative user on both an assigned primary computer and a deliberately nonprimary one. Compare folder and profile behavior with the approved mapping. Check a controlled device-replacement scenario and record the assignment update. Resolve unexpected data placement before enabling the policy for additional users or retiring their old workstations. ## Official references [Microsoft Learn: Deploy primary computers for Folder Redirection and Roaming User Profiles](https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-primary-computers). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy primary computers for Folder Redirection and Roaming User Profiles - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-primary-computers - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assign primary computers before expanding roaming user data,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-040-assign-primary-computers-before-expanding-roaming-user-data/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign source, destination, and orchestrator roles for Storage Migration Service > Which migration roles and inventory decisions should be established before data transfer? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-041-assign-source-destination-and-orchestrator-roles-for-storage-migration-service/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:30+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Which migration roles and inventory decisions should be established before data transfer? ## Potentially affected Use this review when planning a Storage Migration Service project. ## DSE recommendation Create a role map that names the machine responsible for orchestration separately from the data endpoints. ## Article ## Source facts Storage Migration Service inventories supported Windows, Linux, and NetApp CIFS sources and transfers data to newer servers or Azure virtual machines. Microsoft distinguishes source, destination, orchestrator, and management-interface roles. For one migrating server, the destination can also orchestrate; for several, the source recommends a separate orchestrator. Identity cutover is optional and occurs after the data-transfer stage. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/overview). ## Applicability Use this review when planning a Storage Migration Service project. Identify the source types, destination versions, number of servers, and management tools. Verify the complete current support requirements before including a source in the inventory. ## DSE recommendation Create a role map that names the machine responsible for orchestration separately from the data endpoints. Have data owners review the inventory and proposed destinations before approving transfer. Record which servers need an eventual identity handoff and which need only copied data. Keep transfer acceptance and the optional cutover decision as separate milestones. ## Verification Compare the discovered inventory with the approved source list and reconcile missing or unexpected data before copying. After an authorized transfer, inspect the recorded results and sample destination files with their owners. Preserve the role map and transfer evidence. Proceed to identity cutover only under its separately reviewed plan for the accepted endpoints. ## Official references [Microsoft Learn: Storage Migration Service overview](https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/overview). Source reviewed September 8, 2026. ## Primary reference - Name: Storage Migration Service overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assign source, destination, and orchestrator roles for Storage Migration Service,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-041-assign-source-destination-and-orchestrator-roles-for-storage-migration-service/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign staff, awareness, currency, protection, and usability in the vital-records program > Use 36 CFR 1223.14 - Required vital records program elements to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/assign-staff-awareness-currency-protection-and-usability-in-the-vital-records-program/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:34+00:00 - Modified: 2026-08-27T13:07:00+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 36 CFR 1223.14 - Required vital records program elements to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 36 CFR 1223.14 - Required vital records program elements ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Assign staff, awareness, currency, protection, and usability in the vital-records program. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [36 CFR 1223.14 – Required vital records program elements](https://www.ecfr.gov/current/title-36/section-1223.14) from National Archives and Records Administration via eCFR supports the following bounded statements: - Under 36 CFR 1223, the rule requires that in carrying out a vital records program, agencies ensure that vital records are adequately protected, accessible, and immediately usable. The research record locates this support at 36 CFR 1223.14(d), read with the unnumbered introductory paragraph of 36 CFR 1223.14 (eCFR anchor p-1223.14(d)). - Under 36 CFR 1223, the rule requires that in carrying out a vital records program, agencies specify agency staff responsibilities. The research record locates this support at 36 CFR 1223.14(a), read with the unnumbered introductory paragraph of 36 CFR 1223.14 (eCFR anchor p-1223.14(a)). The source support ends with the statements listed above. Use them to examine essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Federal agency records-management regulation that also incorporates referenced continuity guidance; verify the current incorporated material and agency-specific policy. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 36 CFR 1223.14(d), read with the unnumbered introductory paragraph of 36 CFR 1223.14 (eCFR anchor p-1223.14(d)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 36 CFR 1223.14(a), read with the unnumbered introductory paragraph of 36 CFR 1223.14 (eCFR anchor p-1223.14(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from 36 CFR 1223.14(d), read with the unnumbered introductory paragraph of 36 CFR 1223.14 (eCFR anchor p-1223.14(d)); 36 CFR 1223.14(a), read with the unnumbered introductory paragraph of 36 CFR 1223.14 (eCFR anchor p-1223.14(a)) to the observed environment. Useful domain evidence includes business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [36 CFR 1223.14 – Required vital records program elements](https://www.ecfr.gov/current/title-36/section-1223.14) — National Archives and Records Administration via eCFR ## Primary reference - Name: 36 CFR 1223.14 - Required vital records program elements - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-36/section-1223.14 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assign staff, awareness, currency, protection, and usability in the vital-records program,” DSE Security, https://update.dsesecurity.com/updates/assign-staff-awareness-currency-protection-and-usability-in-the-vital-records-program/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign Teams meeting policy by organizer, then test lobby and presenter behavior > Many Teams meeting controls are evaluated from the organizer's assigned policy, so attendee experience can vary even when participants belong to the same organization. - Canonical URL: https://update.dsesecurity.com/updates/teams-meeting-policy-organizer-lobby-presenter-testing/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:16+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Many Teams meeting controls are evaluated from the organizer's assigned policy, so attendee experience can vary even when participants belong to the same organization. ## Potentially affected Organizations administering Microsoft Teams meeting and event policies for different organizer populations. ## DSE recommendation Classify organizer use cases, assign the smallest policy set, test each attendee type and meeting option, and preserve effective-policy evidence before broad rollout. ## Article Bottom line: Teams meeting and event policies control features available to organizers and participants. Microsoft documents multiple implementation types, including per-organizer settings under which participants inherit the organizer’s policy behavior. Validate the organizer, attendee type, meeting option, and client experience together. ## Source fact: what Microsoft documents Microsoft’s [meeting and events policy overview](https://learn.microsoft.com/en-us/microsoftteams/meeting-policies-overview) says administrators can edit the global policy or create and assign custom policies. Users receive the global policy unless another policy is assigned. The page explains that settings can be implemented per organizer, per user, or through combinations described in the relevant setting documentation. For a per-organizer setting, participants inherit the policy assigned to the meeting organizer. Microsoft gives Who can bypass the lobby as an example: the setting attached to the organizer controls whether users join directly or wait. Other meeting behavior can also depend on organization-wide meeting settings, meeting templates or sensitivity labels, organizer-selected meeting options, attendee identity, and current Teams client capabilities, which should be checked in the linked setting references. ## What the source does not establish A policy assignment does not prove the intended behavior for every anonymous user, guest, external participant, dial-in caller, trusted organization, room device, or webinar. Lobby controls do not authenticate a participant beyond the identity signals actually used. Limiting presenters does not prevent an authorized presenter from sharing sensitive material. The overview does not define which collaboration model is correct for a particular meeting. ## Applicability questions - Which organizer populations run ordinary internal meetings, customer calls, public events, confidential reviews, or emergency sessions? - Which participants are internal, guest, federated, anonymous, dial-in, or using Teams Rooms? - Which settings are global, per organizer, per user, meeting-option, template, or sensitivity-label controlled? - Who can change meeting options, and do organizers understand the consequence? - What accessibility, waiting-room staffing, recording, transcription, and business-continuity needs apply? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Define meeting classes and intended lobby, presenter, anonymous-access, recording, and content-sharing behavior for each. - Keep the policy set small and assign by organizer role. Document the global fallback and group-assignment precedence. - Test each class with the actual organizer policy and representative internal, guest, external, anonymous, dial-in, mobile, browser, and room participants. - Provide organizer guidance for meeting options they can override and an escalation path for blocked legitimate participants. - Review policy assignments after job changes and investigate meetings whose observed controls differ from the design. ## Verification and evidence - Preserve policy definitions, assignments, meeting templates or labels, and change approval. - Record test meeting IDs, organizer, attendee type, client, expected result, and observed lobby and presenter state. - Capture effective policy output through supported administrative tools where available. - Repeat tests after major Teams policy, client, template, or identity changes. ## Official references - [Manage meeting and events policies in Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/meeting-policies-overview) — Microsoft ## Primary reference - Name: Manage meeting and events policies in Microsoft Teams - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/microsoftteams/meeting-policies-overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Assign Teams meeting policy by organizer, then test lobby and presenter behavior,” DSE Security, https://update.dsesecurity.com/updates/teams-meeting-policy-organizer-lobby-presenter-testing/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Assign the Windows DNSSEC Key Master only to a qualifying authoritative server > Use DNSSEC Key Master to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/assign-the-windows-dnssec-key-master-only-to-a-qualifying-authoritative-server/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:40+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use DNSSEC Key Master to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of DNSSEC Key Master ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Assign the Windows DNSSEC Key Master only to a qualifying authoritative server. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [DNSSEC Key Master](https://learn.microsoft.com/en-us/windows-server/networking/dns/dnssec-key-master) from Microsoft supports the following bounded statements: - The Windows DNSSEC Key Master generates and manages cryptographic keys for a signed zone. The research record locates this support at Section ‘What is a DNSSEC Key Master?’. - Only one DNS server can be Key Master for a specific zone at a time, and it must be an authoritative primary capable of online signing. The research record locates this support at Sections ‘What is a DNSSEC Key Master?’ and ‘Requirements’. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The role description does not provide a complete key ceremony, backup, cryptoperiod, hardware-protection, or incident-recovery design. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section ‘What is a DNSSEC Key Master?’, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections ‘What is a DNSSEC Key Master?’ and ‘Requirements’, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section ‘What is a DNSSEC Key Master?’; Sections ‘What is a DNSSEC Key Master?’ and ‘Requirements’. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [DNSSEC Key Master](https://learn.microsoft.com/en-us/windows-server/networking/dns/dnssec-key-master) — Microsoft ## Primary reference - Name: DNSSEC Key Master - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/dnssec-key-master - Source publication date: 2025-08-01 ## Citation and use Preferred citation: “Assign the Windows DNSSEC Key Master only to a qualifying authoritative server,” DSE Security, https://update.dsesecurity.com/updates/assign-the-windows-dnssec-key-master-only-to-a-qualifying-authoritative-server/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Audit DNS serials, MX targets, and delegation glue for common errors > Use RFC 1912 — Common DNS Operational and Configuration Errors to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/audit-dns-serials-mx-targets-and-delegation-glue-for-common-errors/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:51+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 1912 — Common DNS Operational and Configuration Errors to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 1912 — Common DNS Operational and Configuration Errors ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Audit DNS serials, MX targets, and delegation glue for common errors. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 1912 — Common DNS Operational and Configuration Errors](https://www.rfc-editor.org/rfc/rfc1912.html) from RFC Editor supports the following bounded statements: - A zone’s serial must be changed whenever its data changes; otherwise, secondaries will not transfer the new zone data. The research record locates this support at Section 3.1 (Serial numbers). - Every delegated name server should answer authoritatively for the zone; a delegated server that does not serve the zone creates a lame delegation. The research record locates this support at Section 2.8 (Authority and Delegation Errors). - The parent and child should publish the same NS set, and address records must be updated at both levels when a secondary changes address. The research record locates this support at Section 2.8 (Authority and Delegation Errors), delegation coordination. Keep the evidence boundary at these traced claims. They support a review of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 3.1 (Serial numbers), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.8 (Authority and Delegation Errors), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2.8 (Authority and Delegation Errors), delegation coordination, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations Section 3.1 (Serial numbers); Section 2.8 (Authority and Delegation Errors); Section 2.8 (Authority and Delegation Errors), delegation coordination adjacent to the sanitized artifacts used for comparison. Prefer zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 1912 — Common DNS Operational and Configuration Errors](https://www.rfc-editor.org/rfc/rfc1912.html) — RFC Editor ## Primary reference - Name: RFC 1912 — Common DNS Operational and Configuration Errors - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc1912.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Audit DNS serials, MX targets, and delegation glue for common errors,” DSE Security, https://update.dsesecurity.com/updates/audit-dns-serials-mx-targets-and-delegation-glue-for-common-errors/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Audit electrical installations against listing, condition, and working-space requirements > Use 29 CFR 1910.303 - General electrical requirements to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/audit-electrical-installations-against-listing-condition-and-working-space-requirements/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:14+00:00 - Modified: 2026-08-27T13:06:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.303 - General electrical requirements to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.303 - General electrical requirements ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Audit electrical installations against listing, condition, and working-space requirements. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.303 – General electrical requirements](https://www.ecfr.gov/current/title-29/section-1910.303) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, working space for equipment likely to require examination, adjustment, servicing, or maintenance while energized must comply with the following dimensions, except as required or permitted elsewhere in this subpart: the depth of the working space in the direction of access to live parts may not be less than indicated in Table S-1. The research record locates this support at 29 CFR 1910.303(g)(1)(i)(A), read with 29 CFR 1910.303(g)(1)(i) (eCFR anchor p-1910.303(g)(1)(i)(A)). - Under 29 CFR 1910, for installations other than equipment described in paragraph (h)(2)(v) of this section, a wall, screen, or fence must be used to enclose an outdoor electrical installation to deter access by persons who are not qualified. The research record locates this support at 29 CFR 1910.303(h)(2)(ii) (eCFR anchor p-1910.303(h)(2)(ii)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths only where the source and recorded environment align. ## What the source does not establish Federal workplace rule; electrical code, equipment instructions, qualified-person determinations, and local inspection requirements also govern installations. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 29 CFR 1910.303(g)(1)(i)(A), read with 29 CFR 1910.303(g)(1)(i) (eCFR anchor p-1910.303(g)(1)(i)(A)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.303(h)(2)(ii) (eCFR anchor p-1910.303(h)(2)(ii)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations 29 CFR 1910.303(g)(1)(i)(A), read with 29 CFR 1910.303(g)(1)(i) (eCFR anchor p-1910.303(g)(1)(i)(A)); 29 CFR 1910.303(h)(2)(ii) (eCFR anchor p-1910.303(h)(2)(ii)) adjacent to the sanitized artifacts used for comparison. Prefer facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [29 CFR 1910.303 – General electrical requirements](https://www.ecfr.gov/current/title-29/section-1910.303) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.303 - General electrical requirements - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.303 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Audit electrical installations against listing, condition, and working-space requirements,” DSE Security, https://update.dsesecurity.com/updates/audit-electrical-installations-against-listing-condition-and-working-space-requirements/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Audit LSA plug-in compatibility before enforcing protected-process mode > Added LSA protection blocks plug-ins and drivers that do not meet protected-process requirements; Microsoft provides audit events that should be reviewed before broad enforcement. - Canonical URL: https://update.dsesecurity.com/updates/windows-lsa-protection-audit-first/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:13+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Added LSA protection blocks plug-ins and drivers that do not meet protected-process requirements; Microsoft provides audit events that should be reviewed before broad enforcement. ## Potentially affected Windows and Windows Server systems with smart-card, cryptographic, password-filter, authentication, or other software that loads into LSA. ## DSE recommendation Inventory LSA extensions, collect audit events on representative systems, remediate incompatible components, and verify protected-process state after staged enforcement. ## Article Bottom line: Added Local Security Authority protection runs LSASS as a protected process to reduce memory reading and code injection by nonprotected processes. Microsoft warns that LSA plug-ins and drivers must satisfy signing and protected-process requirements. Audit compatibility first or an authentication dependency can fail at enforcement. ## Source fact: what Microsoft documents Microsoft’s [added LSA protection guide](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection) says protected mode requires qualifying signatures for plug-ins loaded into LSA. Examples include smart-card drivers, cryptographic plug-ins, and password filters. Microsoft recommends identifying all LSA plug-ins, ensuring that they meet requirements, testing their function, and using audit logs before broad deployment. The guide documents audit-mode Code Integrity events for components that would fail protected-process requirements and enforcement events for components that are blocked. It also explains configuration with and without a UEFI lock, Secure Boot dependencies, automatic enablement criteria for specified Windows 11 installations, restart requirements, verification, and the relationship between LSA protection and Credential Guard. A UEFI-locked configuration has a different removal process from an ordinary registry or policy setting. ## What the source does not establish The presence of a policy value does not prove LSASS is running in the intended protected mode. An empty audit log does not prove compatibility if audit collection is misconfigured or a component was not exercised. LSA protection does not replace Credential Guard, patching, privileged-access controls, or protection against an attacker already operating with sufficient kernel-level capability. It also does not make custom plug-ins supportable. ## Applicability questions - Which Windows editions, versions, installation histories, UEFI, Secure Boot, and HVCI states are present? - Which password filters, smart-card middleware, credential providers, cryptographic modules, or security agents interact with LSA? - Is audit mode active and are relevant Code Integrity logs centrally collected? - Does the organization require UEFI lock, and can it perform the documented recovery or removal process? - Which authentication and recovery functions must be tested after reboot? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Inventory LSA extensions and the business functions that depend on them. Obtain vendor support statements for the deployed build. - Collect the documented audit events on representative hardware while exercising normal, smart-card, password-change, remote, and service authentication. - Remediate, update, replace, or formally except incompatible components before enforcement. - Deploy through rings with tested recovery media and administrator access. Decide explicitly whether UEFI lock is required. - After each ring, verify protected-process state and repeat critical authentication tests before expansion. ## Verification and evidence - Preserve device inventory, component versions, audit-event review, compatibility decisions, and change approval. - Capture relevant Code Integrity audit and enforcement events with device and timestamp context. - Verify configuration and runtime state using Microsoft’s documented methods after reboot. - Record successful smart-card, password, service, local, remote, and recovery authentication tests as applicable. ## Official references - [Configure added LSA protection](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection) — Microsoft ## Primary reference - Name: Configure added LSA protection - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/configuring-additional-lsa-protection - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Audit LSA plug-in compatibility before enforcing protected-process mode,” DSE Security, https://update.dsesecurity.com/updates/windows-lsa-protection-audit-first/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Audit Program 2 compliance and resolve documented findings > Use 40 CFR 68.58 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/audit-program-2-compliance-and-resolve-documented-findings/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:05+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.58 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.58 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Audit Program 2 compliance and resolve documented findings. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.58 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.58) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the owner or operator promptly determine and document an appropriate response to each of the findings of the compliance audit and document that deficiencies have been corrected. The research record locates this support at 40 CFR 68.58(d) (eCFR anchor p-68.58(d)). - Under 40 CFR 68, the rule requires that the owner or operator develop a report of the audit findings. The research record locates this support at 40 CFR 68.58(c) (eCFR anchor p-68.58(c)). Only the traced statements above are asserted as source facts. Apply the review to critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths after confirming that the source and deployed context match. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.58(d) (eCFR anchor p-68.58(d)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.58(c) (eCFR anchor p-68.58(c)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to 40 CFR 68.58(d) (eCFR anchor p-68.58(d)); 40 CFR 68.58(c) (eCFR anchor p-68.58(c)) and to observable material such as facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [40 CFR 68.58 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.58) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.58 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.58 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Audit Program 2 compliance and resolve documented findings,” DSE Security, https://update.dsesecurity.com/updates/audit-program-2-compliance-and-resolve-documented-findings/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Audit safety signs and tags for signal word, message, and placement > Use 29 CFR 1910.145 - Specifications for accident prevention signs and tags to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/audit-safety-signs-and-tags-for-signal-word-message-and-placement/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:22+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.145 - Specifications for accident prevention signs and tags to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.145 - Specifications for accident prevention signs and tags ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Audit safety signs and tags for signal word, message, and placement. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.145 – Specifications for accident prevention signs and tags](https://www.ecfr.gov/current/title-29/section-1910.145) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, other tags may be used in addition to those required by this paragraph (f), or in other situations where this paragraph (f) does not require tags, provided that they do not detract from the impact or visibility of the signal word and major message of any required tag. The research record locates this support at 29 CFR 1910.145(f)(9) (eCFR anchor p-1910.145(f)(9)). - Under 29 CFR 1910, this paragraph (f) applies to all accident prevention tags used to identify hazardous conditions and provide a message to employees with respect to hazardous conditions as set forth in paragraph (f)(3) of this section, or to meet the specific tagging requirements of other OSHA standards. The research record locates this support at 29 CFR 1910.145(f)(1)(i) (eCFR anchor p-1910.145(f)(1)(i)). The source support ends with the statements listed above. Use them to examine access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Federal workplace rule; signs and tags do not replace engineering controls, barriers, training, or other code-required markings. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.145(f)(9) (eCFR anchor p-1910.145(f)(9)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.145(f)(1)(i) (eCFR anchor p-1910.145(f)(1)(i)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 29 CFR 1910.145(f)(9) (eCFR anchor p-1910.145(f)(9)); 29 CFR 1910.145(f)(1)(i) (eCFR anchor p-1910.145(f)(1)(i)). Favor asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [29 CFR 1910.145 – Specifications for accident prevention signs and tags](https://www.ecfr.gov/current/title-29/section-1910.145) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.145 - Specifications for accident prevention signs and tags - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.145 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Audit safety signs and tags for signal word, message, and placement,” DSE Security, https://update.dsesecurity.com/updates/audit-safety-signs-and-tags-for-signal-word-message-and-placement/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Audit the Facility Security Plan annually and amend it after material change > Use 33 CFR 105.415 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/audit-the-facility-security-plan-annually-and-amend-it-after-material-change/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:52+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.415 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.415 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Audit the Facility Security Plan annually and amend it after material change. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.415 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.415) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the FSO must ensure an annual FSP audit beginning within one year after initial approval and attach a letter certifying that the plan meets applicable part 105 requirements. The research record locates this support at 33 CFR 105.415(b)(1) (eCFR anchor p-105.415(b)(1)). - Under 33 CFR 105, the FSP must be audited after a change in facility ownership or operator, or after modifications to physical structure, emergency procedures, security measures, or operations. The research record locates this support at 33 CFR 105.415(b)(2) (eCFR anchor p-105.415(b)(2)). Only the traced statements above are asserted as source facts. Apply the review to access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths after confirming that the source and deployed context match. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.415(b)(1) (eCFR anchor p-105.415(b)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.415(b)(2) (eCFR anchor p-105.415(b)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to 33 CFR 105.415(b)(1) (eCFR anchor p-105.415(b)(1)); 33 CFR 105.415(b)(2) (eCFR anchor p-105.415(b)(2)) and to observable material such as asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [33 CFR 105.415 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.415) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.415 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.415 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Audit the Facility Security Plan annually and amend it after material change,” DSE Security, https://update.dsesecurity.com/updates/audit-the-facility-security-plan-annually-and-amend-it-after-material-change/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Audit weak certificate algorithms before enforcing rejection > Use Disable weak cryptographic algorithms in certificate validation on Windows and Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/audit-weak-certificate-algorithms-before-rejection/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:05+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Disable weak cryptographic algorithms in certificate validation on Windows and Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Disable weak cryptographic algorithms in certificate validation on Windows and Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Audit weak certificate algorithms before enforcing rejection. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Disable weak cryptographic algorithms in certificate validation on Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/disable-weak-cryptographic-algorithms) from Microsoft supports the following bounded statements: - Windows policy can reject X.509 certificates that use MD5, SHA-1, or undersized RSA keys. The research record locates this support at Opening overview. - The policy affects certificate validation for TLS, code signing, and other Windows certificate scenarios and includes logging support. The research record locates this support at Opening overview; section: Enable logging. The source support ends with the statements listed above. Use them to examine certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Inventory affected chains and use logging before enforcement to avoid unplanned authentication or application failure. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview; section: Enable logging, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles are in and out of scope? - Which condition in Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview; section: Enable logging and to observable material such as CA and template exports, enrollment tests, certificate chains, access-control entries, event logs, and revocation-path checks. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Disable weak cryptographic algorithms in certificate validation on Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/disable-weak-cryptographic-algorithms) — Microsoft ## Primary reference - Name: Disable weak cryptographic algorithms in certificate validation on Windows and Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/disable-weak-cryptographic-algorithms - Source publication date: 2025-07-16 ## Citation and use Preferred citation: “Audit weak certificate algorithms before enforcing rejection,” DSE Security, https://update.dsesecurity.com/updates/audit-weak-certificate-algorithms-before-rejection/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Authenticate a complete DNS transaction with SIG(0), not a single RRset > Use RFC 2931 — DNS Request and Transaction Signatures ( SIG(0)s ) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/authenticate-a-complete-dns-transaction-with-sig-0-not-a-single-rrset/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:50+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2931 — DNS Request and Transaction Signatures ( SIG(0)s ) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2931 — DNS Request and Transaction Signatures ( SIG(0)s ) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Authenticate a complete DNS transaction with SIG(0), not a single RRset. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2931 — DNS Request and Transaction Signatures ( SIG(0)s )](https://www.rfc-editor.org/rfc/rfc2931.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A SIG(0) request signature is placed at the end of the additional section and covers the DNS request, including its DNS header but excluding UDP/IP headers. The research record locates this support at Section 3.1 (Calculating Request and Transaction SIGs). - A response transaction signature covers both the full query and the corresponding response, including their DNS headers but excluding transport and IP headers. The research record locates this support at Section 3.1 (Calculating Request and Transaction SIGs), response calculation. - A valid response SIG(0) authenticates the queried server and transaction integrity, but it does not directly authenticate each data RR in the message. The research record locates this support at Section 3.2 (Processing Responses and SIG(0) RRs). The source support ends with the statements listed above. Use them to examine authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 3.1 (Calculating Request and Transaction SIGs), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3.1 (Calculating Request and Transaction SIGs), response calculation, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 3.2 (Processing Responses and SIG(0) RRs), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Section 3.1 (Calculating Request and Transaction SIGs); Section 3.1 (Calculating Request and Transaction SIGs), response calculation; Section 3.2 (Processing Responses and SIG(0) RRs) through zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 2931 — DNS Request and Transaction Signatures ( SIG(0)s )](https://www.rfc-editor.org/rfc/rfc2931.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2931 — DNS Request and Transaction Signatures ( SIG(0)s ) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2931.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Authenticate a complete DNS transaction with SIG(0), not a single RRset,” DSE Security, https://update.dsesecurity.com/updates/authenticate-a-complete-dns-transaction-with-sig-0-not-a-single-rrset/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Authorize cloud-native services by workload identity—not subnet membership > Cloud-native zero trust shifts application policy toward user, application, and service identities. Inventory workload identities and enforce narrowly scoped service-to-service authorization across environments. - Canonical URL: https://update.dsesecurity.com/updates/cloud-native-service-identity-zero-trust/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:10+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Cloud-native zero trust shifts application policy toward user, application, and service identities. Inventory workload identities and enforce narrowly scoped service-to-service authorization across environments. ## Potentially affected Organizations running microservices or distributed applications across on-premises, hybrid, or multiple cloud environments. ## DSE recommendation Issue verifiable workload identities, define service-to-service policy at the application layer, constrain gateway and proxy administration, and test identity rotation and policy failure independently of network location. ## Article Bottom line: a service should not gain trust merely because it runs inside a familiar cluster, subnet, cloud account, or data center. For cloud-native applications, authorization should identify the calling workload and the requested action, then apply explicit policy regardless of where the service happens to run. ## Source fact: what NIST describes [NIST SP 800-207A](https://csrc.nist.gov/pubs/sp/800/207/a/final) applies zero-trust architecture concepts to cloud-native applications in hybrid and multi-cloud environments. NIST describes a shift from controls based mainly on network parameters toward policies based on application and service identities, in addition to user identity. The publication discusses an enabling platform that can include API gateways, sidecar proxies, and application identity infrastructure, with the objective of enforcing granular application-level policies across locations. NIST does not say that networks stop mattering. The source describes removing implicit trust based only on location; segmentation and network controls can remain useful layers. ## What the source does not establish The model does not certify a particular service mesh, gateway, identity framework, or cloud provider. Deploying mutual authentication or a sidecar does not prove that authorization is correct. A strong workload identity can still be over-privileged, issued to the wrong runtime, accepted by the wrong audience, or left active after retirement. Applicability depends on application architecture, platform support, identity issuance, protocol paths, legacy components, latency and availability requirements, and who controls the policy and trust anchors. ## Applicability questions - Which human, service, batch, device, and automation identities call each application interface? - How is workload identity issued, bound to a runtime, rotated, revoked, and logged? - Which actions and data may each identity reach, and where is that policy enforced? - Can traffic bypass the gateway, proxy, or policy decision point? - What happens when identity issuance, policy distribution, or a sidecar is unavailable? ## DSE recommendation: build a workload authorization map The following steps are DSE recommendations based on the cited source. - Inventory application flows as caller, action, destination, data class, environment, and owner. Include background jobs, administrative paths, and third-party integrations. - Give workloads distinct, short-lived identities where the platform supports them. Avoid reusing a shared secret or broad cloud identity across unrelated services. - Write allow policy from the required business flow. Deny unexpected identities, audiences, methods, and destinations; give every exception an owner and expiration. - Protect the enforcement plane. Restrict who can change gateways, identity issuers, trust bundles, proxy configuration, and authorization policy. Log and review those changes. - Preserve network defenses for containment, management isolation, and traffic observation. Do not represent identity policy as a replacement for every network control. - Test rotation, revocation, stale policy, enforcement failure, and attempted bypass before broad rollout. ## Verification and evidence For a sample service, retain the flow diagram, workload identity record, policy revision, change approval, successful and denied transaction logs, rotation and revocation test, bypass test, and documented failure behavior. Verify that the evidence names the exact environment and service version. ## Official references - [NIST SP 800-207A — A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments](https://csrc.nist.gov/pubs/sp/800/207/a/final) — National Institute of Standards and Technology; finalized September 13, 2023 - [NIST SP 800-207 — Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) — National Institute of Standards and Technology ## Primary reference - Name: NIST SP 800-207A — A Zero Trust Architecture Model for Access Control in Cloud-Native Applications - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/207/a/final - Source publication date: 2023-09-13 ## Citation and use Preferred citation: “Authorize cloud-native services by workload identity—not subnet membership,” DSE Security, https://update.dsesecurity.com/updates/cloud-native-service-identity-zero-trust/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Authorize identity remediation actions by connector and RBAC scope > Use Remediation actions in Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/authorize-identity-remediation-actions-by-connector-and-rbac-scope/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:54+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Remediation actions in Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remediation actions in Microsoft Defender for Identity ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Authorize identity remediation actions by connector and RBAC scope. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remediation actions in Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/remediation-actions) from Microsoft supports the following bounded statements: - Available remediation actions depend on the connector managing the account and can span Active Directory, Entra ID, non-Microsoft identity providers, and connected SaaS applications. The research record locates this support at Opening applicability overview. - Portal-initiated remediation actions are authorized through Microsoft Entra role-based access control and are blocked before execution when the initiating user lacks authorization. The research record locates this support at Authorization paragraph. Keep the evidence boundary at these traced claims. They support a review of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish RBAC authorization is not business approval or proof that an action is safe, reversible, or successful on the source system. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening applicability overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Authorization paragraph, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to Opening applicability overview; Authorization paragraph and to observable material such as sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Remediation actions in Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/remediation-actions) — Microsoft ## Primary reference - Name: Remediation actions in Microsoft Defender for Identity - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/remediation-actions - Source publication date: 2026-07-22 ## Citation and use Preferred citation: “Authorize identity remediation actions by connector and RBAC scope,” DSE Security, https://update.dsesecurity.com/updates/authorize-identity-remediation-actions-by-connector-and-rbac-scope/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Authorize secure DNS UPDATE operations at the zone boundary > Use RFC 3007 — Secure Domain Name System (DNS) Dynamic Update to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/authorize-secure-dns-update-operations-at-the-zone-boundary/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:49+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3007 — Secure Domain Name System (DNS) Dynamic Update to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3007 — Secure Domain Name System (DNS) Dynamic Update ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Authorize secure DNS UPDATE operations at the zone boundary. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3007 — Secure Domain Name System (DNS) Dynamic Update](https://www.rfc-editor.org/rfc/rfc3007.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Every secure dynamic update carries TSIG or SIG(0) authentication so the primary server can identify the update principal. The research record locates this support at Section 2 (Authentication). - A TKEY-derived shared secret established without authentication must not be used to authorize secure dynamic updates. The research record locates this support at Section 2 (Authentication), dynamically configured secrets. - The primary server denies zone changes by default and permits only actions explicitly authorized by policy for the authenticated principal. The research record locates this support at Section 3 (Policy). The source support ends with the statements listed above. Use them to examine authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2 (Authentication), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2 (Authentication), dynamically configured secrets, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 3 (Policy), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from Section 2 (Authentication); Section 2 (Authentication), dynamically configured secrets; Section 3 (Policy) through zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 3007 — Secure Domain Name System (DNS) Dynamic Update](https://www.rfc-editor.org/rfc/rfc3007.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 3007 — Secure Domain Name System (DNS) Dynamic Update - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3007.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Authorize secure DNS UPDATE operations at the zone boundary,” DSE Security, https://update.dsesecurity.com/updates/authorize-secure-dns-update-operations-at-the-zone-boundary/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Avoid duplicate Okta ingestion when enabling the Defender for Identity connector > Use Connect Okta to Microsoft Defender for Identity (Preview) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/avoid-duplicate-okta-ingestion-with-defender-for-identity-connector/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:17+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Connect Okta to Microsoft Defender for Identity (Preview) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Connect Okta to Microsoft Defender for Identity (Preview) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Avoid duplicate Okta ingestion when enabling the Defender for Identity connector. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Connect Okta to Microsoft Defender for Identity (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/okta-integration) from Microsoft supports the following bounded statements: - The connector collects Okta system logs once and shares them with supported Microsoft security products to reduce API use and duplicate collection. The research record locates this support at Opening overview. - If Okta is already integrated through Microsoft Defender for Cloud Apps, enabling the Defender for Identity connection can cause duplicate Okta data in the Defender portal. The research record locates this support at Duplicate-data warning. Keep the evidence boundary at these traced claims. They support a review of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The connector is marked Preview; inventory existing integrations and validate resulting records before changing production collection. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Duplicate-data warning, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to Opening overview; Duplicate-data warning and to observable material such as integration configuration, connectivity tests, event timestamps, alert correlation, role assignments, and case records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Connect Okta to Microsoft Defender for Identity (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/okta-integration) — Microsoft ## Primary reference - Name: Connect Okta to Microsoft Defender for Identity (Preview) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/okta-integration - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Avoid duplicate Okta ingestion when enabling the Defender for Identity connector,” DSE Security, https://update.dsesecurity.com/updates/avoid-duplicate-okta-ingestion-with-defender-for-identity-connector/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # AXIS OS security updates: verify camera firmware tracks and deployed versions > Axis lists multiple 2026 AXIS OS security advisories and patched versions. Camera fleets should be inventoried and updated against the correct supported track. - Canonical URL: https://update.dsesecurity.com/updates/axis-os-security-updates-firmware-tracks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-16T10:00:00+00:00 - Modified: 2026-07-19T19:06:30+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Video Surveillance - Reading time: 2 minutes ## What you need to know Axis lists multiple 2026 AXIS OS security advisories and patched versions. Camera fleets should be inventoried and updated against the correct supported track. ## Potentially affected Axis network devices running AXIS OS, including cameras and related devices whose deployed firmware is older than the vendor-patched release for an applicable advisory. ## DSE recommendation Inventory device models and AXIS OS tracks, compare them with the official Axis advisory registry, back up configurations, and stage vendor-supported firmware updates before broader deployment. ## Article ## What the official registry shows Axis maintains a public security-advisory registry that maps disclosed vulnerabilities to severity information and patched AXIS OS versions. The current 2026 section includes product-specific vulnerabilities as well as affected open-source components. Axis release notes also identify which issues are addressed in individual AXIS OS releases. This does not mean every listed vulnerability affects every Axis device in the same way. Model support, installed applications, firmware track, configuration, network exposure, and authentication requirements can materially change risk. ## Why inventory comes first A reliable camera-firmware program starts with a model and version inventory. Teams should know which devices run an active track, which depend on a long-term support track, and which have reached a point where replacement planning is safer than indefinite exception handling. ## DSE firmware-readiness checklist - Export or verify the camera inventory, including model, serial number, IP address, site, and current AXIS OS version. - Use the official Axis advisory registry and release notes to determine applicability. - Confirm that the target firmware is supported for each model and intended track. - Back up device configurations and record specialized analytics or integrations. - Test representative devices for video, recording, analytics, events, time sync, and VMS integration. - Schedule phased updates to preserve coverage and allow recovery if a device does not return cleanly. - Validate live view, recorded video, alerts, and retention after deployment. Do not treat a version number alone as authorization to update a production fleet. Use device-specific vendor guidance and a coverage-aware deployment plan. ## Primary reference - Name: Axis Security Advisories - Authority: Axis Communications - URL: https://help.axis.com/en-US/security-advisories - Source publication date: Not stated by the source ## Citation and use Preferred citation: “AXIS OS security updates: verify camera firmware tracks and deployed versions,” DSE Security, https://update.dsesecurity.com/updates/axis-os-security-updates-firmware-tracks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Back up both local administrator and DSRM passwords with Windows LAPS > Use Windows LAPS overview to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/back-up-local-admin-and-dsrm-passwords-with-windows-laps/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:04+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Windows LAPS overview to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Windows LAPS overview ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Back up both local administrator and DSRM passwords with Windows LAPS. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Windows LAPS overview](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview) from Microsoft supports the following bounded statements: - Windows LAPS automatically manages and backs up a local administrator password for Entra-joined or AD-joined devices. The research record locates this support at Opening overview. - It can also manage and back up the DSRM account password on AD domain controllers. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Authorize password retrieval narrowly and design post-authentication rotation and audit. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios are in and out of scope? - Which condition in Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as policy exports, directory access-control entries, sanitized client events, rotation tests, retrieval authorization, and exception records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Windows LAPS overview](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview) — Microsoft ## Primary reference - Name: Windows LAPS overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-overview - Source publication date: 2025-03-10 ## Citation and use Preferred citation: “Back up both local administrator and DSRM passwords with Windows LAPS,” DSE Security, https://update.dsesecurity.com/updates/back-up-local-admin-and-dsrm-passwords-with-windows-laps/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Back up every production GPO on a defined schedule > Use Back Up and Restore Group Policy in Windows to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/back-up-production-gpos-on-defined-schedule/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:45+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Back Up and Restore Group Policy in Windows to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Back Up and Restore Group Policy in Windows ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Back up every production GPO on a defined schedule. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Back Up and Restore Group Policy in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-backup-restore) from Microsoft supports the following bounded statements: - GPO backup and restore protects deployments from errors and disasters and avoids manual reconstruction. The research record locates this support at Opening overview. - GPMC can copy GPOs across domains or import backed-up settings even where no trust relationship exists. The research record locates this support at Opening overview. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles only where the source and recorded environment align. ## What the source does not establish Test restored settings and migration tables before linking a recovered or copied GPO. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from Opening overview; Opening overview to the observed environment. Useful domain evidence includes directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Back Up and Restore Group Policy in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-backup-restore) — Microsoft ## Primary reference - Name: Back Up and Restore Group Policy in Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-backup-restore - Source publication date: 2025-07-10 ## Citation and use Preferred citation: “Back up every production GPO on a defined schedule,” DSE Security, https://update.dsesecurity.com/updates/back-up-production-gpos-on-defined-schedule/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Back up physical-security controllers like OT: configurations, tools, licenses, spares, and restore tests > NIST SP 1339 treats OT recovery as more than copying configuration files: tools, licenses, compatible spares, documentation, integrity, and restore tests all matter. - Canonical URL: https://update.dsesecurity.com/updates/physical-security-ot-backup-restore-testing/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:29:04+00:00 - Modified: 2026-07-19T21:29:04+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know NIST SP 1339 treats OT recovery as more than copying configuration files: tools, licenses, compatible spares, documentation, integrity, and restore tests all matter. ## Potentially affected Physical-security controllers and related OT-like infrastructure whose recovery depends on configurations, firmware, software, licenses, engineering tools, diagrams, or spare hardware. ## DSE recommendation Connect backups to inventory and change management, protect redundant copies, preserve recovery dependencies, and prove restoration on nonproduction equipment. ## Article ## Recovery starts with inventory Source fact: NIST SP 1339 says effective OT backup management integrates backups into change management, creates them regularly, tests them, and reviews them during recovery exercises. Its prerequisites begin with identifying configuration-bearing or process-supporting devices, keeping the asset inventory current, and assigning mission criticality to set frequency, retention, and recovery order. The required recovery set extends beyond a single export. NIST lists program and configuration files, firmware, software applications, operating-system or virtual-machine images, license keys, vendor tools, support documentation, and other materials needed for redeployment. It also recommends compatible spare parts that can meet recovery objectives and reduce supply-chain delay. ## Protect useful, restorable copies Backup frequency, media, and storage location should reflect how often information changes, system type, and risk. NIST recommends redundant storage on site and off site, protection from unauthorized access or destruction, and integrity and availability mechanisms such as hashing, encryption, or write-once media. It distinguishes hot backups for immediate failover, warm backups for quicker recovery with updated data, and cold backups or spares that require rebuilding. Testing is functional. NIST calls for recurring restoration on nonproduction systems to validate media reliability, practice the procedure, and confirm the restored system works. Hashing can verify content integrity where feasible, while native engineering comparisons can be appropriate for OT assets. Lessons from tests should update procedures. Engineering documents provide another recovery layer. NIST lists items such as network and wiring diagrams, equipment specifications, configuration details, and other documents that support verification and troubleshooting. ## Applicability boundary SP 1339 is an OT quick-start guide with a manufacturing-sector context. Applying its approach to physical access controllers or other security infrastructure is DSE synthesis and should be limited to systems whose operational characteristics fit. Vendor-supported export and restore instructions still govern the product. Configuration backup also does not replace recorded-video retention, database protection, redundancy, or an exercised business-continuity plan. ## DSE recovery checklist DSE recommendation: This checklist is DSE operational synthesis from SP 1339; apply it only where the physical-security system’s operational characteristics fit. - Identify every component that holds configuration or is required to rebuild the service. - Set recovery order, frequency, retention, and copy locations from criticality and change rate. - Export after approved changes and retain exact firmware, installers, licenses, utilities, cables, keys, and manuals. - Maintain protected onsite and offsite copies with inventory labels and integrity records. - Keep compatible, tested spares for components whose replacement lead time exceeds the recovery objective. - Restore onto nonproduction or spare equipment and test communications, doors, events, time, users, and monitoring. - Verify hashes and compare restored configuration using supported native tools. - Update runbooks, diagrams, inventories, and backup scope after each exercise or material change. ## Official references - [NIST SP 1339 publication record](https://csrc.nist.gov/pubs/sp/1339/final) — the official CSRC status, publication details, and download page. - [NIST SP 1339: OT Backup Quick Start Guide](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1339.pdf) — the June 17, 2026 inventory, backup, dependency, integrity, restoration, and documentation guidance. ## Primary reference - Name: NIST SP 1339 — OT Backup Quick Start Guide - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/1339/final - Source publication date: 2026-06-17 ## Citation and use Preferred citation: “Back up physical-security controllers like OT: configurations, tools, licenses, spares, and restore tests,” DSE Security, https://update.dsesecurity.com/updates/physical-security-ot-backup-restore-testing/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Back up the Network Controller database before SDN maintenance > Which Network Controller state must an SDN maintenance recovery plan preserve? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-154-back-up-the-network-controller-database-before-sdn-maintenance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:37+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which Network Controller state must an SDN maintenance recovery plan preserve? ## Potentially affected Administrators maintaining the multi-node SDN infrastructure described in Microsoft’s upgrade and recovery guidance. ## DSE recommendation Have the SDN owner identify the database backup artifact, protected destination, retention owner, and approved restore instructions. ## Article ## Source facts Microsoft’s SDN maintenance guidance distinguishes a Network Controller database backup from backups of the controller VMs. It states that VM backups alone do not ensure session continuity across multiple controller nodes. After upgrading a controller node, the procedure checks its status with Get-NetworkControllerNode and waits for Up before upgrading another node. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Update-Backup-Restore). ## Applicability Identify the actual SDN architecture and releases and compare them with the documented procedure. Review the supported backup and restore process for that design before applying guidance from a different controller hosting model. ## DSE recommendation Have the SDN owner identify the database backup artifact, protected destination, retention owner, and approved restore instructions. Record controller node status before maintenance. Establish a pause condition if a node does not return to the expected state, and keep the backup decision separate from ordinary VM snapshot activity. ## Verification Verify that the intended backup operation completed and that its artifact can be located and checked. In an approved recovery exercise, validate the documented restoration path and representative network policy state. During maintenance, record each node’s return to service before proceeding and retain unexplained controller errors for investigation. ## Official references [Microsoft Learn: Upgrade, backup, and restore SDN infrastructure](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Update-Backup-Restore). Source reviewed September 8, 2026. ## Primary reference - Name: Upgrade, backup, and restore SDN infrastructure - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Update-Backup-Restore - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Back up the Network Controller database before SDN maintenance,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-154-back-up-the-network-controller-database-before-sdn-maintenance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Back up the root CA before renewing its certificate > Use Renew root CA certificate in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/back-up-root-ca-before-certificate-renewal/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:06+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Renew root CA certificate in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Renew root CA certificate in Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Back up the root CA before renewing its certificate. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Renew root CA certificate in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/renew-root-ca-certificate) from Microsoft supports the following bounded statements: - A root CA self-signs at the top of the PKI hierarchy, so its renewal preserves continued trust. The research record locates this support at Opening overview. - Microsoft documents renewal with an existing or new key pair and makes root-CA backup the first procedure step. The research record locates this support at Sections: renewal options; Step 1 – Back up the root CA. Keep the evidence boundary at these traced claims. They support a review of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Plan chain rollover, publication, relying-party compatibility, and old-key retention before renewal. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: renewal options; Step 1 – Back up the root CA, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles are in and out of scope? - Which condition in Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Sections: renewal options; Step 1 – Back up the root CA through CA and template exports, enrollment tests, certificate chains, access-control entries, event logs, and revocation-path checks. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Renew root CA certificate in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/renew-root-ca-certificate) — Microsoft ## Primary reference - Name: Renew root CA certificate in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/renew-root-ca-certificate - Source publication date: 2025-03-13 ## Citation and use Preferred citation: “Back up the root CA before renewing its certificate,” DSE Security, https://update.dsesecurity.com/updates/back-up-root-ca-before-certificate-renewal/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Backups are not recovery until restoration is tested > A successful backup job does not prove that systems and data can be restored. Build a documented restoration test around critical services, protected backup copies, clean recovery prerequisites, accountable owners, and evidence from an actual test. - Canonical URL: https://update.dsesecurity.com/updates/backups-restoration-testing-recovery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:09+00:00 - Modified: 2026-07-19T19:03:09+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 2 minutes ## What you need to know A successful backup job does not prove that systems and data can be restored. Build a documented restoration test around critical services, protected backup copies, clean recovery prerequisites, accountable owners, and evidence from an actual test. ## Potentially affected Organizations relying on file, server, application, cloud, or infrastructure backups for continuity or ransomware recovery. ## DSE recommendation Select one critical service, define a safe restoration test, perform it in an isolated or approved environment, and record results and remediation work. ## Article A backup console can report success even when an organization cannot restore a usable business service. Recovery also depends on credentials, encryption keys, software, configuration, infrastructure, documentation, clean systems, and people who know the sequence. ## What the official source says Source fact: CISA’s #StopRansomware Guide recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity in a disaster-recovery scenario. CISA warns that ransomware may attempt to find and delete or encrypt accessible backups. The guide also discusses protected system images, critical-asset prioritization, secured logs, and rebuilding on a clean network. ## Define what “restored” means DSE recommendation: test a complete, representative service rather than restoring a random file and calling the exercise finished. Before the test, document the business owner, technical owner, approved test environment, recovery point being tested, expected dependencies, validation method, and stop conditions. - Identify the authoritative backup set and confirm that access is restricted. - Confirm required credentials, recovery keys, licenses, installers, configuration, certificates, and documentation. - Use an isolated or otherwise approved destination that will not overwrite production data. - Scan or validate recovered material according to the organization’s incident and recovery plan. - Have the business owner verify that the restored information or application is complete and usable. - Record elapsed time, errors, manual work, missing dependencies, and the exact evidence retained. ## Review the failure modes A restoration test should look beyond backup-job status. Check whether one compromised identity could reach production systems and backup administration, whether deletion protections can be changed too easily, whether alerts reach an attended destination, and whether the documented recovery order matches current business dependencies. Cloud data also needs an explicit recovery decision; provider availability, retention, recycle bins, version history, and a separate backup are different capabilities. DSE recommendation: treat every failed or partially successful test as useful evidence. Open remediation items with owners and due dates, then repeat the affected portion. Preserve safe test records without including passwords, recovery keys, customer data, or sensitive topology in a broadly accessible report. ## Claims to avoid Do not advertise a recovery-time objective, recovery-point objective, immutability guarantee, or successful disaster recovery unless the organization has defined the metric and produced current test evidence. One restored file does not validate an application, and one application test does not validate the entire environment. Practical next step: choose one important but safely testable service. Restore it to an approved location, have the owner validate it, document every dependency, and schedule the next test based on risk and change rate. ## Primary reference - Name: CISA #StopRansomware Guide - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/resources-tools/resources/stopransomware-guide - Source publication date: 2023-10-19 ## Citation and use Preferred citation: “Backups are not recovery until restoration is tested,” DSE Security, https://update.dsesecurity.com/updates/backups-restoration-testing-recovery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bank physical security annual review: evidence for the board report > A bank security review should connect procedures, training, device testing, incidents, local risk, and unresolved exceptions so the security officer can report on program effectiveness, not simply equipment presence. - Canonical URL: https://update.dsesecurity.com/updates/bank-physical-security-annual-review-board-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-28T14:22:00+00:00 - Modified: 2026-07-28T14:22:00+00:00 - Last reviewed by DSE: 2026-07-28 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity, Video Surveillance - Reading time: 3 minutes ## What you need to know A bank security review should connect procedures, training, device testing, incidents, local risk, and unresolved exceptions so the security officer can report on program effectiveness, not simply equipment presence. ## Potentially affected State-chartered banks that are members of the Federal Reserve System and evaluate their program under 12 CFR 208.61, plus security, facilities, audit, risk, compliance, and board-support teams assisting with the report. ## DSE recommendation Confirm the institution and offices governed by the rule, then assemble location-aware evidence and document conclusions, exceptions, ownership, and follow-up for the security officer’s annual board report. ## Article ## Source fact: first confirm that this rule applies Federal Reserve Regulation H, [12 CFR 208.61](https://www.federalreserve.gov/frrs/regulations/section-20861-bank-security-procedures.htm), governs bank security procedures for state-chartered banks that are members of the Federal Reserve System; a separate subsection addresses Reserve Banks. It should not be assumed to govern a national bank, insured state nonmember bank, savings association, credit union, fintech, or vendor merely because that organization performs financial services. Legal or compliance personnel should confirm charter, regulator, covered offices, current rule, parallel requirements, and record-retention duties. This article is operational guidance, not legal advice. For a covered state member bank, the rule makes the board responsible for compliance and requires a written security program for the main office and branches. The board designates a security officer who develops and administers the program, subject to board approval. The program addresses opening and closing, safeguarding currency and similar valuables, identifying people committing crimes and preserving useful evidence, initial and periodic employee training, and selecting, testing, operating, and maintaining appropriate security devices. The security officer must report to the board at least annually on implementation, administration, and effectiveness. The rule does not prescribe a report template, score, page count, or particular certification. Any evidence structure or rating method adopted by the bank should be labeled as its own governance design. ## Review the program as an operating system Reconcile the official office population with the written program, monitoring accounts, device inventory, training population, service records, incidents, and prior commitments. Document scope decisions for drive-throughs, ATM areas, operations sites, temporary facilities, or closed locations. For each covered office, compare the controlled procedure with an observed, authorized opening or closing exercise and current handling of valuables, keys, credentials, exceptions, and after-hours escalation. Reassess local crime, exposed values, law-enforcement distance, physical surroundings, staffing, hours, floor plan, lighting, tenant occupancy, and significant incidents. An unchanged equipment list does not prove that safeguards remain appropriate after operating or environmental changes. ## DSE recommendation: produce decision-useful evidence - Record the location, control or asset, test method, date, result, tester, reviewer, exception, and linked remediation for each sampled item. - For alarms, coordinate safe testing with monitoring and confirm event, zone, account, notification, restoration, and return to service. Do not cause an uncoordinated police dispatch. - For video used to identify offenders or preserve evidence, test representative retrieval, timestamp accuracy, image usefulness under relevant lighting, export, access control, and chain of custody. - For access, locks, and lighting, sample exterior openings, privileged credentials, after-hours schedules, departed personnel, maintenance, and actual operating conditions. - Assess training by role, shift, new-hire and refresher coverage, exercises, missed-training remediation, and whether personnel can perform approved actions during and after an event. - Present significant failures, incomplete coverage, residual risk, compensating measures, required investment, accountable owners, target dates, and prior-year closure evidence. A vendor invoice or configuration screenshot can support the record but does not alone prove end-to-end operation. Protect detailed diagrams, response instructions, contact lists, and weaknesses as sensitive records. The annual conclusion should clearly distinguish verified facts, management judgment, sampling limits, and unresolved risk so the board can make informed decisions and the next review can show outcomes. ## Primary reference - Name: Federal Reserve Regulation H: 12 CFR 208.61 - Authority: www.federalreserve.gov - URL: https://www.federalreserve.gov/frrs/regulations/section-20861-bank-security-procedures.htm - Source publication date: 2026-07-28 ## Citation and use Preferred citation: “Bank physical security annual review: evidence for the board report,” DSE Security, https://update.dsesecurity.com/updates/bank-physical-security-annual-review-board-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Base RDS session-host sizing on the users’ actual workload mix > Which workload and concurrency assumptions should an RDS session-host sizing estimate state? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-127-base-rds-session-host-sizing-on-the-users-actual-workload-mix/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:04+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which workload and concurrency assumptions should an RDS session-host sizing estimate state? ## Potentially affected Administrators sizing Remote Desktop Services or Azure Virtual Desktop session hosts. ## DSE recommendation Build a sizing worksheet with named applications, representative user activity, peak concurrency, and planned growth. ## Article ## Source facts Microsoft describes session-host capacity planning as estimating required resources and users per host from current and future workload demand. The workload mix affects density: light data-entry work and demanding 3D applications can support different user counts on the same hardware. The guidance distinguishes a single-session host, with one signed-in user, from a multi-session host serving several users concurrently. Multi-session deployment allows more than one signed-in user on the host VM. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/session-host-virtual-machine-sizing-guidelines). ## Applicability Identify the deployment type, application mix, concurrency pattern, user groups, and service targets. Review the source’s sizing guidance for the relevant workload class rather than treating one example density as universal. ## DSE recommendation Build a sizing worksheet with named applications, representative user activity, peak concurrency, and planned growth. Ask the application owners to approve the workload model. Choose a pilot host and define the user experience measures that will determine whether its proposed density is acceptable. ## Verification Run representative sessions together and measure the agreed experience and resource indicators during realistic activity. Include login periods and a demanding application task. Record the tested user count and workload mix with the results, and revise the estimate when those assumptions change. ## Official references [Microsoft Learn: Session Host Virtual Machine Sizing Guidelines for Remote Desktop](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/session-host-virtual-machine-sizing-guidelines). Source reviewed September 8, 2026. ## Primary reference - Name: Session Host Virtual Machine Sizing Guidelines for Remote Desktop - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/session-host-virtual-machine-sizing-guidelines - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Base RDS session-host sizing on the users’ actual workload mix,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-127-base-rds-session-host-sizing-on-the-users-actual-workload-mix/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Base the Facility Security Plan on an approved assessment and site-specific operations > Use 33 CFR 105.400 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/base-the-facility-security-plan-on-an-approved-assessment-and-site-specific-operations/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:55+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.400 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.400 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Base the Facility Security Plan on an approved assessment and site-specific operations. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.400 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.400) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, an FSP must address every vulnerability identified in the Facility Security Assessment. The research record locates this support at 33 CFR 105.400(a)(3), read with 33 CFR 105.400(a) (eCFR anchor p-105.400(a)(3)). - Under 33 CFR 105, an FSP may cover multiple facilities with similar designs and operations only when the cognizant COTP authorizes and approves that scope. The research record locates this support at 33 CFR 105.400(a)(5), read with 33 CFR 105.400(a) (eCFR anchor p-105.400(a)(5)). Only the traced statements above are asserted as source facts. Apply the review to access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths after confirming that the source and deployed context match. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.400(a)(3), read with 33 CFR 105.400(a) (eCFR anchor p-105.400(a)(3)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.400(a)(5), read with 33 CFR 105.400(a) (eCFR anchor p-105.400(a)(5)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to 33 CFR 105.400(a)(3), read with 33 CFR 105.400(a) (eCFR anchor p-105.400(a)(3)); 33 CFR 105.400(a)(5), read with 33 CFR 105.400(a) (eCFR anchor p-105.400(a)(5)) and to observable material such as asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [33 CFR 105.400 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.400) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.400 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.400 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Base the Facility Security Plan on an approved assessment and site-specific operations,” DSE Security, https://update.dsesecurity.com/updates/base-the-facility-security-plan-on-an-approved-assessment-and-site-specific-operations/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Baseline delay, loss, and delay variation before a network complaint becomes guesswork > Network quality needs defined paths, packet types, intervals, clocks, and statistics. Build directional baselines for delay, loss, and delay variation before users report a vague slowdown. - Canonical URL: https://update.dsesecurity.com/updates/baseline-network-delay-loss-delay-variation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:18:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 4 minutes ## What you need to know Network quality needs defined paths, packet types, intervals, clocks, and statistics. Build directional baselines for delay, loss, and delay variation before users report a vague slowdown. ## Potentially affected WAN and internet circuits; LAN paths; VPNs; voice and video; cloud applications; network monitoring; synthetic probes; timestamps; service-level reporting; and escalation workflows. ## DSE recommendation Define representative measurement paths and methods, synchronize clocks, collect directional delay, loss, and variation over business cycles, use distributions rather than one average, annotate change, and retain raw evidence. ## Article ## Source facts: performance metrics require defined measurement conditions [RFC 2330](https://www.rfc-editor.org/info/rfc2330) establishes a framework for IP performance metrics. It emphasizes clearly defined metrics, measurement methods, repeatability, statistical treatment, and the conditions under which observations are made. The framework warns against presenting a measurement without enough context to understand what was actually tested. RFC 3393 defines IP packet delay variation metrics, including concepts used to describe differences in one-way delay between selected packets. RFC 7680 defines one-way packet loss metrics. These documents use precise packet streams, source and destination points, timing, and statistical samples. They do not reduce network quality to one universal “jitter” or “packet loss” value. Round-trip ping can be a useful operational test, but it combines two directions, can receive different treatment than application traffic, and may be rate limited or deprioritized. One-way measurements need synchronized clocks. Synthetic probes do not necessarily follow the same path or policy as user traffic. An average can hide bursts, tails, directionality, and time-of-day behavior that make a service unusable. ## DSE recommendation: build a baseline that can survive an escalation Begin with the business service and its path. The objective is evidence that can show when and where experience changed, not the largest possible collection of unrelated telemetry. - Define the service question. Identify the application, sites, user populations, traffic direction, service hours, critical transactions, expected dependencies, and the decision the measurement should support. Separate availability, response time, throughput, loss, delay, and delay variation. - Choose representative endpoints. Place probes on the actual sides of meaningful boundaries: user LAN, WAN edge, data center, cloud region, VPN termination, voice gateway, or provider handoff. Record routing, tunnels, quality-of-service policy, and address translation that may affect the path. - Document the method. Record protocol, packet size, marking, interval, timeout, sample selection, one-way or round-trip interpretation, clock source, tool version, and retention. Test whether network policy treats the probe differently from the application before claiming equivalence. - Collect a business-cycle baseline. Measure weekdays, weekends, maintenance periods, backups, shift changes, busy hours, and known low-use windows. Preserve distributions and percentiles, not only averages. Keep direction-specific delay and loss where the method supports them. - Correlate context. Annotate carrier incidents, routing changes, interface errors and discards, utilization, queue drops, wireless health, VPN changes, security inspection, cloud status, and application events. A coincident metric is a lead to investigate, not proof of causation. - Set evidence-based thresholds. Use observed normal ranges, application tolerance, and contractual targets. Define duration and sample requirements so a single unusual packet does not create noise, while sustained degradation and short severe bursts remain visible. - Preserve escalation evidence. Retain raw samples or sufficient aggregates, timestamps, endpoint health, path information, configuration versions, and event annotations. Give providers the exact affected direction, interval, method, baseline comparison, and supporting interface or path data. Validate the monitor itself. During a controlled window, create a known amount of representative traffic, introduce a safe rate limit or path change where authorized, and compare the expected effect with the recorded samples. Confirm that the probe reports its own health, a missing sample is not converted to zero loss or zero delay, clock problems are visible, and maintenance suppression does not erase the underlying evidence. Revalidate after probe, routing, tunnel, quality-of-service, or collector changes. Factual boundary: Delay, loss, and delay variation measurements describe the selected packets between selected points under selected conditions. They do not by themselves locate the fault or prove that a carrier, firewall, application, or endpoint caused it. Route asymmetry and traffic treatment can limit inference. Track baseline coverage for critical services, probe availability, clock quality, directional loss, tail latency, delay variation, threshold events, unresolved path changes, and time to isolate a fault domain. When a user says “the network is slow,” the team should be able to compare the complaint with a defined, recent normal state and decide the next diagnostic step. ## Official references - IETF, [Framework for IP Performance Metrics](https://www.rfc-editor.org/info/rfc2330), RFC 2330. - IETF, [IP Packet Delay Variation Metric for IP Performance Metrics](https://www.rfc-editor.org/info/rfc3393/), RFC 3393. - IETF, [A One-Way Loss Metric for IP Performance Metrics](https://www.rfc-editor.org/info/rfc7680/), RFC 7680. ## Primary reference - Name: IETF RFC 2330: Framework for IP Performance Metrics - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/info/rfc2330 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Baseline delay, loss, and delay variation before a network complaint becomes guesswork,” DSE Security, https://update.dsesecurity.com/updates/baseline-network-delay-loss-delay-variation/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Baseline Windows DNS-over-HTTPS events and counters separately from port 53 > Use Monitor DNS over HTTPS events and performance in DNS Server on Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/baseline-windows-dns-over-https-events-and-counters-separately-from-port-53/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:39+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Monitor DNS over HTTPS events and performance in DNS Server on Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Monitor DNS over HTTPS events and performance in DNS Server on Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Baseline Windows DNS-over-HTTPS events and counters separately from port 53. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Monitor DNS over HTTPS events and performance in DNS Server on Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/monitor-dns-over-https) from Microsoft supports the following bounded statements: - Windows DNS Server records DNS-over-HTTPS operational events in dedicated DNS Server event-log channels described by the page. The research record locates this support at Monitor events; Event channels and event IDs. - Windows exposes separate DNS-over-HTTPS request, response, and dropped-request performance counters, and those counters reset when the DNS Server service restarts. The research record locates this support at Monitor performance; DNS-over-HTTPS performance counters; Note. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish These events and counters show Windows DNS-over-HTTPS activity and drops; they do not by themselves establish confidentiality, client adoption, root cause, or acceptable capacity. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Monitor events; Event channels and event IDs, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Monitor performance; DNS-over-HTTPS performance counters; Note, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Monitor events; Event channels and event IDs; Monitor performance; DNS-over-HTTPS performance counters; Note. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Monitor DNS over HTTPS events and performance in DNS Server on Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/monitor-dns-over-https) — Microsoft ## Primary reference - Name: Monitor DNS over HTTPS events and performance in DNS Server on Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/monitor-dns-over-https - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Baseline Windows DNS-over-HTTPS events and counters separately from port 53,” DSE Security, https://update.dsesecurity.com/updates/baseline-windows-dns-over-https-events-and-counters-separately-from-port-53/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Batch JMAP calls while preserving state-token and error semantics > Use RFC 8620 — The JSON Meta Application Protocol (JMAP) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/batch-jmap-calls-while-preserving-state-token-and-error-semantics/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:08+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8620 — The JSON Meta Application Protocol (JMAP) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8620 — The JSON Meta Application Protocol (JMAP) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Batch JMAP calls while preserving state-token and error semantics. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8620 — The JSON Meta Application Protocol (JMAP)](https://www.rfc-editor.org/rfc/rfc8620.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - One JMAP API request carries an ordered array of method calls, which the server processes sequentially and answers with an ordered response array. The research record locates this support at Sections 3 (Structured Data Exchange) and 3.3 (The Request Object). - A /changes response links old and new state tokens; when an intermediate state cannot be calculated, the server returns cannotCalculateChanges and the client invalidates its cache. The research record locates this support at Section 5.2 (/changes). - A /set call may partly succeed across different objects, but an individual object’s update is atomic and an ifInState mismatch aborts the method with stateMismatch. The research record locates this support at Section 5.3 (/set). Only the traced statements above are asserted as source facts. Apply the review to sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Sections 3 (Structured Data Exchange) and 3.3 (The Request Object), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 5.2 (/changes), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5.3 (/set), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from Sections 3 (Structured Data Exchange) and 3.3 (The Request Object); Section 5.2 (/changes); Section 5.3 (/set) to the observed environment. Useful domain evidence includes sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 8620 — The JSON Meta Application Protocol (JMAP)](https://www.rfc-editor.org/rfc/rfc8620.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8620 — The JSON Meta Application Protocol (JMAP) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8620.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Batch JMAP calls while preserving state-token and error semantics,” DSE Security, https://update.dsesecurity.com/updates/batch-jmap-calls-while-preserving-state-token-and-error-semantics/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Benchmark SMB compression with representative files and network conditions > When should a team request SMB compression for a file-transfer workload? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-039-benchmark-smb-compression-with-representative-files-and-network-conditions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:32+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know When should a team request SMB compression for a file-transfer workload? ## Potentially affected Use this review for a file-transfer path whose endpoints meet the current SMB compression requirements. ## DSE recommendation Select representative files and define whether elapsed transfer time, network demand, or another workload outcome motivates the change. ## Article ## Source facts SMB compression compresses data during transfer instead of requiring a separate compress-copy-expand workflow. Microsoft describes a tradeoff between reduced network usage and additional processor work, with benefits depending on network conditions. Compression can be configured from the SMB client or server side; those labels describe transfer roles rather than operating-system editions. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-compression). ## Applicability Use this review for a file-transfer path whose endpoints meet the current SMB compression requirements. Identify the actual sender, receiver, file set, and network conditions before choosing where compression should be requested. ## DSE recommendation Select representative files and define whether elapsed transfer time, network demand, or another workload outcome motivates the change. Record the request configuration and test conditions for both endpoints. Compare transfers with and without the approved compression setting under similar conditions. Include processor observations and the impact on other work, rather than judging the result only by bytes transferred. ## Verification Confirm the endpoint configuration and collect the agreed transfer measurements. Check that the destination files are complete and usable. Record processor and network observations for the same time interval. Keep the conclusion specific to the tested files and path; revisit it if the network capacity, application activity, or file mix materially changes. ## Official references [Microsoft Learn: SMB Compression](https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-compression). Source reviewed September 8, 2026. ## Primary reference - Name: SMB Compression - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-compression - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Benchmark SMB compression with representative files and network conditions,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-039-benchmark-smb-compression-with-representative-files-and-network-conditions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bind NPS RADIUS traffic to the intended network interfaces > Which interfaces and UDP ports should an NPS server use for RADIUS? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-181-bind-nps-radius-traffic-to-the-intended-network-interfaces/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:10+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Which interfaces and UDP ports should an NPS server use for RADIUS? ## Potentially affected Administrators configuring Network Policy Server on a multihomed Windows server. ## DSE recommendation Write an interface-and-port matrix before changing the NPS Ports settings. ## Article ## Source facts By default, NPS listens for IPv4 and IPv6 RADIUS traffic on every installed network adapter using ports 1812, 1813, 1645, and 1646. Administrators can specify particular adapters when they need to exclude an interface from RADIUS traffic. Microsoft requires access servers to use the same RADIUS port numbers as NPS and notes that some devices use the older 1645 and 1646 defaults. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-multihomed-configure). ## Applicability Inventory the server interfaces, their intended purpose, and the authentication and accounting ports configured on each access device. Treat IPv4 and IPv6 as explicit entries. Do not infer that an adapter intended only for management is excluded from NPS listening. ## DSE recommendation Write an interface-and-port matrix before changing the NPS Ports settings. Include the exact local address, protocol family, request type, and permitted access devices. Have the network owner compare it with the corresponding device settings and firewall rules. Preserve the original configuration and pilot one access path before changing all devices. Define how operators will recover access if the expected listener is unavailable. ## Verification Send controlled authentication and accounting requests from representative access devices and confirm their arrival on the intended interface. Check an excluded interface as a negative case. Record listener settings, device port values, and correlated results; investigate a silent accounting path separately from a successful sign-in. ## Official references [Microsoft Learn: Configure NPS on a Multihomed Computer](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-multihomed-configure). Source reviewed September 8, 2026. ## Primary reference - Name: Configure NPS on a Multihomed Computer - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-multihomed-configure - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bind NPS RADIUS traffic to the intended network interfaces,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-181-bind-nps-radius-traffic-to-the-intended-network-interfaces/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bind QUIC packet-protection keys to the correct TLS encryption level > Use RFC 9001 — Using TLS to Secure QUIC to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/bind-quic-packet-protection-keys-to-the-correct-tls-encryption-level/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:00+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 9001 — Using TLS to Secure QUIC to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 9001 — Using TLS to Secure QUIC ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Bind QUIC packet-protection keys to the correct TLS encryption level. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 9001 — Using TLS to Secure QUIC](https://www.rfc-editor.org/rfc/rfc9001.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - TLS’s current encryption level determines the QUIC packet type and keys; Initial, 0-RTT, Handshake, and 1-RTT use distinct level secrets, and CRYPTO frames omit 0-RTT. The research record locates this support at Section 4.1.3 (Sending and Receiving Handshake Messages). - QUIC derives separate directional packet-protection secrets at each encryption level, with Initial secrets coming from the client’s first Destination Connection ID and later secrets from TLS. The research record locates this support at Sections 5.1 (Packet Protection Keys) and 5.2 (Initial Secrets). - Only 1-RTT keys are updated; an endpoint waits for handshake confirmation and acknowledgment in the current phase, toggles Key Phase, and retains old keys through successful new-key processing. The research record locates this support at Sections 6 (Key Update) and 6.1 (Initiating a Key Update). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 4.1.3 (Sending and Receiving Handshake Messages), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 5.1 (Packet Protection Keys) and 5.2 (Initial Secrets), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 6 (Key Update) and 6.1 (Initiating a Key Update), which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, certificates, identity providers, time, content delivery, network paths, and application ownership in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Section 4.1.3 (Sending and Receiving Handshake Messages); Sections 5.1 (Packet Protection Keys) and 5.2 (Initial Secrets); Sections 6 (Key Update) and 6.1 (Initiating a Key Update) to the observed environment. Useful domain evidence includes request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 9001 — Using TLS to Secure QUIC](https://www.rfc-editor.org/rfc/rfc9001.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 9001 — Using TLS to Secure QUIC - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9001.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bind QUIC packet-protection keys to the correct TLS encryption level,” DSE Security, https://update.dsesecurity.com/updates/bind-quic-packet-protection-keys-to-the-correct-tls-encryption-level/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bind shielding data to the template disks a tenant actually trusts > What should a tenant verify before producing a shielding-data file? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-065-bind-shielding-data-to-the-template-disks-a-tenant-actually-trusts/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:06+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What should a tenant verify before producing a shielding-data file? ## Potentially affected Use this review when a tenant prepares shielding data on that separate trusted computer. ## DSE recommendation Review the template catalog separately from the answer-file settings. ## Article ## Source facts A shielding-data file is encrypted and contains sensitive VM-provisioning information supplied by its owner. Microsoft requires a template disk before the file is created. Microsoft directs preparation to a separate trusted computer outside the guarded fabric. An answer file specializes the generalized template for the intended VM. A volume signature catalog identifies trusted template disks. During deployment, provisioning fails if the template matches none of the signatures included in the shielding data. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tenant-creates-shielding-data). ## Applicability Use this review when a tenant prepares shielding data on that separate trusted computer. Identify the approved template, intended VM role, and owner of the provisioning information. Keep sensitive contents out of ordinary review tickets and shared logs. ## DSE recommendation Review the template catalog separately from the answer-file settings. Have the VM owner confirm that the signatures represent only the approved templates and that the intended role is correctly described. Record artifact identities and authorized custodians without reproducing secrets. Establish how a changed template will be approved and reflected in a newly reviewed provisioning artifact. ## Verification Provision an approved test VM using the selected template and shielding data. Confirm its intended role and management access. In a controlled negative test, use an unapproved template and inspect the provisioning result. Retain the artifact identifiers and outcomes together so a successful deployment is tied to the actual trusted template set. ## Official references [Microsoft Learn: Shielded VMs for tenants – Creating shielding data to define a shielded VM](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tenant-creates-shielding-data). Source reviewed September 8, 2026. ## Primary reference - Name: Shielded VMs for tenants - Creating shielding data to define a shielded VM - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tenant-creates-shielding-data - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bind shielding data to the template disks a tenant actually trusts,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-065-bind-shielding-data-to-the-template-disks-a-tenant-actually-trusts/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bind SMTP TLS endpoints to DNSSEC-authenticated TLSA records > Use RFC 7672 — SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/bind-smtp-tls-endpoints-to-dnssec-authenticated-tlsa-records/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:07+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 7672 — SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 7672 — SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Bind SMTP TLS endpoints to DNSSEC-authenticated TLSA records. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 7672 — SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)](https://www.rfc-editor.org/rfc/rfc7672.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A DNSSEC-secure TLSA RRset with at least one usable record requires both TLS encryption and SMTP server authentication. The research record locates this support at Section 2.2 (TLS Discovery), secure usable TLSA result. - If all records in a secure nonempty TLSA RRset are unusable, TLS remains mandatory but authentication is not; lookup errors defer delivery or try another MX. The research record locates this support at Section 2.2 (TLS Discovery), secure unusable and error results. - DANE supplies both the commitment to TLS and the certificate-verification parameters through DNSSEC-authenticated TLSA data. The research record locates this support at Section 3 (DANE Authentication). Only the traced statements above are asserted as source facts. Apply the review to sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 2.2 (TLS Discovery), secure usable TLSA result, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.2 (TLS Discovery), secure unusable and error results, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 3 (DANE Authentication), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Section 2.2 (TLS Discovery), secure usable TLSA result; Section 2.2 (TLS Discovery), secure unusable and error results; Section 3 (DANE Authentication) to the observed environment. Useful domain evidence includes sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 7672 — SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)](https://www.rfc-editor.org/rfc/rfc7672.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 7672 — SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc7672.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bind SMTP TLS endpoints to DNSSEC-authenticated TLSA records,” DSE Security, https://update.dsesecurity.com/updates/bind-smtp-tls-endpoints-to-dnssec-authenticated-tlsa-records/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Block external-tenant sign-in paths only after mapping Tenant Restrictions v2 enforcement > Tenant Restrictions v2 can constrain access to external Microsoft Entra tenants, but authentication-plane and data-plane coverage varies by enforcement method, platform, browser, application, and resource. - Canonical URL: https://update.dsesecurity.com/updates/entra-tenant-restrictions-v2-enforcement-paths/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:30+00:00 - Modified: 2026-08-25T21:36:18+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Tenant Restrictions v2 can constrain access to external Microsoft Entra tenants, but authentication-plane and data-plane coverage varies by enforcement method, platform, browser, application, and resource. ## Potentially affected Organizations seeking to limit workforce access to external Microsoft Entra tenants from managed devices or networks. ## DSE recommendation Choose enforcement methods from documented coverage, inventory legitimate partner access, pilot across real clients, and verify both allowed and denied authentication and data paths. ## Article Bottom line: Tenant Restrictions v2 can apply a cloud policy that limits which external tenants and applications users may access. The enforcement mechanism matters. A proxy header, Windows configuration, and Global Secure Access do not provide identical authentication-plane, data-plane, browser, platform, or application coverage. ## Source fact: what Microsoft documents Microsoft’s [Tenant Restrictions v2 setup guide](https://learn.microsoft.com/en-us/entra/external-id/tenant-restrictions-v2) documents a policy in cross-tenant access settings and three enforcement approaches: universal tenant restrictions through Global Secure Access, authentication-plane enforcement through a corporate proxy, and Windows device enforcement. Policies can be scoped to users, groups, organizations, or external applications. The source describes important boundaries. Windows enforcement can protect specified authentication and data paths on managed Windows devices, while browser and application behavior depends on the networking stack and configuration. The page includes separate sections for Chrome, Firefox, .NET applications, Microsoft 365 resources, service principals, and preview capabilities. Microsoft also distinguishes tenant restrictions from inbound and outbound cross-tenant access settings and from ordinary B2B collaboration. ## What the source does not establish The feature does not automatically cover every operating system, browser, personal device, protocol, application, or network route. An authentication block does not necessarily prove that cached or data-plane access is impossible in every documented scenario. The source does not identify an organization’s legitimate external tenants, determine partner risk, or guarantee that a default-deny rollout will preserve support, acquisition, training, or customer workflows. ## Applicability questions - Is the objective authentication-plane control, data-plane control, or both? - Which Windows, macOS, mobile, browser, .NET, PowerShell, Office, Teams, SharePoint, Exchange, and Graph paths are actually used? - Which partner, customer, training, support, and personal Microsoft tenants are legitimately required? - Will enforcement occur on devices, proxies, Global Secure Access, or a combination, and where can traffic bypass it? - Which capabilities in the current documentation are generally available versus preview? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Write the intended allow and deny decisions before configuring technology. Assign an owner and review date to every partner-tenant and application exception. - Draw authentication and resource traffic paths for managed and unmanaged devices, remote users, alternate browsers, native clients, and automation. - Match each path to Microsoft’s documented enforcement coverage. Do not generalize a successful Windows or Edge test to another stack. - Pilot with users who exercise real collaboration and support cases. Test intended access, denied access, cached sessions, browser variations, and loss of the enforcement component. - Monitor denials and establish a time-bounded exception process before broad enforcement. ## Verification and evidence - Preserve partner policy objects, default policy, enforcement configuration, scope, and change approval. - Record a client-and-resource test matrix showing expected and observed authentication and data access. - Capture Entra sign-in evidence and relevant proxy, device, or Global Secure Access logs for allowed and blocked cases. - Retest after client, browser, network, or policy changes. ## Official references - [Set up tenant restrictions v2](https://learn.microsoft.com/en-us/entra/external-id/tenant-restrictions-v2) — Microsoft ## Primary reference - Name: Set up tenant restrictions v2 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/external-id/tenant-restrictions-v2 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Block external-tenant sign-in paths only after mapping Tenant Restrictions v2 enforcement,” DSE Security, https://update.dsesecurity.com/updates/entra-tenant-restrictions-v2-enforcement-paths/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bound an AI agent’s authority before it can act on business systems > Agentic AI combines models with tools, data, memory, and planning so it can act without continuous supervision. Limit its identity, privileges, tools, context, autonomy, and blast radius before deployment. - Canonical URL: https://update.dsesecurity.com/updates/agentic-ai-authority-oversight-security-checklist/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-28T14:22:00+00:00 - Modified: 2026-07-28T14:22:00+00:00 - Last reviewed by DSE: 2026-07-28 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Agentic AI combines models with tools, data, memory, and planning so it can act without continuous supervision. Limit its identity, privileges, tools, context, autonomy, and blast radius before deployment. ## Potentially affected AI agents that send messages, call APIs, run code, update records, access files, administer systems, trigger workflows, make recommendations, coordinate sub-agents, or act in business environments. ## DSE recommendation Start with low-risk non-sensitive tasks, give each agent a distinct least-privileged identity, use narrow temporary credentials, constrain tools and data, require human approval for high-impact actions, log activity, and rehearse containment. ## Article ## Source fact: an agent expands the action surface The joint government guidance [Careful Adoption of Agentic AI Services](https://www.ncsc.govt.nz/assets/guidance/Documents/Careful-adoption-of-agentic-AI-services_FINAL.pdf) describes agentic systems as combinations of models, tools, data, memory, identities, and orchestration that can pursue goals and take actions with less continuous human supervision. The guidance identifies risks including prompt injection, excessive permissions, unsafe tool use, poisoned or untrusted context, identity misuse, unexpected delegation, inadequate logging, and cascading effects across connected systems. The agencies recommend beginning with low-risk uses and non-sensitive data, using distinct cryptographic identities, least privilege and just-in-time credentials, constraining tools and environments, monitoring behavior, and preserving meaningful human oversight. Designers and operators—not the agent itself—must decide which actions require human approval. High-impact actions should not become autonomous merely because a model expresses confidence. ## Define an authority envelope Document the agent’s exact objective, owner, users, data classes, memory, model and service dependencies, allowed tools, target systems, read and write permissions, transaction limits, network destinations, operating times, approval points, retention, and stop conditions. Include sub-agents and tool calls; a narrow chat interface can still have broad downstream authority. Separate development, testing, and production, and use synthetic or low-sensitivity data until controls are proven. Give each production agent a unique non-human identity. Avoid shared user accounts, static credentials embedded in prompts or code, and permission inherited from a developer. Issue short-lived credentials for the specific task, bind them to approved services where possible, and remove access when the run ends. Treat instructions, retrieved documents, webpages, messages, and tool output as potentially hostile input. ## DSE recommendation: require these controls before launch - Create an inventory entry for the agent, model, owner, version, tools, credentials, data sources, vendors, approvals, dependencies, and review date. - Allowlist tool functions and parameters. Enforce limits outside the model for recipients, destinations, amounts, records changed, execution time, and data returned. - Require a human to review the proposed action and relevant evidence before external messages, payments, access changes, destructive operations, code deployment, sensitive disclosure, or other high-impact steps. - Sandbox code and file operations, restrict outbound network access, scan retrieved content, and prevent one untrusted instruction from silently changing the agent’s governing policy. - Log prompts, relevant context, identity use, tool requests and results, approvals, policy denials, configuration versions, and final actions with sensitive-data controls. - Provide an immediate way to disable the identity, revoke credentials, stop runs, isolate outputs, preserve evidence, and roll back reversible changes. Test prompt injection, confused-deputy behavior, forged approval, unavailable tools, excessive recursion, data leakage, partial failure, and emergency shutdown before production. Reassess after model, prompt, tool, permission, data, or workflow changes. Human review must be informed and practical; a rapid approval click with no visible action or evidence is not an effective control. ## Primary reference - Name: Joint Cybersecurity Guidance: Careful Adoption of Agentic AI Services - Authority: www.ncsc.govt.nz - URL: https://www.ncsc.govt.nz/assets/guidance/Documents/Careful-adoption-of-agentic-AI-services_FINAL.pdf - Source publication date: 2026-05-01 ## Citation and use Preferred citation: “Bound an AI agent’s authority before it can act on business systems,” DSE Security, https://update.dsesecurity.com/updates/agentic-ai-authority-oversight-security-checklist/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bound Arc Remote Support access to the active Microsoft support case > How should consent, duration, and revocation be controlled for Arc Remote Support? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-047-bound-arc-remote-support-access-to-the-active-microsoft-support-case/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:24+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know How should consent, duration, and revocation be controlled for Arc Remote Support? ## Potentially affected Use this review when considering remote access for an identified Microsoft support case. ## DSE recommendation Record the support-case reference, requested troubleshooting purpose, access level, and approved duration before enabling access. ## Article ## Source facts Microsoft describes Remote Support as a preview that permits a support professional to access the device for troubleshooting after a support request is submitted. Access requires consent, and the customer controls its level and duration. The documented setup is performed from the Arc-enabled Windows server’s Remote Support page. The same feature provides a Revoke access action to withdraw the access. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/manage/azure-arc/remote-support-for-windows-server). ## Applicability Use this review when considering remote access for an identified Microsoft support case. Confirm the preview’s current eligibility requirements and the actual device. Identify the case owner and person authorized to grant consent. ## DSE recommendation Record the support-case reference, requested troubleshooting purpose, access level, and approved duration before enabling access. Have the case owner confirm which device the support professional needs. Arrange an agreed observation period and name the person responsible for ending access. Keep any extension tied to a renewed case decision rather than leaving the original approval open-ended. ## Verification Inspect the displayed access settings after the approved setup and compare them with the case record. At the end of the work, use the documented revocation path and retain the resulting status. Record when access was ended and any unresolved troubleshooting work. Investigate a mismatch in device, level, or duration before approving another session. ## Official references [Microsoft Learn: How to configure remote support for Arc-enabled Windows servers (preview)](https://learn.microsoft.com/en-us/windows-server/manage/azure-arc/remote-support-for-windows-server). Source reviewed September 8, 2026. ## Primary reference - Name: How to configure remote support for Arc-enabled Windows servers (preview) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/azure-arc/remote-support-for-windows-server - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bound Arc Remote Support access to the active Microsoft support case,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-047-bound-arc-remote-support-access-to-the-active-microsoft-support-case/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bound AXFR to a complete SOA-delimited zone transfer over TCP > Use RFC 5936 — DNS Zone Transfer Protocol (AXFR) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/bound-axfr-to-a-complete-soa-delimited-zone-transfer-over-tcp/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:48+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 5936 — DNS Zone Transfer Protocol (AXFR) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 5936 — DNS Zone Transfer Protocol (AXFR) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Bound AXFR to a complete SOA-delimited zone transfer over TCP. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 5936 — DNS Zone Transfer Protocol (AXFR)](https://www.rfc-editor.org/rfc/rfc5936.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An AXFR response that transfers a zone consists of one or more DNS messages carrying the zone’s contents. The research record locates this support at Section 2.2 (AXFR Response). - The AXFR message series begins and ends with the same zone SOA; non-SOA records may otherwise arrive in any order or grouping. The research record locates this support at Section 2.2 (AXFR Response), SOA delimiters and RR ordering. - AXFR uses TCP, but a TCP connection is not necessarily dedicated to a single zone-transfer session. The research record locates this support at Section 4 (Transport). The source support ends with the statements listed above. Use them to examine authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2.2 (AXFR Response), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.2 (AXFR Response), SOA delimiters and RR ordering, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4 (Transport), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from Section 2.2 (AXFR Response); Section 2.2 (AXFR Response), SOA delimiters and RR ordering; Section 4 (Transport) through zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 5936 — DNS Zone Transfer Protocol (AXFR)](https://www.rfc-editor.org/rfc/rfc5936.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 5936 — DNS Zone Transfer Protocol (AXFR) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5936.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bound AXFR to a complete SOA-delimited zone transfer over TCP,” DSE Security, https://update.dsesecurity.com/updates/bound-axfr-to-a-complete-soa-delimited-zone-transfer-over-tcp/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bound carrier-grade NAT resources, logging, and port allocation > Use RFC 6888 — Common Requirements for Carrier-Grade NATs (CGNs) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/bound-carrier-grade-nat-resources-logging-and-port-allocation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:39+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6888 — Common Requirements for Carrier-Grade NATs (CGNs) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6888 — Common Requirements for Carrier-Grade NATs (CGNs) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Bound carrier-grade NAT resources, logging, and port allocation. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6888 — Common Requirements for Carrier-Grade NATs (CGNs)](https://www.rfc-editor.org/rfc/rfc6888.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A carrier-grade NAT must support administrator-configurable per-subscriber external-port limits and should support configurable limits on mapping and subscriber state memory. The research record locates this support at Section 3 (Requirements for CGNs), requirements 4 and 5. - Mapping logs can identify a subscriber from protocol, subscriber identifier, translated address and port, and time; destination addresses and ports should not be logged without an administrative need. The research record locates this support at Section 4 (Logging), requirement 12. - A port-allocation scheme should balance three competing goals: high port utilization, low log volume, and port numbers that attackers cannot easily guess. The research record locates this support at Section 5 (Port Allocation Scheme), requirements 13-15. Keep the evidence boundary at these traced claims. They support a review of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 3 (Requirements for CGNs), requirements 4 and 5, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4 (Logging), requirement 12, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5 (Port Allocation Scheme), requirements 13-15, which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations Section 3 (Requirements for CGNs), requirements 4 and 5; Section 4 (Logging), requirement 12; Section 5 (Port Allocation Scheme), requirements 13-15 adjacent to the sanitized artifacts used for comparison. Prefer configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 6888 — Common Requirements for Carrier-Grade NATs (CGNs)](https://www.rfc-editor.org/rfc/rfc6888.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6888 — Common Requirements for Carrier-Grade NATs (CGNs) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6888.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bound carrier-grade NAT resources, logging, and port allocation,” DSE Security, https://update.dsesecurity.com/updates/bound-carrier-grade-nat-resources-logging-and-port-allocation/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bound HTTP/2 streams with flow control and connection error handling > Use RFC 9113 — HTTP/2 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/bound-http-2-streams-with-flow-control-and-connection-error-handling/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:59+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 9113 — HTTP/2 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 9113 — HTTP/2 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Bound HTTP/2 streams with flow control and connection error handling. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 9113 — HTTP/2](https://www.rfc-editor.org/rfc/rfc9113.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - HTTP/2 maintains receiver-controlled, hop-by-hop flow-control windows for each stream and for the connection; a sender must honor both advertised limits. The research record locates this support at Sections 5.2 (Flow Control) and 5.2.1 (Flow-Control Principles). - Only DATA frames consume flow-control credit, and every received flow-controlled frame counts against the connection window even when the frame also has an error. The research record locates this support at Sections 5.2.1 (Flow-Control Principles) and 6.9 (WINDOW_UPDATE). - A stream-local failure sends RST_STREAM without ending other streams; a connection-state failure sends GOAWAY when possible and then closes the TCP connection. The research record locates this support at Sections 5.4.1 (Connection Error Handling) and 5.4.2 (Stream Error Handling). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Sections 5.2 (Flow Control) and 5.2.1 (Flow-Control Principles), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 5.2.1 (Flow-Control Principles) and 6.9 (WINDOW_UPDATE), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 5.4.1 (Connection Error Handling) and 5.4.2 (Stream Error Handling), which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for DNS, certificates, identity providers, time, content delivery, network paths, and application ownership and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Sections 5.2 (Flow Control) and 5.2.1 (Flow-Control Principles); Sections 5.2.1 (Flow-Control Principles) and 6.9 (WINDOW_UPDATE); Sections 5.4.1 (Connection Error Handling) and 5.4.2 (Stream Error Handling) to the observed environment. Useful domain evidence includes request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 9113 — HTTP/2](https://www.rfc-editor.org/rfc/rfc9113.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 9113 — HTTP/2 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9113.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bound HTTP/2 streams with flow control and connection error handling,” DSE Security, https://update.dsesecurity.com/updates/bound-http-2-streams-with-flow-control-and-connection-error-handling/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bound NXDOMAIN and NODATA caching from SOA data > Use RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/bound-nxdomain-and-nodata-caching-from-soa-data/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:47+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Bound NXDOMAIN and NODATA caching from SOA data. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE)](https://www.rfc-editor.org/rfc/rfc2308.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - NXDOMAIN means the queried name does not exist, while NODATA is a successful response showing that the existing name lacks the requested record type. The research record locates this support at Sections 2.1 (Name Error) and 2.2 (No Data). - An authoritative NXDOMAIN or NODATA response must include the zone’s SOA record in the authority section. The research record locates this support at Section 3 (Negative Answers from Authoritative Servers). - A negative cache entry uses the smaller of the SOA.MINIMUM value and the SOA record’s TTL, and is discarded when that TTL expires. The research record locates this support at Section 5 (Caching Negative Answers). The source support ends with the statements listed above. Use them to examine authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Sections 2.1 (Name Error) and 2.2 (No Data), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Negative Answers from Authoritative Servers), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5 (Caching Negative Answers), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Sections 2.1 (Name Error) and 2.2 (No Data); Section 3 (Negative Answers from Authoritative Servers); Section 5 (Caching Negative Answers) through zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE)](https://www.rfc-editor.org/rfc/rfc2308.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2308.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bound NXDOMAIN and NODATA caching from SOA data,” DSE Security, https://update.dsesecurity.com/updates/bound-nxdomain-and-nodata-caching-from-soa-data/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bound QPACK decoder blocking while compressing HTTP/3 fields > Use RFC 9204 — QPACK: Field Compression for HTTP/3 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/bound-qpack-decoder-blocking-while-compressing-http-3-fields/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:58+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 9204 — QPACK: Field Compression for HTTP/3 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 9204 — QPACK: Field Compression for HTTP/3 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Bound QPACK decoder blocking while compressing HTTP/3 fields. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 9204 — QPACK: Field Compression for HTTP/3](https://www.rfc-editor.org/rfc/rfc9204.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Static-table and literal QPACK representations cannot block, while an unacknowledged dynamic-table reference can block its request stream after cross-stream reordering. The research record locates this support at Section 2.1 (Encoder). - A field section blocks when its Required Insert Count exceeds the decoder’s Insert Count and becomes processable once the decoder has received all required insertions. The research record locates this support at Sections 2.1.2 (Blocked Streams) and 2.2.1 (Blocked Decoding). - The encoder must keep potentially blocked streams within SETTINGS_QPACK_BLOCKED_STREAMS; exceeding the decoder’s announced limit is a QPACK_DECOMPRESSION_FAILED connection error. The research record locates this support at Section 2.1.2 (Blocked Streams). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2.1 (Encoder), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 2.1.2 (Blocked Streams) and 2.2.1 (Blocked Decoding), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2.1.2 (Blocked Streams), which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include DNS, certificates, identity providers, time, content delivery, network paths, and application ownership, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from Section 2.1 (Encoder); Sections 2.1.2 (Blocked Streams) and 2.2.1 (Blocked Decoding); Section 2.1.2 (Blocked Streams) to the observed environment. Useful domain evidence includes request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 9204 — QPACK: Field Compression for HTTP/3](https://www.rfc-editor.org/rfc/rfc9204.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 9204 — QPACK: Field Compression for HTTP/3 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9204.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bound QPACK decoder blocking while compressing HTTP/3 fields,” DSE Security, https://update.dsesecurity.com/updates/bound-qpack-decoder-blocking-while-compressing-http-3-fields/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bound UDP datagrams and congestion response before adding reliability > Use RFC 8085 — UDP Usage Guidelines to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/bound-udp-datagrams-and-congestion-response-before-adding-reliability/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:40+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8085 — UDP Usage Guidelines to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8085 — UDP Usage Guidelines ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Bound UDP datagrams and congestion response before adding reliability. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8085 — UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An application using UDP should congestion-control the aggregate rate of every socket or worker sending to the same destination host. The research record locates this support at Section 3.1 (Congestion Control Guidelines). - A UDP application should avoid datagrams that exceed the path MTU by using supplied path-MTU information or performing PMTUD or PLPMTUD, with IP and UDP headers deducted from the payload size. The research record locates this support at Section 3.2 (Message Size Guidelines). - An application that retransmits over UDP is responsible for congestion-controlling original and retransmitted traffic; reliable ordered delivery should use a standard transport when possible. The research record locates this support at Section 3.3 (Reliability Guidelines). Keep the evidence boundary at these traced claims. They support a review of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 3.1 (Congestion Control Guidelines), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3.2 (Message Size Guidelines), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 3.3 (Reliability Guidelines), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations Section 3.1 (Congestion Control Guidelines); Section 3.2 (Message Size Guidelines); Section 3.3 (Reliability Guidelines) adjacent to the sanitized artifacts used for comparison. Prefer configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 8085 — UDP Usage Guidelines](https://www.rfc-editor.org/rfc/rfc8085.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8085 — UDP Usage Guidelines - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8085.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bound UDP datagrams and congestion response before adding reliability,” DSE Security, https://update.dsesecurity.com/updates/bound-udp-datagrams-and-congestion-response-before-adding-reliability/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Bracket route refresh updates so peers can reconcile stale state > Use RFC 7313 — Enhanced Route Refresh Capability for BGP-4 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/bracket-route-refresh-updates-so-peers-can-reconcile-stale-state/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:38+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 7313 — Enhanced Route Refresh Capability for BGP-4 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 7313 — Enhanced Route Refresh Capability for BGP-4 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Bracket route refresh updates so peers can reconcile stale state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 7313 — Enhanced Route Refresh Capability for BGP-4](https://www.rfc-editor.org/rfc/rfc7313.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Enhanced route-refresh procedures apply to a peer only after that peer has advertised the Enhanced Route Refresh Capability. The research record locates this support at Section 4 (Operation), capability precondition. - The refreshing speaker must send Begin-of-RIB-Refresh before re-advertisement and End-of-RIB-Refresh after completing the entire affected Adj-RIB-Out. The research record locates this support at Section 4 (Operation), sender procedure. - On Begin-of-RIB-Refresh, the receiver marks that peer’s AFI/SAFI routes stale; refreshed routes replace them, and End-of-RIB-Refresh removes any that remain stale. The research record locates this support at Section 4 (Operation), receiver procedure. Keep the evidence boundary at these traced claims. They support a review of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 4 (Operation), capability precondition, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4 (Operation), sender procedure, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4 (Operation), receiver procedure, which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations Section 4 (Operation), capability precondition; Section 4 (Operation), sender procedure; Section 4 (Operation), receiver procedure adjacent to the sanitized artifacts used for comparison. Prefer configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 7313 — Enhanced Route Refresh Capability for BGP-4](https://www.rfc-editor.org/rfc/rfc7313.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 7313 — Enhanced Route Refresh Capability for BGP-4 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc7313.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Bracket route refresh updates so peers can reconcile stale state,” DSE Security, https://update.dsesecurity.com/updates/bracket-route-refresh-updates-so-peers-can-reconcile-stale-state/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Budget raw capacity for two-way and three-way mirrors > How much raw capacity does a mirrored data-capacity target require? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-043-budget-raw-capacity-for-two-way-and-three-way-mirrors/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:28+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know How much raw capacity does a mirrored data-capacity target require? ## Potentially affected Use this review when comparing mirror layouts for a supported cluster. ## DSE recommendation Write a capacity worksheet that identifies the copy count, server count, and intended data volume. ## Article ## Source facts Storage Spaces Direct mirroring places complete copies on different physical hardware. Two-way mirroring writes two copies and has 50 percent storage efficiency; Microsoft’s example needs at least 2 TB of physical capacity for 1 TB of data and two server fault domains. Three-way mirroring writes three copies, giving 33.3 percent efficiency and requiring at least three server fault domains. Microsoft recommends three-way mirroring when the cluster has more than two servers. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/fault-tolerance). ## Applicability Use this review when comparing mirror layouts for a supported cluster. Distinguish raw drive capacity from the usable data target. Review the source’s failure-tolerance discussion and the complete design requirements before selecting a resiliency option. ## DSE recommendation Write a capacity worksheet that identifies the copy count, server count, and intended data volume. Ask the storage owner to review growth, maintenance, and recovery headroom separately from the basic copy calculation. Show the business owner both raw and usable quantities in the proposal. Keep performance and failure requirements alongside cost so the layout is not chosen from capacity efficiency alone. ## Verification Compare the implemented resiliency and reported capacity with the worksheet. Record the actual server and drive inventory, and investigate any unexplained difference in available space. Validate the workload through the approved storage acceptance process. Revisit the calculation when the data target or fault-domain design changes. ## Official references [Microsoft Learn: Fault tolerance and storage efficiency on Azure Local and Windows Server clusters](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/fault-tolerance). Source reviewed September 8, 2026. ## Primary reference - Name: Fault tolerance and storage efficiency on Azure Local and Windows Server clusters - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/fault-tolerance - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Budget raw capacity for two-way and three-way mirrors,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-043-budget-raw-capacity-for-two-way-and-three-way-mirrors/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Budget the physical footprint before expanding an S2D volume > How much storage-pool capacity does a planned volume expansion actually require? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-149-budget-the-physical-footprint-before-expanding-an-s2d-volume/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:42+00:00 - Modified: 2026-09-08T18:23:28+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How much storage-pool capacity does a planned volume expansion actually require? ## Potentially affected Administrators expanding volumes on Storage Spaces Direct clusters. ## DSE recommendation Write the logical-size request and physical-capacity calculation separately. ## Article ## Source facts Microsoft requires sufficient pool capacity for the expanded volume’s physical footprint. Its three-way-mirror example doubles a 1 TB logical volume to 2 TB, increasing the physical footprint from 3 TB to 6 TB. An S2D volume consists of multiple stacked objects, including its partition, virtual disk, and applicable storage tiers. Resizing requires updating several of those objects. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/manage-volumes). ## Applicability Identify the volume, resiliency, tiers, current footprint, free pool capacity, and desired logical size. Review the documented procedure and any media-specific capacity requirements before changing the volume. ## DSE recommendation Write the logical-size request and physical-capacity calculation separately. Have the storage owner check the available pool space and approve the workload maintenance plan. Preserve the original object sizes and confirm that additional capacity, if needed, will be added through a supported method. ## Verification After the approved expansion, compare the sizes of the relevant objects and the filesystem’s usable capacity with the plan. Test representative workload access and review remaining pool capacity. Record a partially expanded stack or unexplained footprint as a failure to resolve before another storage change. ## Official references [Microsoft Learn: Manage volumes in Azure Local and Windows Server](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/manage-volumes). Source reviewed September 8, 2026. ## Primary reference - Name: Manage volumes in Azure Local and Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/manage-volumes - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Budget the physical footprint before expanding an S2D volume,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-149-budget-the-physical-footprint-before-expanding-an-s2d-volume/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a cruise-terminal screening program around documented procedures and prohibited items > Use 33 CFR 105.505 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/build-a-cruise-terminal-screening-program-around-documented-procedures-and-prohibited-items/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:51+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.505 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.505 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Build a cruise-terminal screening program around documented procedures and prohibited items. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.505 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.505) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that the TSP document all procedures that are employed to ensure all persons, baggage, and personal effects are screened at the cruise ship terminal prior to being allowed into a cruise ship terminal’s secure areas or onto a cruise ship. The research record locates this support at 33 CFR 105.505(a)(1), read with 33 CFR 105.505(a) (eCFR anchor p-105.505(a)(1)). - Under 33 CFR 105, the rule requires that the TSP include the procedures used when prohibited items are detected. The research record locates this support at 33 CFR 105.505(c)(10), read with 33 CFR 105.505(c) (eCFR anchor p-105.505(c)(10)). Only the traced statements above are asserted as source facts. Apply the review to credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces after confirming that the source and deployed context match. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.505(a)(1), read with 33 CFR 105.505(a) (eCFR anchor p-105.505(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.505(c)(10), read with 33 CFR 105.505(c) (eCFR anchor p-105.505(c)(10)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to 33 CFR 105.505(a)(1), read with 33 CFR 105.505(a) (eCFR anchor p-105.505(a)(1)); 33 CFR 105.505(c)(10), read with 33 CFR 105.505(c) (eCFR anchor p-105.505(c)(10)) and to observable material such as approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [33 CFR 105.505 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.505) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.505 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.505 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build a cruise-terminal screening program around documented procedures and prohibited items,” DSE Security, https://update.dsesecurity.com/updates/build-a-cruise-terminal-screening-program-around-documented-procedures-and-prohibited-items/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a custom Hyper-V Quick Create gallery from a source manifest > How does a custom VM image become a selectable Quick Create gallery entry? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-213-build-a-custom-hyper-v-quick-create-gallery-from-a-source-manifest/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:38+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know How does a custom VM image become a selectable Quick Create gallery entry? ## Potentially affected Teams curating a custom Hyper-V Quick Create virtual-machine gallery. ## DSE recommendation Prepare a small gallery with a clearly identified image and descriptive metadata. ## Article ## Source facts The VM gallery uses sources defined in the Windows registry; each source points to a local or remote JSON file listing virtual machines. The gallery combines the entries from its configured sources each time it opens. Microsoft documents testing the intended image through the local installation-source option before placing it in a gallery. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/custom-vm-gallery). ## Applicability Identify who owns the image, the gallery JSON, and the configured source location. Keep image qualification separate from presentation in the gallery. A visible name and description do not demonstrate that the underlying operating system or application image meets organizational requirements. ## DSE recommendation Prepare a small gallery with a clearly identified image and descriptive metadata. Have the image owner approve the source files and the intended audience before distributing the gallery location. Test that image through the documented local-source route first. Preserve the previous manifest and give each image revision an unambiguous identity so operators can distinguish a changed image from a changed description. ## Verification Open the gallery from a representative client and verify that the intended entry appears from the expected source. Create an isolated test machine and compare the resulting operating system and image identity with the approved release. Check that an obsolete gallery entry is no longer offered when its manifest is deliberately withdrawn. ## Official references [Microsoft Learn: Create a custom virtual machine gallery](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/custom-vm-gallery). Source reviewed September 8, 2026. ## Primary reference - Name: Create a custom virtual machine gallery - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/custom-vm-gallery - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build a custom Hyper-V Quick Create gallery from a source manifest,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-213-build-a-custom-hyper-v-quick-create-gallery-from-a-source-manifest/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a cybersecurity learning program that changes behavior > Annual completion is not the same as readiness. A managed learning program uses role-specific objectives, practical exercises, several measures, leadership support, and continuous improvement to change security and privacy behavior. - Canonical URL: https://update.dsesecurity.com/updates/cybersecurity-privacy-learning-program-lifecycle/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-28T14:22:00+00:00 - Modified: 2026-07-28T14:22:00+00:00 - Last reviewed by DSE: 2026-07-28 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 2 minutes ## What you need to know Annual completion is not the same as readiness. A managed learning program uses role-specific objectives, practical exercises, several measures, leadership support, and continuous improvement to change security and privacy behavior. ## Potentially affected Employees, contractors, executives, finance, human resources, IT administrators, developers, physical-security staff, incident responders, privacy personnel, and other roles with specialized responsibilities. ## DSE recommendation Assign a sponsor and program owner, analyze real risk and audiences, define observable outcomes, combine awareness with role-based practice, measure behavior and exercise performance, and improve the program continuously. ## Article ## Source fact: completion is only one program measure NIST SP 800-50 Rev. 1 describes a cybersecurity and privacy learning program as a lifecycle with four phases: plan and strategy; analysis and design; development and implementation; and assessment and improvement. It replaces an event-centered view of annual awareness with a managed program tied to organizational mission, risks, roles, culture, and measurable outcomes. The publication is directed to federal organizations but explicitly offers a voluntary approach that other organizations can adapt. The [NIST learning-program guidance](https://csrc.nist.gov/pubs/sp/800/50/r1/final) distinguishes broad awareness, role-based training, and education. It emphasizes leadership support, stakeholder involvement, communication, accessibility, evaluation, and continual improvement. A course-completion percentage can show delivery, but it does not establish that people recognize a threat, follow a procedure, or make a safer decision under pressure. ## Design around roles and real decisions Identify audiences by what they can affect. Everyone may need to report suspicious messages and protect credentials, while finance verifies payment changes, managers approve access, administrators protect privileged systems, developers handle secrets, facilities staff preserve physical evidence, and executives make crisis decisions. Contractors, temporary staff, vendors, and users requiring accessible or multilingual material need deliberate coverage. Use incidents, audit findings, help-desk data, threat intelligence, business changes, and regulatory duties to define observable objectives. “Understand phishing” is vague; “report a simulated credential request through the approved channel without entering a password” can be practiced and measured. Select delivery methods that match the decision: short reminders for awareness, guided exercises for procedures, labs for technical skills, and tabletop scenarios for coordination. ## DSE recommendation: operate a measured lifecycle - Name an executive sponsor and accountable program owner. Define scope, resources, required stakeholders, risk priorities, and the decisions the program is intended to improve. - Build a role-to-objective matrix covering new hires, role changes, recurring learning, incidents, long absences, and departure. Assign content owners and review dates. - Develop practical activities with current procedures, realistic tools, safe environments, accessibility checks, and a clear reporting or escalation path. - Pilot with representative users. Correct confusing instructions, inaccessible content, broken reporting routes, and scenarios that reward guessing rather than the intended behavior. - Combine delivery measures with outcome measures: completion and lateness; scenario choices; reporting quality and speed; exercise performance; recurring control failures; and help-desk trends. - Review results with business, security, privacy, HR, legal, and accessibility stakeholders. Record changes, owners, due dates, and evidence that the revised activity worked. Avoid punitive metrics that discourage reporting or turn simulation results into a ranking without context. Segment results by role and scenario, protect personnel data, and look for process failures as well as individual mistakes. If employees repeatedly choose an unsafe workaround, improve the workflow and the learning together. ## Primary reference - Name: NIST SP 800-50 Rev. 1: Cybersecurity and Privacy Learning Program - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/50/r1/final - Source publication date: 2024-09-12 ## Citation and use Preferred citation: “Build a cybersecurity learning program that changes behavior,” DSE Security, https://update.dsesecurity.com/updates/cybersecurity-privacy-learning-program-lifecycle/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a data register that reduces breach impact and protection burden > A useful data register follows information through collection, storage, sharing, backup, export, retention, and deletion so the organization can protect what it needs and stop retaining what it does not. - Canonical URL: https://update.dsesecurity.com/updates/data-register-inventory-minimization-retention/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-28T14:22:00+00:00 - Modified: 2026-07-28T14:22:00+00:00 - Last reviewed by DSE: 2026-07-28 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know A useful data register follows information through collection, storage, sharing, backup, export, retention, and deletion so the organization can protect what it needs and stop retaining what it does not. ## Potentially affected Customer, employee, financial, authentication, video, access-control, contractual, operational, and regulated data in applications, SaaS platforms, endpoints, paper files, backups, exports, and vendor systems. ## DSE recommendation Inventory data by type and flow, assign business and system owners, document purpose and access, minimize unnecessary copies, reconcile retention obligations, verify deletion, and review the register during changes and incidents. ## Article ## Source fact: unnecessary data creates unnecessary exposure The Federal Trade Commission advises businesses to know what personal information they hold, retain only what they need for legitimate business purposes, protect it, dispose of it securely, and plan for incidents. Its [Protecting Personal Information guide](https://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-business) recommends inventorying computers, mobile devices, file cabinets, employee homes, service providers, and other locations, and tracing how information enters, moves through, and leaves the organization. This does not establish one retention period for every record. Tax, employment, safety, financial, surveillance, contract, litigation, and sector obligations can differ. Legal holds may suspend normal deletion. The useful control is a documented decision that reconciles business need and applicable obligations, not a universal number copied across every system. ## Register data as a flow, not only an application Create entries around meaningful data types and business processes. Record the purpose, data subjects, fields, sensitivity, source, collection method, system of record, owner, custodian, users and service accounts, physical and geographic locations, vendors, transfers, exports, backups, retention rule, legal or contractual basis, deletion method, and incident contact. Include spreadsheets, email attachments, reports, local downloads, paper, test data, integration logs, and departed vendors; these copies often fall outside a central application inventory. Link the register to the asset, identity, vendor, backup, and records-management inventories instead of reproducing all of them. A register should answer which systems and parties are affected when a data type changes, a vendor ends, a person requests action, or an incident occurs. Assign a business owner who can justify collection and retention and a technical owner who can prove storage, access, protection, and deletion behavior. ## DSE recommendation: turn the register into decisions - Begin with high-impact processes such as payroll, customer onboarding, payment, physical access, video, identity administration, support, and incident evidence. - Interview the people who perform the work and observe a representative transaction. Compare the described flow with configuration, integrations, exports, shared locations, and vendor documentation. - Challenge each field and copy: identify the purpose, minimum necessary population, access, retention trigger, and consequence of not collecting it. - Replace indefinite retention with an approved rule that states the trigger, period or decision criterion, exceptions, hold process, owner, and deletion evidence. - Test deletion in primary systems, replicas, search indexes, endpoints, vendor platforms, and backups according to documented product behavior. Record what is deleted, anonymized, expired, or retained. - Review entries during procurement, system change, new integration, migration, contract termination, regulatory change, and incident postmortem. Measure ownerless entries, overdue reviews, unjustified fields, uncontrolled exports, retention exceptions, deletion failures, and vendor gaps. Restrict the register itself because detailed locations, access paths, and weaknesses can assist an attacker. During an incident, use it to define scope and investigation priorities, but validate current evidence rather than assuming the register is perfectly complete. ## Primary reference - Name: FTC: Protecting Personal Information, A Guide for Business - Authority: Federal Trade Commission - URL: https://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-business - Source publication date: 2026-07-28 ## Citation and use Preferred citation: “Build a data register that reduces breach impact and protection burden,” DSE Security, https://update.dsesecurity.com/updates/data-register-inventory-minimization-retention/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a defensible Microsoft Purview retention and legal-hold decision tree > Retention policies, retention labels, records controls, and eDiscovery holds answer different questions. Route each requirement through legal, records, privacy, workload, license, scope, deployment, validation, exception, and release decisions. - Canonical URL: https://update.dsesecurity.com/updates/build-defensible-purview-retention-legal-hold-decision-tree/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:01:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Retention policies, retention labels, records controls, and eDiscovery holds answer different questions. Route each requirement through legal, records, privacy, workload, license, scope, deployment, validation, exception, and release decisions. ## Potentially affected Microsoft Purview Data Lifecycle Management, Records Management and eDiscovery; Exchange, SharePoint, OneDrive, Teams and other supported workloads; retention policies and labels; adaptive or static scopes; legal holds; custodians; locations; licensing; disposition; and audit evidence. ## DSE recommendation Translate each approved requirement into purpose, authority, content, event, duration, disposition, scope and owner; choose the supported Purview control; test on representative content; verify deployment and per-location status; govern exceptions and conflicts; and require authorized release. ## Article ## Source facts: retention and eDiscovery holds serve different purposes Microsoft’s [retention-policy documentation](https://learn.microsoft.com/en-us/purview/create-retention-policies) describes policies that retain content, delete it, or retain and then delete it. Policies can apply at a container level so content in supported locations inherits the settings. Microsoft directs organizations toward retention labels and file-plan capabilities when item-level or higher-value business, legal, or regulatory record keeping is needed. Microsoft’s [eDiscovery hold guidance](https://learn.microsoft.com/en-us/purview/edisc-hold-create) describes preserving content relevant to a case and distinguishes a case hold from long-term lifecycle retention. It notes that a hold can take time to take effect and documents workload-specific locations and considerations. Microsoft’s related hold-management guidance warns that identity or location changes can require the policy to be updated and reapplied. Microsoft documentation is product guidance, not legal advice. Applicable law, court orders, regulatory rules, contracts, records schedules, privacy obligations, and litigation strategy determine what must be preserved or deleted. Features, supported locations, indexing, processing time, limits, and licensing vary. Qualified legal, records, privacy, and Microsoft 365 administrators must approve the design. ## DSE recommendation: use one decision record before choosing a control For every proposed rule, capture the authority and exact business statement before opening Purview. Identify the content class, creator or custodian, event that starts the clock, duration, required disposition, geographic or business scope, exceptions, legal owner, records owner, technical owner, and evidence needed. “Keep Teams for seven years” is not sufficiently precise. - Choose the purpose branch. Use lifecycle controls for approved ongoing retention and deletion. Use record controls when content needs item-level classification, event-based retention, disposition, or record restrictions. Use an eDiscovery hold for scoped case preservation under authorized legal process. Do not use a permanent hold as a substitute for records design. - Map the actual workload. Trace where the content lives, including group mailboxes, SharePoint sites, OneDrive, meeting artifacts, chats, channel messages, private or shared channels, attachments, versions, and connected applications. A user-facing product name can hide multiple storage locations. - Resolve conflicts and priority. Model overlapping retention, deletion, labels, records, and holds using current Microsoft retention principles. Ask legal and records owners to decide the intended result. Do not simplify a conflict by removing a hold or shortening retention without authority. - Confirm support and license. Verify the tenant, workload, policy type, scope, label behavior, limits, and required licenses for every affected user or feature. Record assumptions that depend on Microsoft service behavior and set a review trigger for product change. - Pilot representative content. Use controlled test locations and items to validate publication, application, event trigger, preservation after edit or deletion, searchability where relevant, disposition, user experience, and audit. Respect documented processing time; do not infer failure or success too early. - Verify deployment continuously. Check policy and per-location status, errors, renamed or moved sites and mailboxes, departed custodians, scope changes, and new collaboration locations. For case holds, follow the legal process to update or retry after identity and location changes. Require separation of duties for creation, approval, modification, and release where risk warrants it. Maintain a register connecting each Purview object to its requirement, scope, owner, approval, test evidence, exceptions, and next review. Alert or review unauthorized policy, label, case, hold, scope, and role changes. Release is a governed decision, not cleanup. Confirm legal authorization, overlapping requirements, disposition effect, processing status, and evidence before removing a hold or policy. A defensible program can explain why the control exists, what it covers, how it was tested, who monitors it, and who may end it. Reject any configuration request that lacks an approved authority, content definition, start event, duration, disposition, scope, and owner. Pause deployment when the test cannot locate expected content, protected content can be removed contrary to the approved outcome, or policy status remains unresolved. Technical administrators should surface those failures to counsel and records owners rather than reinterpret the requirement themselves. ## Official references - Microsoft, [Automatically retain or delete content by using retention policies](https://learn.microsoft.com/en-us/purview/create-retention-policies). - Microsoft, [Create holds in eDiscovery](https://learn.microsoft.com/en-us/purview/edisc-hold-create). ## Primary reference - Name: Microsoft Learn: Create and configure retention policies - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/purview/create-retention-policies - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build a defensible Microsoft Purview retention and legal-hold decision tree,” DSE Security, https://update.dsesecurity.com/updates/build-defensible-purview-retention-legal-hold-decision-tree/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a firewall rule lifecycle that survives staff and system changes > Firewall rules stay trustworthy when requests, approvals, tests, owners, expiration conditions, reviews, and removals are part of one documented lifecycle. - Canonical URL: https://update.dsesecurity.com/updates/firewall-rule-lifecycle/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:04:22+00:00 - Modified: 2026-07-19T19:04:22+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Firewall rules stay trustworthy when requests, approvals, tests, owners, expiration conditions, reviews, and removals are part of one documented lifecycle. ## Potentially affected Organizations managing network, host, cloud, or security-appliance firewall policies across production, remote-access, and management environments. ## DSE recommendation Require a documented owner and business purpose for each material rule, review rules against current dependencies, and retire obsolete access through controlled change. ## Article ## A rule is a business decision expressed in technology NIST SP 800-41 Rev. 1 discusses establishing firewall policy and selecting, configuring, testing, deploying, and managing firewall solutions. Its strongest operational lesson is that a firewall is not finished when traffic first passes. Rules persist while applications, addresses, vendors, administrators, and risk change. Without ownership and review, a narrow exception can become unexplained permanent access. Age-of-source note: NIST published this revision in September 2009. Product architectures have evolved substantially. Use the publication for durable policy and management concepts, then use current platform documentation and your present security architecture for implementation details. ## Define the request before editing policy A rule request should identify the service owner, business purpose, source, destination, protocol or service, direction, expected users or systems, required logging, implementation window, and conditions for removal. Record dependencies such as identity services, address translation, remote-access gateways, cloud controls, or vendor connections. Temporary access needs an explicit expiration or review date. Prefer the narrowest supported access that satisfies the documented workflow. Broad labels such as “application traffic” are not enough to explain a rule later. When a request cannot be made specific, treat that uncertainty as a design question rather than silently creating a wider rule. ## Approve, test, and release as a change - Confirm that the requester and approver have authority for the affected service. - Check for an existing rule or supported architecture that already meets the need. - Review rule order, overlapping objects, routing, and related controls before deployment. - Back up or export the current policy using the platform’s supported method. - Define a harmless functional test, a monitoring check, and rollback criteria. - Implement during an appropriate window and record the actual result. A successful connection is only one signal. Validation should also confirm that unrelated access was not introduced, expected logging is present, and the dependent business workflow remains healthy. ## Review without deleting blindly Periodic review should look for rules with missing owners, expired purposes, overly broad objects, duplicates, shadowed entries, obsolete vendors, unsupported systems, or no clear dependency. Hit counts can help investigation, but an unused counter alone does not prove a rule is safe to remove; seasonal, recovery, or rarely used administrative workflows may be legitimate. For each questioned rule, contact the owner, trace the dependency, inspect relevant evidence, and plan a controlled disable or removal with monitoring and recovery. Re-certification should mean that an accountable owner has confirmed the current purpose—not that the original ticket still exists. ## Close the lifecycle Application retirement, vendor offboarding, site closure, address redesign, and replacement of a remote-access method should all trigger rule review. Remove associated objects and exceptions through change control, update diagrams and inventories, and preserve the audit record. A clean firewall policy is easier to test, explain, and recover than a collection of exceptions whose original context has disappeared. ## Primary reference - Name: NIST SP 800-41 Rev. 1 — Guidelines on Firewalls and Firewall Policy - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/41/r1/final - Source publication date: 2009-09-28 ## Citation and use Preferred citation: “Build a firewall rule lifecycle that survives staff and system changes,” DSE Security, https://update.dsesecurity.com/updates/firewall-rule-lifecycle/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a Hyper-V capacity envelope from the correct limits > Which published maximum applies to a planned Hyper-V workload? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-247-build-a-hyper-v-capacity-envelope-from-the-correct-limits/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:04+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know Which published maximum applies to a planned Hyper-V workload? ## Potentially affected Capacity planners reviewing Hyper-V virtual-machine, host, and cluster limits. ## DSE recommendation Create a capacity worksheet with one row for each required resource and separate columns for workload demand, guest limit, VM limit, host limit, and available capacity. ## Article ## Source facts Microsoft publishes separate Hyper-V maximums for virtual machines and hosts. It also publishes maximums for failover clusters containing Hyper-V hosts. VM maximums depend on the host Windows Server version, and some components also depend on the VM generation. A guest operating system can support less than the Hyper-V maximum, so its vendor limits must also be checked. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/maximum-scale-limits). ## Applicability Identify the host version, guest operating system, VM generation, and clustered or standalone placement before reading a number from a limit table. Treat a product maximum as a boundary to review, not a workload sizing target or performance commitment. ## DSE recommendation Create a capacity worksheet with one row for each required resource and separate columns for workload demand, guest limit, VM limit, host limit, and available capacity. Link each product boundary to its applicable source section and version. Have the workload owner supply measured demand and the infrastructure owner account for maintenance or host-loss scenarios before approving a placement. ## Verification Compare the proposed VM configuration with every applicable boundary, resolving any value whose version or generation is unclear. Then run a representative workload test at the proposed allocation and record actual consumption. Keep the measured operating envelope distinct from the published ceiling when documenting the capacity decision. ## Official references [Microsoft Learn: Hyper-V Maximum Scale Limits in Windows Server](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/maximum-scale-limits). Source reviewed September 8, 2026. ## Primary reference - Name: Hyper-V Maximum Scale Limits in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/maximum-scale-limits - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build a Hyper-V capacity envelope from the correct limits,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-247-build-a-hyper-v-capacity-envelope-from-the-correct-limits/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a practical baseline with CISA Cybersecurity Performance Goals > Use CISA’s voluntary Cross-Sector Cybersecurity Performance Goals to identify a manageable set of high-impact improvements, assign owners, capture evidence, and avoid confusing a baseline assessment with compliance or certification. - Canonical URL: https://update.dsesecurity.com/updates/cisa-cpg-practical-cybersecurity-baseline/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:09+00:00 - Modified: 2026-07-19T19:03:09+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity - Reading time: 2 minutes ## What you need to know Use CISA’s voluntary Cross-Sector Cybersecurity Performance Goals to identify a manageable set of high-impact improvements, assign owners, capture evidence, and avoid confusing a baseline assessment with compliance or certification. ## Potentially affected Small and midsize organizations, critical-infrastructure operators, business leaders, and IT teams prioritizing limited security resources. ## DSE recommendation Review the current CISA goals, mark each item implemented, partial, not implemented, or not applicable, and assign the next evidence-backed action. ## Article A long security-control catalog can overwhelm a team that needs to decide what to do next. CISA’s Cross-Sector Cybersecurity Performance Goals, commonly called the CPGs, are designed to focus attention on a limited set of practices with meaningful risk-reduction value. ## What the official source says Source fact: CISA describes the Cross-Sector CPGs as voluntary baseline practices that are broadly applicable across critical infrastructure. CISA says they were selected to help organizations, particularly small and midsize organizations, prioritize investments in essential actions with high-impact security outcomes. The goals include information-technology and operational-technology considerations and are aligned to Cybersecurity Framework functions. The CPGs are not a promise that an organization will avoid an incident. CISA’s published FAQ also explains that implementing a goal does not necessarily fulfill an entire referenced NIST Cybersecurity Framework subcategory, and CISA does not operate an official CPG assessor-certification program. ## A useful assessment method DSE recommendation: work from the current CISA page and downloadable materials rather than a copied checklist that may become stale. For every goal, record five things: - Status: implemented, partially implemented, not implemented, or not applicable. - Owner: the person accountable for the decision and the team operating the practice. - Evidence: a configuration export, policy, ticket, report, test record, diagram, or other reproducible proof. - Gap: what remains incomplete, including technology, process, people, or supplier dependencies. - Next review: when someone will verify that the practice still operates as intended. ## Prioritize instead of chasing a score Start with goals connected to the organization’s most consequential services and likely attack paths. A partially deployed safeguard protecting every critical account may deserve attention before a fully deployed safeguard on a low-impact system. Consider safety, operational disruption, sensitive data, financial loss, contractual commitments, and recovery difficulty. DSE recommendation: convert the review into a short backlog. Each item should identify the business risk, accountable owner, safe implementation sequence, dependencies, success evidence, and rollback or escalation condition. Test changes with a representative group before broad production deployment. ## Important limits The CPGs are a baseline, not a complete security program, legal opinion, audit, certification, or substitute for sector-specific requirements. “Not applicable” should include a written reason. “Implemented” should mean the control is configured, operating, and periodically verified—not simply licensed or purchased. Practical next step: select five current CPG items related to your most critical business service. Confirm evidence for each one, assign one improvement owner, and schedule a follow-up review before expanding the assessment. ## Primary reference - Name: CISA Cross-Sector Cybersecurity Performance Goals - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/cybersecurity-performance-goals - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build a practical baseline with CISA Cybersecurity Performance Goals,” DSE Security, https://update.dsesecurity.com/updates/cisa-cpg-practical-cybersecurity-baseline/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a release matrix for every electrically locked egress door > “Fail safe” and “fail secure” do not describe the whole opening. Document and test how each electrically locked door behaves for normal egress, request to exit, power loss, fire/life-safety inputs, emergency actions, faults, and restoration. - Canonical URL: https://update.dsesecurity.com/updates/electrically-locked-egress-door-release-matrix/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:35:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Access Control, Business Continuity - Reading time: 3 minutes ## What you need to know “Fail safe” and “fail secure” do not describe the whole opening. Document and test how each electrically locked door behaves for normal egress, request to exit, power loss, fire/life-safety inputs, emergency actions, faults, and restoration. ## Potentially affected Access-controlled doors, electromagnetic locks, electric strikes and locks, request-to-exit devices, delayed or controlled egress arrangements, fire-alarm interfaces, power supplies, emergency release controls, and door monitoring. ## DSE recommendation Have the design team and applicable authority confirm each opening, then commission a door-by-door release matrix with witnessed results for every relevant input, loss, fault, emergency state, and return to normal. ## Article ## Source facts: the locking application determines the evidence UL Solutions’ [guidance on controlled and delayed egress locking devices](https://www.ul.com/news/proper-application-ul-standards-controlled-or-delayed-egress-locking-devices-ul-294-1034) explains that lock hardware is one part of an access or egress control system. The article describes model-code considerations that can include integration with fire detection or suppression, behavior on loss of power, fail-safe or fail-secure functions, emergency planning and drills, delayed-release limitations, signage, and resistance to unauthorized entry. The source also distinguishes certification categories. Depending on the application, an opening may contain components evaluated under UL 294 for access control or special locking arrangements, UL 1034 for burglary-resistant electric locking mechanisms, UL 305 for panic hardware, UL 10C for fire-door assemblies, or other categories. A mark on one device does not establish that every component, interconnection, installation detail, and operating state of the finished opening is correct. Adopted codes, occupancy, door function, listed equipment instructions, approved plans, and decisions of the authority having jurisdiction determine what is permitted for a particular opening. This article is operational guidance, not a code interpretation or legal conclusion. Do not copy another site’s release logic or assume every electrically locked door should react identically. ## DSE recommendation: commission from an approved state matrix Create one record per opening before programming. Identify the door, room and egress direction; occupancy and approved locking arrangement as provided by the design professional; lock and latch type; door and frame rating where applicable; reader; request-to-exit devices; position and latch monitoring; power supply; fire/life-safety interface; emergency release; controller; network dependencies; and approved restoration method. Across the top of the matrix, list every relevant input or condition. Down the side, state the expected lock, latch, alarm, monitoring, annunciation, and access-control event behavior. At minimum, consider: - normal authorized entry, denied entry, and ordinary mechanical egress; - request-to-exit sensing or hardware, door-held and door-forced conditions; - loss and restoration of branch power, lock power, controller power, and communications; - approved fire-alarm, suppression, emergency-control, or building-system inputs; - manual emergency release and any approved delayed or controlled-egress sequence; - controller restart, schedule change, lockdown or other authorized security mode; and - faulted contacts, broken conductors, stuck relays, and other supervised conditions supported by the design. Coordinate testing with the owner, monitoring parties, fire/life-safety provider, design professional, and authority when required. Place affected systems in the approved test state, protect occupants, prevent an unintended dispatch, and never defeat an egress or safety function merely to complete a convenient test. - Inspect before energizing. Match product identifiers, certification information, approved drawings, wiring, power, door hardware, labels, signage, and manufacturer instructions. - Test the physical opening. Verify alignment, latching, closing, egress-side operation, door swing, and required clearances under normal conditions before attributing a mechanical problem to software. - Trigger one condition at a time. Observe the actual lock and latch, the person’s ability to use the approved egress method, local indications, access events, fire/life-safety status, and remote monitoring. - Test combined and restoration states. Exercise the approved sequence when two material conditions overlap, then prove that restoration does not relock, suppress an alarm, or clear an event prematurely. - Record discrepancies by opening. Capture expected versus actual behavior, time, witness, evidence, corrective owner, retest, and approval. A global “doors tested” checkbox is not adequate. Keep the approved matrix with the as-built record and controlled operating instructions. Revalidate after lock, power-supply, controller, reader, request-to-exit, fire-interface, schedule, firmware, or door-hardware changes. Also test after unexplained unlocks, failed releases, door work, or emergency-plan changes. The objective is a door that preserves the approved balance of entry control, egress, fire/life-safety operation, and auditable restoration in every state the site depends on. ## Official references - UL Solutions, [Proper Application of UL Standards for Controlled or Delayed Egress Locking Devices—UL 294 & 1034](https://www.ul.com/news/proper-application-ul-standards-controlled-or-delayed-egress-locking-devices-ul-294-1034), March 5, 2021. - NFPA, [free online access to NFPA 101, Life Safety Code](https://link.nfpa.org/all-publications/101); use the adopted edition and project-specific approval. ## Primary reference - Name: UL Solutions: Proper Application of UL Standards for Controlled or Delayed Egress Locking Devices—UL 294 & 1034 - Authority: UL Solutions - URL: https://www.ul.com/news/proper-application-ul-standards-controlled-or-delayed-egress-locking-devices-ul-294-1034 - Source publication date: 2021-03-05 ## Citation and use Preferred citation: “Build a release matrix for every electrically locked egress door,” DSE Security, https://update.dsesecurity.com/updates/electrically-locked-egress-door-release-matrix/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a repeatable Microsoft Purview audit-search procedure before an incident > Microsoft Purview Audit can investigate activity across Microsoft 365, but reliable evidence depends on verified ingestion, licensing-based retention, precise UTC queries, least-privileged access, and preserved exports. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-purview-audit-search-incident-readiness/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:15+00:00 - Modified: 2026-07-19T21:28:15+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 2 minutes ## What you need to know Microsoft Purview Audit can investigate activity across Microsoft 365, but reliable evidence depends on verified ingestion, licensing-based retention, precise UTC queries, least-privileged access, and preserved exports. ## Potentially affected Microsoft 365 and Office 365 organizations using Purview Audit Standard or Premium for security, operational, compliance, or incident investigations. ## DSE recommendation Verify audit ingestion and retention before an event, assign limited audit roles, create narrow named searches, preserve criteria and exports, and document the expected ingestion delay and evidence chain. ## Article ## Source fact: what Microsoft documents Microsoft Purview Audit Standard and Premium provide searchable user and administrator activity across Microsoft 365 workloads. Microsoft states that unified audit search is enabled by default for Microsoft 365 and Office 365 enterprise organizations, but documents an Exchange Online PowerShell check for the actual ingestion setting. Audit searches started in the portal continue after the browser closes, and completed search jobs remain available for 30 days. Each audit user can run up to 10 search jobs concurrently, with one unfiltered job. A portal search can span up to 180 days. Broad searches in large tenants can require up to 48 hours. Microsoft says core-service records such as Exchange, SharePoint, OneDrive, and Teams are typically available in 60–90 minutes, but does not guarantee a specific ingestion time. Microsoft documents 180-day default retention for users with supported non-E5 Microsoft 365 or Office 365 licensing. Eligible E5, Purview Suite, or Audit add-on licensing provides one-year default retention for specified Entra, Exchange, and SharePoint activities, with retention-policy options dependent on licensing. The license assigned to the relevant user and the event workload affect what remains searchable. ## Permissions and applicability Searching requires Audit Logs or View-Only Audit Logs roles in the appropriate portal or role group. Export size, long-term retention, high-value events, APIs, and Premium features depend on subscription and configuration. Audit availability is not instantaneous, and absence from a result is not proof that an action did not occur. ## DSE recommendation: production-safe operational steps - Verify unified audit ingestion from Exchange Online PowerShell and record the result, date, tenant, operator, and expected retention for each licensed user class. - Assign the least-privileged audit role to named investigators and test access before an incident. Separate routine readers from administrators who can change audit configuration. - Create a search worksheet using UTC range, users, workloads, activities, record types, sites or files, keywords, and a unique search name. - Start narrow searches first, allow for ingestion, and expand one dimension at a time. Record every query change. - Export results and preserve the original file, search criteria, completion time, administrator, source portal, and hash when evidence integrity matters. - Correlate audit events with Entra sign-ins, Exchange trace, endpoint, network, application, and support evidence as appropriate. - Run a quarterly validation that generates a known benign event, waits for ingestion, locates it, exports it, and verifies authorized access. DSE recommends escalating before retention expires when an investigation may require older events. Retention policy, litigation hold, mailbox audit, and application logging are distinct controls; confirm the source needed for each question rather than assuming the unified audit log contains every relevant event. ## Official reference [Search the audit log](https://learn.microsoft.com/en-us/purview/audit-search) — ingestion, roles, retention, concurrency, time ranges, search behavior, and export workflow. ## Primary reference - Name: Microsoft Learn: Search the audit log - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/purview/audit-search - Source publication date: 2026-06-19 ## Citation and use Preferred citation: “Build a repeatable Microsoft Purview audit-search procedure before an incident,” DSE Security, https://update.dsesecurity.com/updates/microsoft-purview-audit-search-incident-readiness/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build a workplace-violence program before behavior becomes an emergency > Workplace violence prevention is not a poster or a single security response. It needs management ownership, safe reporting, multidisciplinary assessment, lawful intervention choices, emergency escalation, employee support, records, training, and post-incident recovery. - Canonical URL: https://update.dsesecurity.com/updates/build-workplace-violence-program-before-emergency/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:11:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Access Control, Business Continuity - Reading time: 3 minutes ## What you need to know Workplace violence prevention is not a poster or a single security response. It needs management ownership, safe reporting, multidisciplinary assessment, lawful intervention choices, emergency escalation, employee support, records, training, and post-incident recovery. ## Potentially affected Employees, managers, human resources, security, legal counsel, employee assistance, occupational safety, labor relations, reception, remote and field workers, contractors, visitors, emergency responders, and access decisions. ## DSE recommendation Establish a multidisciplinary program with a written scope, multiple reporting paths, imminent-danger escalation, documented assessment and case ownership, proportional interventions, privacy controls, training, and after-action support. ## Article ## Source facts: prevention and response require many disciplines The Interagency Security Committee’s 2019 [Violence in the Federal Workplace: A Guide for Prevention and Response](https://www.cisa.gov/sites/default/files/publications/isc_workplace_violence_guide_-_2019_0.pdf) presents workplace violence as an organizational program rather than a security-only incident. It addresses planning, prevention, employee relations, labor relations, employee assistance, law enforcement and security, legal considerations, written policy, threat assessment, incident response, and recovery. The guide describes benefits of a written policy, including telling employees what behavior is covered, how to report concerns, that reports will receive an appropriate response, and that management supports the program. Its scope extends beyond physical assault to threatening, intimidating, harassing, or disruptive behavior and can include contractors, visitors, interns, and other nonemployees as defined by policy. The federal guide emphasizes collaboration among functions with different responsibilities and confidentiality limits. It is not a private-employer legal standard, diagnostic manual, or substitute for emergency services. Employment law, collective-bargaining obligations, disability and leave requirements, privacy, records, state workplace-violence rules, and law-enforcement authority require qualified local guidance. ## DSE recommendation: create a trusted path from concern to managed case Appoint an executive owner and a standing multidisciplinary team that includes, as appropriate, human resources, security, legal counsel, occupational safety, employee assistance or behavioral-health expertise, labor relations, communications, facilities, and operations. Define alternates and a 24-hour emergency path. The team should not wait for a crisis to exchange phone numbers. - Publish a behavior-based scope. Give examples of threats, intimidation, stalking, domestic violence affecting work, harassment, weapon concerns, sabotage, escalating conflict, and other disruptive behavior. Avoid labels based on identity, diagnosis, protected activity, personality, or rumor. State anti-retaliation expectations and the limits of confidentiality. - Offer several reporting routes. Provide manager, HR, security, hotline, and emergency options so a concern is not trapped with the subject’s supervisor. Tell people what information helps: exact words or actions, dates, context, people involved, immediate access or location concerns, witnesses, and preserved messages. Employees should report observations, not investigate. - Separate immediate danger from assessment. For imminent threats or violence, direct people to emergency services and the site’s emergency procedure. For non-imminent concerns, assign a case owner, acknowledge receipt where appropriate, preserve information, and convene the qualified team promptly. - Assess the situation, not a stereotype. Gather reliable information across authorized sources; consider behavior, context, stressors, capability, access, targets, protective factors, and changes over time; document uncertainty; and seek specialized assessment or law enforcement support when warranted. One unusual behavior should not become an unsupported prediction. - Choose proportional interventions. Options may include supervisory action, conflict management, employee assistance, schedule or worksite changes, trespass or visitor controls, access changes, safety planning, leave, discipline, protective orders, or law-enforcement coordination. Legal and HR owners should approve employment actions; security should not improvise them. - Manage and close the case. Record decisions, owners, review dates, contact restrictions, access changes, notifications, support offered, and triggers for reassessment. Confirm temporary badges, keys, property, schedules, and access permissions are handled through normal authorized processes. Train managers and front-line employees on recognition, reporting, emergency actions, preservation of messages, and respectful response to a reporter. Give reception and security site-specific procedures for an agitated visitor, separated employee, protected person, restraining-order information, welfare concern, and law-enforcement arrival. Exercises should test coordination without sensationalizing real people or revealing confidential cases. After an incident, address medical and psychological support, family communication, scene and evidence control, continuity, employee information, media, return to work, and lessons learned. Measure reporting awareness, response time, unresolved ownership, overdue reviews, access-change completion, and corrective actions—not the number of reports driven down. A credible program makes early reporting safe, decisions multidisciplinary, emergency action fast, and recovery humane. ## Official references - Cybersecurity and Infrastructure Security Agency, Interagency Security Committee, [Violence in the Federal Workplace: A Guide for Prevention and Response](https://www.cisa.gov/sites/default/files/publications/isc_workplace_violence_guide_-_2019_0.pdf), 2019 edition. - CISA, [ISC Violence in the Federal Workplace Guide resource page](https://www.cisa.gov/resources-tools/resources/isc-violence-federal-workplace-guide). ## Primary reference - Name: CISA Interagency Security Committee: Violence in the Federal Workplace—A Guide for Prevention and Response - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/publications/isc_workplace_violence_guide_-_2019_0.pdf - Source publication date: 2019-01-01 ## Citation and use Preferred citation: “Build a workplace-violence program before behavior becomes an emergency,” DSE Security, https://update.dsesecurity.com/updates/build-workplace-violence-program-before-emergency/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build advance-notice controls for high-significance nuclear shipments > Use 10 CFR 73.72 - Advance notice of covered shipments to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/build-advance-notice-controls-for-high-significance-nuclear-shipments/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:38+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.72 - Advance notice of covered shipments to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.72 - Advance notice of covered shipments ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Build advance-notice controls for high-significance nuclear shipments. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.72 – Advance notice of covered shipments](https://www.ecfr.gov/current/title-10/section-73.72) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, a licensee who conducts an on-site transfer of spent nuclear fuel that does not travel upon or cross a public highway is exempt from the requirements of this section for that transfer. The research record locates this support at 10 CFR 73.72(b) (eCFR anchor p-73.72(b)). - Under 10 CFR 73, the rule requires that the notifications take place at the following intervals: two hours before commencement of the shipment. The research record locates this support at 10 CFR 73.72(a)(4)(ii), read with 10 CFR 73.72(a)(4) (eCFR anchor p-73.72(a)(4)(ii)). Keep the evidence boundary at these traced claims. They support a review of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish NRC regulation for defined shipments; recipients, timing, changes, protected details, secure communications, and other transport requirements demand authorized qualified review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.72(b) (eCFR anchor p-73.72(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.72(a)(4)(ii), read with 10 CFR 73.72(a)(4) (eCFR anchor p-73.72(a)(4)(ii)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 10 CFR 73.72(b) (eCFR anchor p-73.72(b)); 10 CFR 73.72(a)(4)(ii), read with 10 CFR 73.72(a)(4) (eCFR anchor p-73.72(a)(4)(ii)). Favor asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [10 CFR 73.72 – Advance notice of covered shipments](https://www.ecfr.gov/current/title-10/section-73.72) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.72 - Advance notice of covered shipments - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.72 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build advance-notice controls for high-significance nuclear shipments,” DSE Security, https://update.dsesecurity.com/updates/build-advance-notice-controls-for-high-significance-nuclear-shipments/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build an alternate-worksite plan around identity, connectivity, data, and people > An alternate location is useful only if authorized people can reach it, authenticate, communicate, obtain governed data, perform priority work, and sustain operations. Design and exercise the entire capability, not just the address. - Canonical URL: https://update.dsesecurity.com/updates/build-alternate-worksite-plan-identity-connectivity-data-people/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:46:00+00:00 - Modified: 2026-08-17T19:22:10+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know An alternate location is useful only if authorized people can reach it, authenticate, communicate, obtain governed data, perform priority work, and sustain operations. Design and exercise the entire capability, not just the address. ## Potentially affected Continuity and remote-work programs; alternate facilities; personnel and delegations; identity and privileged access; devices; connectivity; applications and data; communications; suppliers; physical security; and exercise programs. ## DSE recommendation Use business-impact priorities to define alternate-worksite capability, map people and technology dependencies, prepare secure identity and connectivity paths, protect data, document activation and authority, and exercise end-to-end work. ## Article ## Source facts: continuity capability combines people, facilities, communications, and information FEMA’s [Continuity Guidance Circular](https://www.fema.gov/sites/default/files/documents/fema_continuity-guidance-circular_082024.pdf) presents continuity concepts including essential functions, orders of succession, delegations of authority, continuity facilities, communications, essential records, human capital, devolution, reconstitution, testing, training, and exercises. These elements show why an alternate facility cannot succeed as an isolated real-estate decision. NIST [SP 800-34 Rev. 1](https://csrc.nist.gov/pubs/sp/800/34/r1/final) connects information-system contingency planning to business impact analysis, preventive controls, recovery strategies, plan development, testing, training, exercises, and maintenance. It emphasizes selecting strategies according to system impact and recovery requirements. FEMA guidance often describes public-sector continuity targets and models. Those materials can inform commercial planning, but they are not automatically contractual requirements for a private organization. The business impact analysis, safety obligations, laws, contracts, insurer conditions, and actual architecture govern the plan. ## DSE recommendation: prove the alternate site can perform priority work Design from required outcomes: who must do which work, by when, using what information and authority, when the primary workplace or technology path is unavailable. - Define essential workflows and tolerances. Use the business impact analysis to identify priority services, minimum staffing, recovery time, acceptable backlog, maximum interruption, data needs, dependencies, peak periods, and manual alternatives. Avoid planning to reproduce every normal capability immediately. - Select a strategy by scenario. Compare remote work, another company facility, contracted workspace, reciprocal arrangement, mobile capability, and distributed teams against regional outage, building denial, cyber incident, carrier failure, public-health event, and staff displacement. One alternate location may share the same hazard as the primary. - Prepare people and authority. Maintain call trees, succession, delegations, role assignments, accessibility needs, travel and family considerations, safety, transportation, lodging, and alternates. Make essential contacts and authority records available when primary identity or document systems are unavailable. - Engineer identity and devices. Provide managed endpoints, phishing-resistant authentication where supported, emergency accounts with controlled custody, privileged access, software, certificates, chargers, spares, secure configuration, replacement and wipe procedures. Test first-time sign-in and recovery without relying on the unavailable office. - Provide diverse communications and connectivity. Validate internet, voice, collaboration, VPN or zero-trust access, DNS, identity reachability, carrier diversity, power, capacity, and support. Document degraded modes and prevent the alternate path from bypassing segmentation or monitoring. - Protect data and records. Identify authoritative records, offline or protected copies, synchronization, recovery point, encryption, access, printing, disposal, transport, and return. Prevent local convenience copies from becoming ungoverned long-term systems of record. - Exercise activation through reconstitution. Trigger notification, travel or remote activation, identity, connectivity, application access, a representative workflow, communications, shift turnover, outage support, and return to normal operations. Capture decisions, timings, failures, workarounds, and corrective actions. Plan for the alternate location itself to fail or become unavailable. Identify the decision point for moving to distributed work, a second location, manual service, or temporary suspension. Preserve current reservations, access instructions, keys or badges, equipment assignments, and supplier escalation without exposing the site’s security details more broadly than necessary. Include sustained operations, not only first-day activation. Exercise shift coverage, fatigue, supervision, replenishment, secure disposal, software updates, device replacement, helpdesk, privileged administration, backup jobs, incident response, mail and deliveries, financial approvals, and reconciliation of work created while systems were degraded. Set conditions for safe reconstitution at the primary site. Factual boundary: The cited federal guidance provides planning models, not a universal mandate or proof that a commercial arrangement is sufficient. Employee safety, labor, accessibility, privacy, insurance, lease, regulatory, customer, and technology requirements require appropriate qualified review. Measure activation time, reachable staff, authentication success, usable capacity, essential workflow completion, data reconciliation, unplanned dependencies, and corrective-action closure. A signed contract for space is not continuity evidence; a safely exercised operating capability is. ## Official references - FEMA, [Continuity Guidance Circular](https://www.fema.gov/sites/default/files/documents/fema_continuity-guidance-circular_082024.pdf). - NIST, [SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems](https://csrc.nist.gov/pubs/sp/800/34/r1/final). ## Primary reference - Name: FEMA Continuity Guidance Circular - Authority: Federal Emergency Management Agency - URL: https://www.fema.gov/sites/default/files/documents/fema_continuity-guidance-circular_082024.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build an alternate-worksite plan around identity, connectivity, data, and people,” DSE Security, https://update.dsesecurity.com/updates/build-alternate-worksite-plan-identity-connectivity-data-people/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build an evidence-based exit from Windows Server 2016 before January 12, 2027 > Windows Server 2016 extended support ends January 12, 2027. An exit plan needs workload ownership, dependency and compatibility evidence, a supported target path, tested recovery, migration proof, and documented retirement—not only an OS count. - Canonical URL: https://update.dsesecurity.com/updates/build-an-evidence-based-exit-from-windows-server-2016-before-january-12-2027/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Windows Server 2016 extended support ends January 12, 2027. An exit plan needs workload ownership, dependency and compatibility evidence, a supported target path, tested recovery, migration proof, and documented retirement—not only an OS count. ## Potentially affected Windows Server 2016 Standard, Datacenter, Essentials, MultiPoint Premium, associated Windows Server 2016 containers, and business services, applications, infrastructure roles, agents, or integrations that depend on them. ## DSE recommendation Create an authoritative Windows Server 2016 workload register, choose and test an exit path for each service, and escalate any workload without a supported target, accountable owner, recovery proof, and approved completion date. ## Article ## Source fact: the fixed lifecycle date is January 12, 2027 Microsoft’s [Windows Server 2016 lifecycle page](https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2016) lists January 12, 2027 as the end of extended support for Datacenter, Essentials, MultiPoint Premium, and Standard editions. Microsoft also states that containers released with Windows Server 2016 follow the same lifecycle dates. End of extended support is an operating-system fact; it does not automatically establish the support status of every application running on that server, which must be checked with its publisher. Microsoft’s 2027 support list also names related Windows Server 2016-era products and components. Treat them as separate inventory objects rather than assuming an OS upgrade resolves every dependency. Database engines, backup agents, security tools, drivers, management platforms, identity roles, and vendor applications can each have distinct support and upgrade conditions. ## Source fact: several transition methods exist, with restrictions Microsoft distinguishes migration, which moves roles or features to a newer server, from an in-place upgrade that installs a newer operating system while retaining roles, settings, and data. Its current [upgrade-path guidance](https://learn.microsoft.com/en-us/windows-server/get-started/install-upgrade-migrate) shows supported in-place paths from Windows Server 2016 to Windows Server 2019, 2022, or 2025 for eligible nonclustered systems. It also documents restrictions involving architecture, language, evaluation editions, clusters, and particular roles. A supported path is permission to test, not proof that a workload is compatible. The [role migration guidance](https://learn.microsoft.com/en-us/windows-server/get-started/upgrade-migrate-roles-features) shows that some roles support migration, some support in-place upgrade, and some require their own procedure. Domain controllers, clusters, certificate services, file services, application servers, and vendor appliances should not share one generic runbook. ## DSE recommendation: inventory services, not just machines For each Windows Server 2016 instance, record business service, accountable owner, technical owner, edition and installation type, physical or virtual platform, cluster status, server roles and features, applications and versions, databases, service identities, certificates, scheduled tasks, interfaces, firewall flows, DNS names, storage, backup and restore method, monitoring, security agents, licensing, data classification, availability requirement, and upstream and downstream dependencies. Reconcile hypervisor, cloud, Active Directory, vulnerability, backup, monitoring, and procurement sources to find dormant or unmanaged systems. Assign one evidence-backed disposition: retire; replace or replatform the application; migrate roles to a new server; perform an in-place upgrade; or use a separately verified, time-bounded support option. Rehosting the same Windows Server 2016 image changes location, not its lifecycle. Do not assume Extended Security Updates are available or suitable for a particular server; obtain current written Microsoft licensing and technical eligibility before using any such option as a bridge. ## DSE recommendation: use exit gates - Discovery gate: ownership, purpose, dependencies, support contracts, and business impact are confirmed. - Design gate: the target version or service is supported by Microsoft and every critical application, role, driver, and agent. The migration method, security baseline, identity changes, licensing, downtime, and rollback are approved. - Recovery gate: backups, keys, installation media, configuration, credentials, and restoration procedures are available and tested in a safe environment. - Pilot gate: representative testing proves authentication, data integrity, integrations, performance, monitoring, backup, patching, failover where applicable, and operational support. - Production gate: change records identify decision authority, communications, success criteria, stop conditions, rollback boundaries, and evidence collectors. - Retirement gate: traffic and dependencies have moved, data is retained or disposed under policy, identities and certificates are revoked or reassigned, records are updated, and the old instance cannot quietly return. ## Report exceptions as business decisions Maintain a dashboard of services, not an optimistic device percentage. Show disposition, target, owner, test status, blocker, next decision, support evidence, planned window, and verified retirement. Escalate missing owners, unsupported applications, failed restore tests, unavailable media or keys, and plans that end after January 12, 2027 without verified coverage. Keep residual-risk acceptance separate from technical completion. This article narrows DSE’s broader patch-management and update-window guidance to a fixed Windows Server 2016 lifecycle exit. Monthly patch success remains necessary, but it cannot substitute for moving the workload to a supported operating model. ## Official sources - [Microsoft Lifecycle: Windows Server 2016](https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2016) - [Microsoft Lifecycle: Products ending support in 2027](https://learn.microsoft.com/en-us/lifecycle/end-of-support/end-of-support-2027) - [Microsoft Learn: Plan your Windows Server upgrade path](https://learn.microsoft.com/en-us/windows-server/get-started/install-upgrade-migrate) - [Microsoft Learn: Upgrade and migrate Windows Server roles and features](https://learn.microsoft.com/en-us/windows-server/get-started/upgrade-migrate-roles-features) ## Primary reference - Name: Microsoft Lifecycle — Windows Server 2016 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/lifecycle/products/windows-server-2016 - Source publication date: 2024-06-04 ## Citation and use Preferred citation: “Build an evidence-based exit from Windows Server 2016 before January 12, 2027,” DSE Security, https://update.dsesecurity.com/updates/build-an-evidence-based-exit-from-windows-server-2016-before-january-12-2027/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build an incident channel you can trust when collaboration is compromised > An alternate chat room is not enough when attackers can monitor normal tools or impersonate responders. Pre-provision independent communications, verify identities through trusted records, and exercise degraded-mode operations. - Canonical URL: https://update.dsesecurity.com/updates/build-an-incident-channel-you-can-trust-when-collaboration-is-compromised/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 4 minutes ## What you need to know An alternate chat room is not enough when attackers can monitor normal tools or impersonate responders. Pre-provision independent communications, verify identities through trusted records, and exercise degraded-mode operations. ## Potentially affected Incident response, IT operations, security operations, executives, legal, communications, identity administrators, business continuity teams, and external responders. ## DSE recommendation Establish an independently accessible incident channel, offline contact and authority records, multi-step responder verification, operating rules, and recurring failover exercises. ## Article ## Source fact: normal collaboration can become an incident dependency CISA’s [StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide) warns that malicious actors may monitor an organization’s communications and recommends coordinated isolation using out-of-band methods such as phone calls when necessary to avoid tipping them off. The lesson is broader than ransomware: email, chat, identity, endpoint management, directories, or network access may be unavailable, observed, or manipulated during an incident. The [CISA Cyber Storm IX After-Action Report](https://www.cisa.gov/sites/default/files/2024-10/Cyber%20Storm%20IX%20After-Action%20Report%20v00%2020241001_508.pdf) found that ordinary communication methods could be suboptimal during a cyber incident and identified the need for consolidated out-of-band capability and established primary and alternate methods. The Cyber Safety Review Board’s [review of Lapsus$](https://www.cisa.gov/sites/default/files/2023-08/CSRB_Lapsus%24_508c.pdf) describes out-of-band communication as an alternative separate from the primary channel and says it is best established before an attack. ## DSE recommendation: separate availability from identity assurance DSE recommendation: design two related controls. The first is an alternate communications plane that does not rely on the systems most likely to fail together. The second is a responder-verification process that establishes who is in the channel and what authority that person holds. A working alternate chat tool solves availability; it does not prove that a display name belongs to an authorized responder. ## Pre-provision the alternate communications plane - Map shared dependencies. Document whether the alternate service relies on the same identity provider, email inbox, phone, managed device, password vault, DNS, network, cloud tenant, administrator, or supplier as the normal service. Independence is a design claim to test, not a product label. - Create and protect access in advance. Establish accounts, strong authentication, administrators, recovery methods, license capacity, rooms, retention settings, and external-participant rules. Limit standing access while ensuring the incident commander can activate the channel without the compromised system. - Keep essential records offline or separately controlled. Maintain current contact methods, incident roles, delegation and approval authorities, supplier escalation paths, and instructions for finding the alternate service. Protect this material according to its sensitivity and test that authorized users can retrieve it. - Define activation and fallback. State who can declare normal communications untrusted, how the activation message is distributed, which channel becomes authoritative, and what to do if that channel also fails. ## Verify people before granting incident authority Current threat reporting shows why channel access is not enough. A joint FBI and CISA [advisory on Scattered Spider](https://www.fbi.gov/file-repository/cyber-alerts/scattered-spider-072925.pdf) describes actors impersonating employees or IT staff to persuade help desks to reset passwords or multifactor authentication. Incident activation is an attractive setting for the same social engineering because urgency and unfamiliar participants weaken routine checks. Use a trusted roster and a known contact path that the arriving person did not supply. Call a pre-recorded number, use a separately established organizational identity, or obtain confirmation from an accountable manager through another verified route. Require two authorized people to approve the addition of a participant who will receive sensitive evidence, administrative access, or decision authority. Confirm role and authority separately from personal identity. A code word shared widely or presented in the same suspicious conversation is not strong proof. ## Operate the channel deliberately Assign an incident identifier, channel owner, participant recorder, decision log, and regular roll call. Mark authoritative instructions and require recipients to acknowledge high-impact actions. Record joins, departures, role changes, approvals, and handoffs. Share the minimum necessary secrets and evidence; an alternate channel should not become an uncontrolled repository for credentials, customer data, or malware samples. Give external counsel, insurers, vendors, and law enforcement a planned route appropriate to their role. ## Exercise failure, then retire access safely Test loss or compromise of the normal identity provider, email, chat, phones, devices, and directory in different combinations. Ask responders to activate the alternate plane, authenticate one another, add an outside party, issue a verified instruction, and preserve a decision record. After an actual incident, revalidate the participant list, export required records under policy, rotate exposed credentials, remove temporary access, and decide when normal communications can again be trusted. The outcome is not merely that a message was sent; it is that an authorized decision reached the correct operator through a channel both available and trustworthy. ## Official sources - [CISA: StopRansomware Guide](https://www.cisa.gov/stopransomware/ransomware-guide) - [CISA: Cyber Storm IX After-Action Report](https://www.cisa.gov/sites/default/files/2024-10/Cyber%20Storm%20IX%20After-Action%20Report%20v00%2020241001_508.pdf) - [Cyber Safety Review Board: Review of the Attacks Associated with Lapsus$](https://www.cisa.gov/sites/default/files/2023-08/CSRB_Lapsus%24_508c.pdf) - [FBI and CISA: Scattered Spider Cybersecurity Advisory](https://www.fbi.gov/file-repository/cyber-alerts/scattered-spider-072925.pdf) ## Primary reference - Name: CISA Cyber Storm IX After-Action Report - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/2024-10/Cyber%20Storm%20IX%20After-Action%20Report%20v00%2020241001_508.pdf - Source publication date: 2024-10-01 ## Citation and use Preferred citation: “Build an incident channel you can trust when collaboration is compromised,” DSE Security, https://update.dsesecurity.com/updates/build-an-incident-channel-you-can-trust-when-collaboration-is-compromised/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build an incident-response plan before the first urgent call > Prepare roles, decision authority, contacts, evidence practices, communications, containment choices, and recovery criteria before a cybersecurity incident forces the organization to make high-impact decisions under pressure. - Canonical URL: https://update.dsesecurity.com/updates/build-incident-response-plan/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:09+00:00 - Modified: 2026-07-19T19:03:09+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 2 minutes ## What you need to know Prepare roles, decision authority, contacts, evidence practices, communications, containment choices, and recovery criteria before a cybersecurity incident forces the organization to make high-impact decisions under pressure. ## Potentially affected Executives, business owners, IT teams, legal and communications contacts, insurers, and operational leaders with incident responsibilities. ## DSE recommendation Create a one-page activation sheet, validate every contact through a separate channel, and exercise one realistic scenario with decision-makers. ## Article During a cybersecurity incident, uncertainty and time pressure can turn a technical problem into a larger business disruption. A usable incident-response plan tells people who can make decisions, how to communicate, what must be preserved, and when to involve qualified outside parties. ## What the official source says Source fact: NIST SP 800-61 Revision 3 integrates incident response throughout Cybersecurity Framework 2.0 risk-management activities. NIST says this approach can help organizations prepare, reduce the number and impact of incidents, and improve detection, response, and recovery. The publication supersedes Revision 2. ## Build the activation sheet first DSE recommendation: keep a short, protected copy of the information needed during the first hour. Make it accessible even if normal email, identity, file sharing, or phone systems are unavailable. - Primary and alternate incident leads, executive decision-maker, and note keeper. - Current contacts for IT, security providers, cyber insurer, legal counsel, communications, critical suppliers, and appropriate authorities. - Criteria for activating the plan and escalating a suspected event. - Approved out-of-band communications and a rule against discussing the incident in potentially compromised channels. - Authority for isolating systems, disabling accounts, interrupting services, preserving evidence, and beginning recovery. ## Plan the decisions, not every possible attack Document critical services and dependencies, logging sources, backups, system owners, data owners, and recovery priorities. Define how responders will record observations, times, commands, transfers, and decisions. Establish a safe method for collecting potential evidence while limiting access and preserving original material when practical. DSE recommendation: separate confirmed facts, working hypotheses, and decisions in the incident log. State who verified each fact and when. This reduces the chance that an early assumption becomes an inaccurate customer, employee, regulator, insurer, or public statement. ## Exercise and maintain the plan Run a tabletop exercise that requires actual decision-makers to work through a plausible scenario. Test unavailable contacts, compromised email, vendor escalation, business shutdown authority, restoration priorities, and external communications. Record gaps and assign remediation owners. Repeat after material changes in systems, suppliers, leadership, insurance, or legal obligations. ## Important limits This guide is operational education, not legal advice or a breach-notification determination. Notification, evidence, employment, privacy, insurance, and law-enforcement decisions require the organization’s qualified advisers. DSE support should not be represented as digital forensics, breach counsel, crisis communications, or an incident-response retainer unless those services are expressly contracted. Practical next step: schedule a 60-minute tabletop around a lost administrator account or encrypted file server. Require the team to locate contacts and make decisions using the current plan, then correct the highest-impact gap. ## Primary reference - Name: NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/61/r3/final - Source publication date: 2025-04-03 ## Citation and use Preferred citation: “Build an incident-response plan before the first urgent call,” DSE Security, https://update.dsesecurity.com/updates/build-incident-response-plan/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build an insider-risk program that protects assets, people, and privacy > Insider risk cannot be managed by surveillance alone. Use multidisciplinary governance, critical-asset controls, narrowly justified monitoring, human review, support pathways, privacy safeguards, and consistent response. - Canonical URL: https://update.dsesecurity.com/updates/build-an-insider-risk-program-that-protects-assets-people-and-privacy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 4 minutes ## What you need to know Insider risk cannot be managed by surveillance alone. Use multidisciplinary governance, critical-asset controls, narrowly justified monitoring, human review, support pathways, privacy safeguards, and consistent response. ## Potentially affected Executives, human resources, legal, privacy, cybersecurity, physical security, safety, managers, identity teams, and owners of critical assets and services. ## DSE recommendation Charter a multidisciplinary insider-risk program, define protected assets and lawful data use, strengthen access controls, create supportive reporting routes, and review cases with privacy and due-process safeguards. ## Article ## Source fact: insider threat is a human and technical risk CISA’s [Insider Threat Mitigation Guide](https://www.cisa.gov/sites/default/files/2022-11/Insider%20Threat%20Mitigation%20Guide_Final_508.pdf) treats insider threat as a complex interaction of people, organizations, facilities, and technology. It promotes early intervention and assistance before negligence, grievance, stressors, or malicious intent become an incident. CISA also says management actions should respect dignity, rights, civil liberties, and privacy. The guide presents options for organizations to tailor; it is not a substitute for legal requirements or professional advice. CISA’s [Insider Threat Mitigation resources](https://www.cisa.gov/topics/physical-security/insider-threat-mitigation/resources-and-tools) emphasize a multidisciplinary capability rather than ownership by a single monitoring team. Cybersecurity, physical security, human resources, legal, privacy, safety, and management may each hold only part of the context needed for a fair and useful assessment. ## DSE recommendation: begin with governance and protected assets DSE recommendation: charter an insider-risk program with a prevention and support purpose, defined authority, accountable executive, multidisciplinary review group, legal and privacy oversight, and written limits on collection and use. Have qualified counsel review applicable law, employment arrangements, collective-bargaining obligations, regulatory duties, and organizational policy. This article provides program design guidance, not a legal conclusion. Identify the assets and services whose misuse, destruction, disclosure, or unavailability could cause material harm. Include sensitive data, administrative access, financial authority, source code, security systems, safety functions, facilities, and recovery capabilities as relevant. Then document who can reach them, through which systems and physical paths, under what approval, and how access is removed. A program that starts with broad employee observation before defining risk is difficult to justify and govern. ## Reduce opportunity with ordinary controls - Apply least privilege, separation of duties, privileged-access controls, and access reviews to critical assets. - Connect hiring, role change, leave, contractor, and departure events to timely physical and logical access changes. - Protect audit records and investigate unexplained gaps in logging on critical systems. - Use data-loss and behavior signals only where they are tied to a defined risk, appropriate authority, and a documented response process. - Design recovery, reconciliation, and peer-review controls so a single action cannot silently create irreversible harm. These controls reduce both malicious and accidental harm without requiring a judgment about a person’s motives. NIST’s [SP 800-53 control catalog](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) provides official control families for access control, audit, personnel security, incident response, and related safeguards; organizations still select and tailor controls for their own risk. ## Put privacy boundaries around monitoring For every data source, record the specific risk purpose, authority, fields collected, population covered, retention, access roles, permitted uses, review method, and deletion process. Collect the minimum information needed. Separate routine administration from case access, log analyst activity, and require human review before an adverse or high-impact response. Test the quality and bias of rules; unusual work patterns can reflect accessibility needs, travel, caregiving, incident duties, or broken business processes. The [NIST Privacy Framework](https://www.nist.gov/privacy-framework) provides a voluntary risk-management structure for identifying and managing privacy risk. Use it to examine how collection, correlation, and disclosure can affect people, not merely whether a monitoring platform can ingest the data. ## Report behaviors, offer help, and respond consistently Train personnel to report observable behavior or control concerns rather than diagnoses, demographic traits, protected activity, rumors, or labels. Provide more than one route for seeking help or raising a concern, including a route outside the immediate management chain. State what happens after a report, how confidentiality is handled, and when imminent safety concerns require emergency action. The multidisciplinary group should validate facts, consider benign explanations, assess urgency and potential harm, identify support or control options, and document the rationale for action. Responses may range from correcting access or a work process, through assistance and supervision, to formal investigation or emergency escalation under established authority. Use consistent criteria and review high-impact decisions; do not let a risk score automatically determine an employment action. ## Measure prevention without rewarding surveillance Useful measures include critical assets with current access ownership, overdue departure access, time to correct control gaps, support referrals completed under appropriate confidentiality, cases receiving multidisciplinary review, and corrective actions retested. Break measures down enough to find process problems while preventing re-identification in executive reporting. Raw alerts, employee watch lists, or terabytes collected are not evidence that people or assets are safer. ## Official sources - [CISA: Insider Threat Mitigation Guide](https://www.cisa.gov/sites/default/files/2022-11/Insider%20Threat%20Mitigation%20Guide_Final_508.pdf) - [CISA: Insider Threat Mitigation Resources and Tools](https://www.cisa.gov/topics/physical-security/insider-threat-mitigation/resources-and-tools) - [NIST: Privacy Framework](https://www.nist.gov/privacy-framework) - [NIST: SP 800-53 Rev. 5 controls](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) ## Primary reference - Name: CISA Insider Threat Mitigation Guide - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/2022-11/Insider%20Threat%20Mitigation%20Guide_Final_508.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build an insider-risk program that protects assets, people, and privacy,” DSE Security, https://update.dsesecurity.com/updates/build-an-insider-risk-program-that-protects-assets-people-and-privacy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build an IPsec profile before negotiating each tunnel by exception > Standardize IPsec and IKE choices, lifecycles, monitoring, and exceptions before adding more site-to-site VPNs. - Canonical URL: https://update.dsesecurity.com/updates/build-an-ipsec-profile-before-tunnel-exceptions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:44+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Standardize IPsec and IKE choices, lifecycles, monitoring, and exceptions before adding more site-to-site VPNs. ## Potentially affected Organizations operating IPsec virtual private networks across the Internet or other untrusted networks ## DSE recommendation Adopt approved interoperable IPsec profiles, record deviations, and test rekey, failover, and recovery as well as initial establishment. ## Article An IPsec tunnel that comes up once is not yet an operational standard. The harder failures often arrive at rekey, certificate rollover, peer failover, path-MTU change, or an emergency rebuild when undocumented exceptions must be rediscovered. ## Source fact: [NIST Special Publication 800-77 Revision 1](https://csrc.nist.gov/pubs/sp/800/77/r1/final) provides guidance on IPsec virtual private networks. It describes the IPsec framework and Internet Key Exchange, the security services they can provide, and practical considerations for implementing IPsec-based VPNs. The publication also discusses alternatives and the need to select designs and controls that match an organization’s environment and risk. IPsec can protect network-layer traffic between configured endpoints through authentication, integrity, and confidentiality services selected by policy. IKE establishes and manages the security associations used by the tunnel. The publication is guidance rather than a statement that any named algorithm, product default, or configuration remains appropriate indefinitely. ## Boundary A secure cryptographic profile does not make either endpoint, routing table, or application trustworthy. Interoperability depends on exact platform support and identity configuration. NAT, fragmentation, MTU, asymmetric routing, overlapping addresses, policy selectors, certificate revocation access, and high-availability behavior can affect service without appearing as a basic IKE failure. Requirements imposed by contracts or regulated environments need separate review. ## Applicability questions - Which tunnel types and peer classes need distinct profiles, such as managed branch, partner, cloud, or remote access? - How are peers authenticated, and how are keys or certificates issued, stored, rotated, and revoked? - Which cryptographic choices are supported on both sides and approved under current organizational policy? - What traffic selectors, routes, MTU handling, logging, and high-availability dependencies apply? - Who owns partner coordination during rekey or an incident? ## DSE recommendation: Create a small set of versioned profiles covering IKE version, authentication, approved algorithm suites, lifetimes, rekey behavior, identity matching, dead-peer detection, logging, and traffic selectors. Validate each profile against current organizational cryptographic policy and the exact products involved. Record every deviation with a business owner, technical rationale, risk decision, and expiration or migration date. Test initial establishment and steady traffic, then force child and IKE rekeys, peer restart, certificate renewal, path failover, packet loss, MTU constraints, and restoration from backed-up configuration. Confirm the monitoring differentiates negotiation, authentication, selector, and routing failures. Protect secrets and private keys from ordinary configuration exports, and document an emergency rebuild that does not rely on the failed tunnel. ## Verification and evidence Keep the approved profile, platform matrix, sanitized configurations, identity and certificate lifecycle records, exception register, negotiated-parameter output, traffic tests, and failure/recovery timestamps. Evidence should show that both directions carry only intended networks and that rekey does not create an unacceptable interruption. Periodically compare deployed tunnels with the standard and review exceptions before renewals or platform upgrades. ## Official references - [NIST SP 800-77 Rev. 1](https://csrc.nist.gov/pubs/sp/800/77/r1/final) ## Primary reference - Name: NIST SP 800-77 Rev. 1: Guide to IPsec VPNs - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/77/r1/final - Source publication date: 2020-06-30 ## Citation and use Preferred citation: “Build an IPsec profile before negotiating each tunnel by exception,” DSE Security, https://update.dsesecurity.com/updates/build-an-ipsec-profile-before-tunnel-exceptions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build critical-access-hospital continuity around rural dependencies > Use 42 CFR 485.625 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/build-critical-access-hospital-continuity-around-rural-dependencies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:59+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 485.625 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 485.625 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Build critical-access-hospital continuity around rural dependencies. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 485.625 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-485.625) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 485, the rule requires that if elected, the unified and integrated emergency preparedness program do all of the following: include integrated policies and procedures that meet the requirements set forth in paragraph (b) of this section, a coordinated communication plan and training and testing programs that meet the requirements of paragraphs (c) and (d) of this section, respectively. The research record locates this support at 42 CFR 485.625(f)(5), read with 42 CFR 485.625(f) (eCFR anchor p-485.625(f)(5)). - Under 42 CFR 485, the rule requires that the CAH develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 485.625(d) (eCFR anchor p-485.625(d)). The source support ends with the statements listed above. Use them to examine essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives in the applicable environment, not to imply a wider guarantee. ## What the source does not establish CAH-specific federal condition of participation; rural transport, referral hospitals, utilities, staffing, emergency power, state law, and survey guidance require complete review. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 485.625(f)(5), read with 42 CFR 485.625(f) (eCFR anchor p-485.625(f)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 485.625(d) (eCFR anchor p-485.625(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 42 CFR 485.625(f)(5), read with 42 CFR 485.625(f) (eCFR anchor p-485.625(f)(5)); 42 CFR 485.625(d) (eCFR anchor p-485.625(d)). Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [42 CFR 485.625 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-485.625) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 485.625 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-485.625 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build critical-access-hospital continuity around rural dependencies,” DSE Security, https://update.dsesecurity.com/updates/build-critical-access-hospital-continuity-around-rural-dependencies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build cyber supply-chain risk management into the full product lifecycle > Cyber supply-chain risk management connects enterprise governance, business processes, acquisition, supplier evidence, operating oversight, incident coordination, continuity, and secure exit. - Canonical URL: https://update.dsesecurity.com/updates/cybersecurity-supply-chain-lifecycle-governance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:10+00:00 - Modified: 2026-07-19T21:27:10+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 2 minutes ## What you need to know Cyber supply-chain risk management connects enterprise governance, business processes, acquisition, supplier evidence, operating oversight, incident coordination, continuity, and secure exit. ## Potentially affected Organizations acquiring or operating hardware, software, cloud services, managed services, data services, connected devices, components, or other technology with supplier dependencies. ## DSE recommendation Define tiered governance, map critical suppliers and sub-tier dependencies, require proportionate evidence, monitor lifecycle change, and plan transition and end-of-life treatment. ## Article A supplier questionnaire at purchase time cannot manage a product whose ownership, components, access, vulnerabilities, hosting, support, or sub-tier dependencies change over years. Cyber supply-chain risk management is a lifecycle and organizational responsibility. ## What NIST includes in C-SCRM Source fact: NIST SP 800-161 Rev. 1 Update 1 addresses risks from products or services that may contain malicious functionality, be counterfeit, or remain vulnerable because of poor manufacturing or development practices. NIST also highlights reduced buyer visibility into how acquired technology is developed, integrated, deployed, supported, and protected. Source fact: NIST integrates cybersecurity supply-chain risk management with broader risk management at enterprise, mission or business-process, and operational levels. The publication covers C-SCRM strategy and implementation plans, policy, plans, and risk assessment for products and services. This structure makes procurement one phase of continuing risk management rather than the finish line. ## Scale diligence to business impact DSE recommendation: define which products and services enter the C-SCRM process and tier them by impact, access, data, privilege, connectivity, replaceability, concentration, safety, and continuity dependency. Apply stronger evidence and approval requirements to higher-impact tiers instead of sending every supplier the same unreviewed questionnaire. - Map critical suppliers, products, sub-tier dependencies, data and administrative access, hosting regions, integration paths, and lifecycle stage. - Request evidence proportionate to risk, such as secure-development practices, component governance, vulnerability handling, update integrity, incident history, independent assessment, continuity, and support commitments. - Where appropriate, put security responsibilities, incident notice, access control, logging, vulnerability remediation, update and support, audit evidence, business continuity, data return or destruction, and exit expectations into agreements. - Assign owners to review changes in product architecture, components, ownership, support, access, data use, vulnerabilities, and material incidents. - Plan alternatives and transition before end of support, contract termination, supplier failure, or unacceptable residual risk. ## Record decisions without inventing certainty DSE recommendation: distinguish supplier statements, self-attestations, independent assessments, certifications, customer testing, and observed operating evidence. Record unresolved questions and residual risk with the appropriate acceptance authority. A completed questionnaire, certificate, or software bill of materials informs a decision but does not prove that a supplier or product is free of compromise or vulnerability. ## Applicability and limits NIST’s publication is comprehensive and federal-oriented, so organizations must tailor it. It does not produce a binary safe-vendor result and does not replace legal, procurement, sanctions, export, privacy, sector, insurance, accessibility, or contract review. Some evidence may be unavailable or sensitive; the organization must decide whether compensating controls, acceptance, transfer, avoidance, or another supplier is appropriate. ## Official reference [NIST SP 800-161 Rev. 1 Update 1](https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final) — lifecycle cybersecurity supply-chain risk-management practices. ## Primary reference - Name: NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final - Source publication date: 2024-11-01 ## Citation and use Preferred citation: “Build cyber supply-chain risk management into the full product lifecycle,” DSE Security, https://update.dsesecurity.com/updates/cybersecurity-supply-chain-lifecycle-governance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build emergency readiness around the RNHCI care model > Use 42 CFR 403.748 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/build-emergency-readiness-around-the-rnhci-care-model/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:10+00:00 - Modified: 2026-08-27T13:06:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 403.748 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 403.748 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Build emergency readiness around the RNHCI care model. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 403.748 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-403.748) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 403, the rule requires that the RNHCI develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 403.748(d) (eCFR anchor p-403.748(d)). - Under 42 CFR 403, the rule requires that if the emergency preparedness policies and procedures are significantly updated, the RNHCI conduct training on the updated policies and procedures. The research record locates this support at 42 CFR 403.748(d)(1)(v) (eCFR anchor p-403.748(d)(1)(v)). Only the traced statements above are asserted as source facts. Apply the review to essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives after confirming that the source and deployed context match. ## What the source does not establish Provider-specific federal participation requirement; confirm current certification status, waivers, survey guidance, state law, and the complete section before applying it. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 403.748(d) (eCFR anchor p-403.748(d)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 403.748(d)(1)(v) (eCFR anchor p-403.748(d)(1)(v)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from 42 CFR 403.748(d) (eCFR anchor p-403.748(d)); 42 CFR 403.748(d)(1)(v) (eCFR anchor p-403.748(d)(1)(v)) through business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [42 CFR 403.748 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-403.748) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 403.748 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-403.748 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build emergency readiness around the RNHCI care model,” DSE Security, https://update.dsesecurity.com/updates/build-emergency-readiness-around-the-rnhci-care-model/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build event logging that supports detection, investigation, and resilience > Current joint guidance centers effective logging on approved policy, centralized collection and correlation, protected log integrity, and detections designed for relevant threats. - Canonical URL: https://update.dsesecurity.com/updates/event-logging-detection-integrity-baseline/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:26:27+00:00 - Modified: 2026-07-19T21:26:27+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Current joint guidance centers effective logging on approved policy, centralized collection and correlation, protected log integrity, and detections designed for relevant threats. ## Potentially affected Organizations collecting security events from identity, endpoint, network, application, cloud, mobile, or operational-technology environments. ## DSE recommendation Approve the logging purpose and scope, inventory high-value sources, normalize time, centralize and protect events, build relevant detections, and test the complete alert path. ## Article Logs become security evidence only when the organization knows why they are collected, can correlate them, protects their integrity, and turns relevant activity into a tested response. Collecting everything without ownership can increase cost while leaving important gaps unnoticed. ## Four practices in the joint guidance Source fact: CISA and international partners published event-logging and threat-detection guidance for cloud services, enterprise information-technology networks, enterprise mobility, and operational-technology networks. The intended audience includes senior IT decision makers, security practitioners, IT managers, OT operators, and network administrators. Source fact: The guidance identifies four central considerations: an enterprise-approved event-logging policy; centralized log collection and correlation; secure storage and log integrity; and a detection strategy for relevant threats. It also highlights consistent event content, formats, and timestamps as important to useful analysis. ## Define the evidence before the platform DSE recommendation: approve the business and security purpose of logging before selecting retention or storage architecture. Record the environments and sources in scope, accountable owners, required events and context, access restrictions, time standard, retention basis, review expectations, privacy considerations, provider responsibilities, and disposal process. - Inventory identity, administrator, endpoint, server, application, cloud, firewall, network-device, DNS, remote-access, mobile, and relevant OT sources. - Prioritize events that can establish authentication, privilege, configuration change, execution, network movement, data access, service health, and defensive-control activity. - Normalize timestamps and preserve source, user, device, action, result, and correlation context where the system can provide it. - Centralize high-value events and monitor for delayed, malformed, duplicated, or stopped ingestion. - Restrict and monitor access, protect events from alteration and deletion, and maintain recovery appropriate to the evidence requirement. ## Prove detection and response DSE recommendation: define detections from credible threats and the organization’s environment, not from an unreviewed vendor default list. For each detection, name the expected data, logic, owner, urgency, investigation context, escalation, safe test, and review date. Run a known-safe test from source event through collection, correlation, alert, triage, and response. A visible source log does not prove the alert path works. ## Applicability and limits The joint publication is a baseline, not a universal event list, storage design, or retention schedule. Privacy, employment, legal, contractual, regulatory, safety, cost, and system-capacity requirements vary. OT and safety systems may require vendor-approved methods and careful testing. Logs can support an investigation but may be incomplete, inaccurate, compromised, or insufficient on their own. ## Official reference [Best Practices for Event Logging and Threat Detection](https://www.cisa.gov/resources-tools/resources/best-practices-event-logging-and-threat-detection) — joint baseline for policy, centralization, integrity, and detection. ## Primary reference - Name: CISA: Best Practices for Event Logging and Threat Detection - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/resources-tools/resources/best-practices-event-logging-and-threat-detection - Source publication date: 2024-08-21 ## Citation and use Preferred citation: “Build event logging that supports detection, investigation, and resilience,” DSE Security, https://update.dsesecurity.com/updates/event-logging-detection-integrity-baseline/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build IPFIX flow telemetry you can trust before an incident > IPFIX can show who communicated, when, where, and how much—if observation points, templates, clocks, sampling, transport, retention, and collector health are engineered and tested first. - Canonical URL: https://update.dsesecurity.com/updates/build-trustworthy-ipfix-flow-telemetry/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:16:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know IPFIX can show who communicated, when, where, and how much—if observation points, templates, clocks, sampling, transport, retention, and collector health are engineered and tested first. ## Potentially affected Routers; switches; firewalls; cloud networks; IPFIX exporters and collectors; templates; time sources; sampling; storage; SIEM and NDR tools; incident response; privacy; and retention. ## DSE recommendation Define investigation questions, place observation points deliberately, select and document fields, monitor templates and sequence gaps, validate clocks and sampling, size collectors, protect telemetry, and test known traffic end to end. ## Article ## Source facts: IPFIX exports structured observations about flows [RFC 7011](https://www.rfc-editor.org/info/rfc7011/) specifies the IP Flow Information Export protocol. An exporting process sends data records described by templates to a collecting process. Information elements can describe addresses, ports, protocols, counters, timing, interfaces, and other observed properties. Observation domains and points provide context for where the metering occurred. Templates are essential to decoding data records and have transport and refresh considerations. Sequence numbers can help a collector detect gaps, but they do not make delivery perfectly reliable or recover every missing record. Sampling, aggregation, cache behavior, exporter resources, clock accuracy, transport, and field support affect what the collector receives and what analysts can infer. RFC 9232 discusses network telemetry frameworks and emphasizes connecting telemetry selection to operational objectives, data models, collection, and analysis. CISA has included flow monitoring such as IPFIX in official visibility guidance for network infrastructure. Flow telemetry is metadata, not full packet capture: it normally cannot show packet payload and may not distinguish permitted business activity from malicious activity without additional context. ## DSE recommendation: engineer flow collection as an evidence pipeline Start with the questions responders need to answer, then prove that the selected exporter and collector produce complete-enough evidence for those questions. - Define use cases. Prioritize questions such as unexpected external communication, lateral movement, unusual management access, data movement, denied connections, service dependency, and incident scoping. For each, identify required direction, fields, precision, history, and response time. - Choose observation points. Map internet edges, data-center boundaries, user networks, server segments, cloud gateways, VPN termination, management networks, and high-value zones. Record whether addresses are observed before or after translation and where asymmetric traffic or encrypted tunnels limit visibility. - Select fields deliberately. Document addresses, ports, protocol, start and end time, bytes, packets, interfaces, direction, TCP flags, forwarding status, application identifiers, and vendor elements actually supported. Preserve exporter, observation domain, template, site, and configuration version as provenance. - Manage templates and transport. Verify that collectors receive current templates after restart, failover, and path interruption. Monitor unknown templates, decoding errors, exporter resets, sequence gaps, transport failures, and stale sources. Use supported secure transport or protected management paths where available. - Validate time, sampling, and scale. Synchronize exporters and collectors, document clock quality, record sampling algorithms and rates, and test burst conditions. Size cache, export bandwidth, collector ingestion, storage, and queries for peak—not average—load. Treat changed sampling as a change to the evidence. - Test known traffic. Generate approved connections with known endpoints, ports, timing, direction, volume, allow or deny result, and address translation. Confirm that records arrive, decode correctly, retain the needed precision, appear in searches, and remain available through the promised retention period. - Protect and govern the data. Restrict exporter configuration and collector access, monitor pipeline changes, back up configurations, define retention, and handle flow metadata according to privacy and customer obligations. Document blind spots and teach analysts not to infer payload, user identity, or causation that records do not contain. Factual boundary: IPFIX is an extensible export protocol, so available fields and behavior vary by exporter and collector. Missing records can reflect sampling, cache pressure, transport loss, template problems, asymmetric routing, or configuration—not necessarily an attacker. Complete flow records still do not contain packet payload. Measure active exporters, expected observation-point coverage, template failures, sequence gaps, clock drift, sampling changes, ingest delay, dropped records, storage pressure, query latency, and successful known-traffic tests. Trustworthy flow telemetry is not achieved when a dashboard appears. It is achieved when responders know what was observed, what may be missing, and how to verify the pipeline before relying on it. ## Official references - IETF, [Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information](https://www.rfc-editor.org/info/rfc7011/), RFC 7011. - IETF, [Network Telemetry Framework](https://www.rfc-editor.org/rfc/rfc9232.html), RFC 9232. - CISA, [Countering Chinese State-Sponsored Actors Compromise of Networks Worldwide to Feed Global Espionage System](https://www.cisa.gov/news-events/cybersecurity-advisories/aa25-239a). ## Primary reference - Name: IETF RFC 7011: Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/info/rfc7011/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build IPFIX flow telemetry you can trust before an incident,” DSE Security, https://update.dsesecurity.com/updates/build-trustworthy-ipfix-flow-telemetry/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build separate Intune approval rings for drivers and firmware > Intune driver update policies can discover, approve, pause, and report applicable Windows drivers and firmware. Use hardware-model pilots and dated approvals, while update rings continue to govern restart and user experience. - Canonical URL: https://update.dsesecurity.com/updates/intune-driver-firmware-approval-rings/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:09:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Intune driver update policies can discover, approve, pause, and report applicable Windows drivers and firmware. Use hardware-model pilots and dated approvals, while update rings continue to govern restart and user experience. ## Potentially affected Intune-managed Microsoft Entra joined and hybrid-joined Windows devices; Windows Autopatch; Windows Update; OEM drivers and firmware; laptops, desktops, docks, displays, audio, network adapters, storage, graphics, and BIOS or UEFI components. ## DSE recommendation Create representative hardware groups, use manual approval for controlled pilots, test complete peripheral and restart workflows, advance only with measured evidence, and reconcile applicable, approved, installed, paused, failed, and superseded updates. ## Article ## Source facts: driver approval and restart behavior are different policy layers Microsoft’s [Intune driver-update documentation](https://learn.microsoft.com/en-us/intune/device-updates/windows/manage-driver-updates) says Windows driver update policies provide a dedicated place to review, approve, and deploy applicable driver and firmware updates. Manufacturers publish the updates, Windows Update evaluates hardware applicability, Windows Autopatch coordinates approved deployment, and Intune presents policy and reporting information. Administrators can use automatic or manual approval workflows. Automatic approval reduces routine review, while manual approval lets an administrator choose an available driver and an availability date. The driver policy works alongside feature, quality, and update-ring policies rather than replacing them. Microsoft explicitly notes that client-side behavior—including restart and user-notification experience—continues to be governed by standard Windows Update settings. The current prerequisites include Intune management, supported Windows Pro, Pro Education, Enterprise, or Education editions, Microsoft Entra join or hybrid join, required connectivity to Microsoft endpoints, required diagnostic data for reporting, and the applicable licensing. Microsoft’s page says Windows Enterprise LTSC is not supported by this driver-policy type and directs administrators to update-ring policy behavior instead. The Microsoft Account Sign-In Assistant service must also be enabled and running for the documented architecture. Reporting is part of the control loop, but an approval is not proof of installation on every targeted device. Applicability varies by model and configuration, devices must scan and check in, and the device still follows Windows Update behavior for the actual installation. ## DSE recommendation: stage by hardware family and operational consequence Keep driver and firmware approvals distinct from the generic operating-system rollout record. Build inventory groups that represent exact model, hardware revision where available, dock, graphics, storage, network, audio, camera, biometric, power, and BIOS or UEFI combinations. A single “IT pilot” group made of one premium laptop model cannot represent the production estate. - Discover and classify. For each offered update, record manufacturer, component, version, applicable device population, current versions, release context, known dependencies, expected restart, and the operational function it can affect. - Approve a small technical ring. Use resilient IT devices that match the target hardware. Confirm installation and recovery access, then exercise sleep, resume, restart, shutdown, charging, docking, display, wired and wireless networking, audio, camera, Bluetooth, storage, and any role-specific peripheral. - Advance to a representative business pilot. Include remote and office devices, different network conditions, commonly used docks and monitors, accessibility devices, specialized peripherals, and users who can report reproducible symptoms. - Observe before broad release. Define a minimum observation period and measurable exit criteria: installation success, restart completion, device health, hardware error rate, support contacts, performance change, and representative workflow success. - Coordinate the user experience. Review the update-ring restart, active-hours, deadline, and notification settings that will govern approved updates. Communicate when firmware may create a longer or visually different restart sequence. - Handle exceptions by version and model. Record devices on which an update is not applicable, not offered, paused, failed, superseded, or deliberately held. Give each hold an owner, evidence, and review date. Before a BIOS or firmware deployment, verify the manufacturer’s prerequisites, power requirements, disk-encryption behavior, supported rollback or recovery options, and physical or remote support path. Do not assume that a normal driver uninstall process applies to firmware. Preserve critical user data through the organization’s approved protection method and ensure the device will remain on stable power. After broad release, compare Intune reporting with real device inventory and help-desk trends. Sample devices from each major model, confirm installed versions locally where needed, and correlate failures with component and firmware combinations. Review policy ownership, role access, diagnostic-data availability, Microsoft endpoint reachability, and Windows Update policy conflicts when reporting is incomplete. The desired result is controlled hardware maintenance: Microsoft selects only applicable content, DSE chooses when approved content can progress, the user experience is predictable, and every held or failed device remains visible until disposition. ## Official references - Microsoft Learn, [Manage Windows driver updates](https://learn.microsoft.com/en-us/intune/device-updates/windows/manage-driver-updates), January 14, 2026. - Microsoft Learn, [Configure Windows driver update policies](https://learn.microsoft.com/en-us/intune/device-updates/windows/driver-updates-policy). ## Primary reference - Name: Microsoft Learn: Manage Windows driver updates - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/intune/device-updates/windows/manage-driver-updates - Source publication date: 2026-01-14 ## Citation and use Preferred citation: “Build separate Intune approval rings for drivers and firmware,” DSE Security, https://update.dsesecurity.com/updates/intune-driver-firmware-approval-rings/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Build the hurricane plan around both wind and water dependencies > Use FEMA Ready Business guidance to connect hurricane hazard assessment, mitigation, continuity, communications, and exercises. - Canonical URL: https://update.dsesecurity.com/updates/build-hurricane-plan-around-wind-water/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:18+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know Use FEMA Ready Business guidance to connect hurricane hazard assessment, mitigation, continuity, communications, and exercises. ## Potentially affected Organizations with people, facilities, suppliers, or technology exposed to tropical cyclones and their secondary effects ## DSE recommendation Plan site-specific actions for wind, rainfall, surge, tornado, utility, access, and supply impacts, then exercise decisions before hurricane season. ## Article A hurricane plan focused only on boarding windows misses the longer operational failures caused by water, power, communications, access, fuel, staffing, and supplier disruption. Preparedness should connect physical protection with decisions about people and essential services. ## Source fact: [FEMA’s Ready Business Hurricane Toolkit](https://www.ready.gov/sites/default/files/2020-04/ready_business_hurricane-toolkit.pdf) is a hazard-specific resource intended to help organizations prepare for hurricane impacts. It combines preparedness and mitigation concepts with business-continuity planning rather than treating the event solely as a building-maintenance problem. The toolkit offers a structured reference for assessing risk and developing actions before, during, and after a storm. Hurricanes can produce several interacting hazards, including damaging wind and water effects, and can disrupt the infrastructure and workforce around a facility. FEMA’s toolkit is planning guidance. It does not predict conditions for a particular storm, certify a building, replace evacuation orders, or guarantee that a mitigation measure or continuity strategy will perform under every event. ## Boundary Official forecasts, evacuation zones, storm-surge information, flood products, building codes, and emergency orders must come from the relevant current authorities. Inland locations can still experience rainfall, river flooding, tornadoes, wind, and supply interruption. Coastal sites may have storm-surge and evacuation constraints that require specialized review. Employee safety and public instructions take precedence over asset protection or an internal reopening target. ## Applicability questions - Which locations, homes, routes, suppliers, data centers, and utilities are exposed to wind, surge, rainfall, river flooding, or tornadoes? - How much lead time is needed to release staff, stop work, protect equipment, relocate records, or move inventory safely? - Which actions become unsafe once winds, flooding, traffic, or official orders reach a defined condition? - Can alternate operations function with regional power, fuel, carrier, and workforce constraints? - Who decides closure, remote work, failover, damage assessment, and reentry? ## DSE recommendation: Build a location-specific hazard and dependency map using current official data and qualified facility review. Define pre-season work separately from storm actions: roof and drainage maintenance, protected records and backups, tested generators, fuel arrangements, supplier alternatives, contact updates, and insurance documentation. Create trigger-based checklists for monitoring, staffing, shutdown, relocation, communications, and handoff. Set a last safe time for each physical action and do not ask employees to travel or remain after official guidance or site conditions make it unsafe. Preauthorize remote operations or alternate sites with capacity and access already tested. Plan damage assessment and reentry with authorities, landlords, utilities, and qualified professionals. Exercise a storm that changes track, removes the primary site and Internet, and disrupts a shared regional supplier. ## Verification and evidence Keep official hazard sources, site reviews, action owners, vendor and fuel confirmations, generator and backup tests, employee communications, trigger approvals, exercise timelines, and remediation. After an event, preserve forecasts and orders used, decisions, damage observations, and service restoration evidence. Review annually before the local season and after material facility or supplier changes, without describing the plan as protection from all hurricane loss. ## Official references - [FEMA Ready Business Hurricane Toolkit](https://www.ready.gov/sites/default/files/2020-04/ready_business_hurricane-toolkit.pdf) - [National Hurricane Center](https://www.nhc.noaa.gov/) ## Primary reference - Name: Ready Business Hurricane Toolkit - Authority: Ready.gov - URL: https://www.ready.gov/sites/default/files/2020-04/ready_business_hurricane-toolkit.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Build the hurricane plan around both wind and water dependencies,” DSE Security, https://update.dsesecurity.com/updates/build-hurricane-plan-around-wind-water/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # C-CURE 9000 and victor RCE: What CISA Update A Changes > CISA Update A revises critical guidance for Johnson Controls C-CURE 9000 and victor. Review CVE-2026-21655, adjacent-network exposure on port 8999, affected versions, fixed releases, and temporary mitigations. - Canonical URL: https://update.dsesecurity.com/updates/ccure-9000-victor-cve-2026-21655-cisa-update-a/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-12T14:47:53+00:00 - Modified: 2026-08-12T14:47:53+00:00 - Last reviewed by DSE: 2026-08-12 - Resource type: Briefing - DSE priority: Critical - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 4 minutes ## What you need to know CISA Update A revises critical guidance for Johnson Controls C-CURE 9000 and victor. Review CVE-2026-21655, adjacent-network exposure on port 8999, affected versions, fixed releases, and temporary mitigations. ## Potentially affected Organizations operating C-CURE 9000, victor Application Server, victor, or victor Web—including security operations workstations, disaster-recovery systems, test environments, and connected management networks. ## DSE recommendation Inventory exact versions and network paths, restrict port 8999 and management access, expedite vendor-supported upgrades, review relevant logs, and functionally test access-control and video operations after the change. ## Article 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. ## Source fact: what CISA Update A covers [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. Johnson 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. CVE-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. ## Affected versions and vendor-directed updates FindingAffected productVendor-directed update CVE-2026-21655C-CURE 9000 3.10.1 and earlierUpgrade to 3.20 or later CVE-2026-21655victor Application Server 4.10 and earlierUpgrade to 4.20 or later CVE-2026-21655victor 7.0 and earlierUpgrade to 8.0 or later CVE-2026-21653victor Web versions before 7.0Upgrade to 7.0 or later CVE-2026-34496victor Web 7.1 and earlierUse 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. ## Why “adjacent network” still deserves urgency The 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. Neither 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. ## Vendor-provided temporary mitigations For 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. ## DSE recommendation: prioritized response The following steps are DSE recommendations based on the official advisories. - 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. - 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. - Expedite vendor-supported updates. Prioritize the RCE path. For CVE-2026-34496, verify the precise fixed victor Web build with the vendor or integrator. - 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. - 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. - Document closure. Record fixed versions, containment changes, functional-test results, residual exceptions, and the date the official advisories were rechecked. ## Official reference - [CISA ICSA-26-204-01 Update A](https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01), updated August 11, 2026 - [Johnson Controls JCI-PSA-2026-13 v2](https://tyco.widen.net/s/9xktps8hl6/jci-psa-2026-13-v2), updated August 6, 2026 - [Johnson Controls JCI-PSA-2026-07](https://tyco.widen.net/s/n5vdddqbcs/jci-psa-2026-07) - [Johnson Controls JCI-PSA-2026-16](https://tyco.widen.net/s/s9cchrkg87/jci-psa-2026-16) - [Johnson Controls Product Security Advisory register](https://www.johnsoncontrols.com/trust-center/cybersecurity/security-advisories) Source review completed August 12, 2026. Recheck the official advisories before changing production systems. ## Primary reference - Name: CISA ICSA-26-204-01 Update A - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01 - Source publication date: 2026-08-11 ## Citation and use Preferred citation: “C-CURE 9000 and victor RCE: What CISA Update A Changes,” DSE Security, https://update.dsesecurity.com/updates/ccure-9000-victor-cve-2026-21655-cisa-update-a/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Cable verification, qualification, and certification answer different questions > Verification checks basic connectivity, qualification evaluates support for a network application, and certification compares measured cabling performance with a selected standard. - Canonical URL: https://update.dsesecurity.com/updates/cable-verification-qualification-certification/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:04:46+00:00 - Modified: 2026-07-19T19:04:46+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Explainer - DSE priority: Information - Topics: Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Verification checks basic connectivity, qualification evaluates support for a network application, and certification compares measured cabling performance with a selected standard. ## Potentially affected Teams installing, accepting, documenting, expanding, or troubleshooting copper or fiber links for networks and connected security systems. ## DSE recommendation State the question and required deliverable before testing, then use the appropriate instrument and preserve the result with the link record. ## Article ## Start with the question, not the tester Fluke Networks separates field cable testing into verification, qualification, and certification. The terms describe different questions and different levels of evidence. Using them interchangeably can produce an acceptance record that sounds stronger than the work actually performed. This explanation does not certify any cable, installation, tester, or technician. Contract requirements, applicable standards, manufacturer warranty conditions, test limits, and required qualifications must be confirmed for the specific project. ## Verification: is it connected as expected? Verification is the basic troubleshooting layer. On copper links it commonly checks continuity and wire map, helping identify opens, shorts, reversals, split pairs, or the location of a fault when the instrument supports distance measurement. Tone and probe functions may help identify a cable. On fiber, visual checks can assist with continuity and polarity within their limitations. A verification result is useful after termination, during a move or change, and when a device will not link. It does not by itself establish that a cable supports a target network technology or complies with a cabling standard. ## Qualification: can it support the intended application? Qualification adds an assessment of whether an installed link can support a specified network application or signaling rate. It is often useful for existing, incompletely documented cabling when a team needs to decide whether a planned device or network upgrade is reasonable. Qualification can also help separate a physical cabling limitation from an active-network problem. The result is tied to the method, limits, configuration, and application evaluated by the instrument. It should not be generalized to every protocol, power requirement, or future upgrade, and it is not a standards-compliance certification. ## Certification: does the link meet the selected standard and limit? Certification instruments make defined measurements across required ranges and compare the results with the selected cabling standard and link configuration. The output is typically a documented pass or fail for that selected limit. Permanent-link and channel configurations are different test contexts, so the test setup and adapters matter. Certification scope should be established before work begins. Record the cabling category or class, fiber type where applicable, link model, standard and limit, required result format, labeling convention, and any project or manufacturer requirements. Do not infer a manufacturer warranty or system compatibility solely from the word “certified.” ## Preserve evidence that can be used later - Assign a unique identifier that matches both ends, drawings, and patching records. - Record the test type, instrument, selected limit, configuration, date, and operator. - Keep the native result file or approved report rather than only a photo of a pass screen. - Document repairs, retests, exceptions, and the final accepted result. - For powered devices, separately validate the supported power and active-network design. During troubleshooting, use the least complex test that answers the immediate question, then escalate when the evidence does not match the required assurance. Clear terminology keeps owners from accepting a wire-map check when they requested application support, or an application test when the project requires standards-based results. ## Primary reference - Name: Fluke Networks — Verification, Qualification, Certification: Which Do I Need? - Authority: Fluke Networks - URL: https://www.flukenetworks.com/blog/cabling-chronicles/verification-qualification-certification-which-do-i-need - Source publication date: 2019-01-23 ## Citation and use Preferred citation: “Cable verification, qualification, and certification answer different questions,” DSE Security, https://update.dsesecurity.com/updates/cable-verification-qualification-certification/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Calculate GPO scope before linking or filtering policy > Use Group Policy scope in Windows to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/calculate-gpo-scope-before-linking-or-filtering/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:50+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Group Policy scope in Windows to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Group Policy scope in Windows ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Calculate GPO scope before linking or filtering policy. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Group Policy scope in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-scope) from Microsoft supports the following bounded statements: - GPO scope begins with links to Active Directory sites, domains, or organizational units. The research record locates this support at Opening overview. - Processing order, filtering, and link options change which policy settings apply to a user or computer. The research record locates this support at Opening overview. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles and the conditions the source actually describes. ## What the source does not establish Model resultant scope for representative principals before production linking. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Opening overview. Favor directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Group Policy scope in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-scope) — Microsoft ## Primary reference - Name: Group Policy scope in Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-scope - Source publication date: 2025-06-13 ## Citation and use Preferred citation: “Calculate GPO scope before linking or filtering policy,” DSE Security, https://update.dsesecurity.com/updates/calculate-gpo-scope-before-linking-or-filtering/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Calculate the cluster-wide live-migration bandwidth limit from all relevant adapters > Which bandwidth total underlies a cluster-wide SMB live-migration percentage? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-102-calculate-the-cluster-wide-live-migration-bandwidth-limit-from-all-relevant/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:29+00:00 - Modified: 2026-09-08T18:23:26+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Which bandwidth total underlies a cluster-wide SMB live-migration percentage? ## Potentially affected Administrators setting SMB live-migration limits on physically hosted Windows Server or Azure Local cluster nodes. ## DSE recommendation Write the proposed percentage and its bandwidth calculation in the change record. ## Article ## Source facts Microsoft requires calculating the bandwidth available across the physical adapters used by the cluster before choosing the SMB bandwidth percentage. That percentage uses the cluster’s total bandwidth even when live migration is assigned a particular cluster network. Cluster nodes must consistently use SMB for live migration to use this control. The cluster parameters distribute the chosen values to a newly added node automatically. These cluster-wide limits work on physically hosted cluster nodes, not on nodes running as virtual machines. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/failover-clustering/configure-live-migration-smb-bandwidth). ## Applicability Inventory the adapters, speeds, cluster networks, and configured live-migration transport. Review how the total was calculated and distinguish this rate-limit decision from deciding which networks may carry migrations. ## DSE recommendation Write the proposed percentage and its bandwidth calculation in the change record. Ask workload and network owners to agree on the capacity reserved for concurrent activity. Preserve the original cluster values, then choose a representative migration workload and a measurement window before changing the limit. ## Verification Perform approved live migrations while measuring migration traffic and application behavior. Compare the observed usage with the intended reservation and document the number of concurrent migrations. Inspect the inherited settings when adding a test node, and revisit the calculation after a material change in adapter capacity. ## Official references [Microsoft Learn: Control Live Migration SMB Bandwidth Control Cluster-wide in Windows Server and Azure Local](https://learn.microsoft.com/en-us/windows-server/failover-clustering/configure-live-migration-smb-bandwidth). Source reviewed September 8, 2026. ## Primary reference - Name: Control Live Migration SMB Bandwidth Control Cluster-wide in Windows Server and Azure Local - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/configure-live-migration-smb-bandwidth - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Calculate the cluster-wide live-migration bandwidth limit from all relevant adapters,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-102-calculate-the-cluster-wide-live-migration-bandwidth-limit-from-all-relevant/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Calculate worst-case toxic and flammable releases using the rule's scenario constraints > Use 40 CFR 68.25 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/calculate-worst-case-toxic-and-flammable-releases-using-the-rule-s-scenario-constraints/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:17+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.25 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.25 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Calculate worst-case toxic and flammable releases using the rule’s scenario constraints. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.25 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.25) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, Program 2 and 3 processes must report the flammable worst-case release scenario producing the greatest endpoint distance under section 68.22. The research record locates this support at 40 CFR 68.25(a)(2)(ii), read with 40 CFR 68.25(a)(2) (eCFR anchor p-68.25(a)(2)(ii)). - Under 40 CFR 68, a Program 1 process must report one worst-case release scenario. The research record locates this support at 40 CFR 68.25(a)(1), read with 40 CFR 68.25(a) (eCFR anchor p-68.25(a)(1)). The source support ends with the statements listed above. Use them to examine critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 40 CFR 68.25(a)(2)(ii), read with 40 CFR 68.25(a)(2) (eCFR anchor p-68.25(a)(2)(ii)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.25(a)(1), read with 40 CFR 68.25(a) (eCFR anchor p-68.25(a)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from 40 CFR 68.25(a)(2)(ii), read with 40 CFR 68.25(a)(2) (eCFR anchor p-68.25(a)(2)(ii)); 40 CFR 68.25(a)(1), read with 40 CFR 68.25(a) (eCFR anchor p-68.25(a)(1)) to the observed environment. Useful domain evidence includes facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [40 CFR 68.25 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.25) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.25 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.25 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Calculate worst-case toxic and flammable releases using the rule's scenario constraints,” DSE Security, https://update.dsesecurity.com/updates/calculate-worst-case-toxic-and-flammable-releases-using-the-rule-s-scenario-constraints/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Camera certificate lifecycle management: HTTPS and 802.1X are different jobs > Axis documents distinct certificate roles for HTTPS server identity and 802.1X network authentication. Each needs ownership, expiry monitoring, renewal, and recovery testing. - Canonical URL: https://update.dsesecurity.com/updates/axis-camera-certificate-lifecycle-https-8021x/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:39+00:00 - Modified: 2026-07-19T21:28:39+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure, Video Surveillance - Reading time: 2 minutes ## What you need to know Axis documents distinct certificate roles for HTTPS server identity and 802.1X network authentication. Each needs ownership, expiry monitoring, renewal, and recovery testing. ## Potentially affected Axis device estates using HTTPS, IEEE 802.1X, AXIS Device Manager, VMS certificate validation, RADIUS, a private or enterprise CA, or automated certificate renewal. ## DSE recommendation Separate HTTPS and 802.1X certificate inventories, assign trust and renewal ownership, and stage certificate changes before they can interrupt video or network access. ## Article ## Two certificate purposes Source fact: The AXIS Device Manager Security Guide describes certificate lifecycle management as the continuing work of issuing, installing, inspecting, remediating, monitoring, and renewing certificates. AXIS Device Manager can manage HTTPS and IEEE 802.1X certificates, monitor expiration, and renew certificates before they expire. The roles are different. For HTTPS, a camera presents a server certificate and the connecting client validates it. Axis notes that in a common VMS architecture, the VMS server accesses cameras directly while operator clients receive live and recorded video through the VMS. In that scenario, the VMS trust store is central, though maintenance clients that connect directly also need the appropriate trust. For 802.1X, the camera uses a client certificate to authenticate itself to a RADIUS service before network access is allowed. Axis explains that an 802.1X environment typically requires managed switches, RADIUS infrastructure, a certificate authority, and staff to maintain and monitor it. The guide describes separate workflows for HTTPS server certificates and 802.1X client and authentication certificates. ## Architecture determines the CA choice Axis discusses using AXIS Device Manager as a private CA for private camera resources and using an enterprise-PKI intermediate CA for 802.1X. That recommendation belongs to the architecture described in the guide. It should not be generalized to public services, every enterprise PKI, or a design in which many clients connect directly to cameras. An expired, untrusted, incorrectly named, or unavailable certificate can break management, recording, or network admission. Renewal is therefore a production change. The source does not authorize replacing certificates without validating the VMS, RADIUS, switch, device, time, and recovery dependencies. ## DSE lifecycle checklist DSE recommendation: This is DSE operational synthesis for Axis environments, not a universal PKI design. - Inventory every certificate by device, purpose, issuer, subject, serial number, expiry, key location, and renewal owner. - Separate HTTPS server identity from 802.1X client authentication and any MQTT or syslog certificates. - Map which VMS, browser, management client, RADIUS server, and switch trusts which CA. - Protect CA private keys and backups according to the organization’s approved key-management process. - Set warnings early enough to investigate and stage renewal before expiration. - Test representative certificate issuance, installation, trust, 802.1X admission, VMS recording, and direct maintenance access. - Test expired, revoked, untrusted, or failed-renewal behavior and document an authorized recovery path. - Review the inventory after device replacement, CA change, network redesign, or VMS migration. ## Official references - [AXIS Device Manager Security Guide](https://help.axis.com/en-us/adm-security-guide) — certificate lifecycle, HTTPS, 802.1X, CA, RADIUS, and trust guidance. - [AXIS OS Knowledge Base](https://help.axis.com/en-US/axis-os-knowledge-base) — current device certificate behavior and version-specific administration context. ## Primary reference - Name: Axis Communications — AXIS Device Manager Security Guide - Authority: Axis Communications - URL: https://help.axis.com/en-us/adm-security-guide - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Camera certificate lifecycle management: HTTPS and 802.1X are different jobs,” DSE Security, https://update.dsesecurity.com/updates/axis-camera-certificate-lifecycle-https-8021x/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Canonicalize IPv6 text before comparing or logging addresses > Use RFC 5952 — A Recommendation for IPv6 Address Text Representation to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/canonicalize-ipv6-text-before-comparing-or-logging-addresses/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:37+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 5952 — A Recommendation for IPv6 Address Text Representation to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 5952 — A Recommendation for IPv6 Address Text Representation ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Canonicalize IPv6 text before comparing or logging addresses. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 5952 — A Recommendation for IPv6 Address Text Representation](https://www.rfc-editor.org/rfc/rfc5952.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Canonical IPv6 text suppresses leading zeroes in each 16-bit field while representing a single all-zero field as 0. The research record locates this support at Section 4.1 (Handling Leading Zeros in a 16-Bit Field). - The double-colon form compresses the longest eligible zero run, never a single zero field, and selects the leftmost run when equal-length runs tie. The research record locates this support at Sections 4.2.1-4.2.3 (:: Usage). - Hexadecimal letters in the canonical representation must be lowercase. The research record locates this support at Section 4.3 (Lowercase). Keep the evidence boundary at these traced claims. They support a review of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 4.1 (Handling Leading Zeros in a 16-Bit Field), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 4.2.1-4.2.3 (:: Usage), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4.3 (Lowercase), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and sanitize protected material before retention. ## Verification and evidence Keep the source locations Section 4.1 (Handling Leading Zeros in a 16-Bit Field); Sections 4.2.1-4.2.3 (:: Usage); Section 4.3 (Lowercase) adjacent to the sanitized artifacts used for comparison. Prefer configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 5952 — A Recommendation for IPv6 Address Text Representation](https://www.rfc-editor.org/rfc/rfc5952.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 5952 — A Recommendation for IPv6 Address Text Representation - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5952.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Canonicalize IPv6 text before comparing or logging addresses,” DSE Security, https://update.dsesecurity.com/updates/canonicalize-ipv6-text-before-comparing-or-logging-addresses/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Cap resolver retries that amplify failures into unnecessary query load > Use RFC 4697 — Observed DNS Resolution Misbehavior to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/cap-resolver-retries-that-amplify-failures-into-unnecessary-query-load/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:46+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4697 — Observed DNS Resolution Misbehavior to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4697 — Observed DNS Resolution Misbehavior ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Cap resolver retries that amplify failures into unnecessary query load. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4697 — Observed DNS Resolution Misbehavior](https://www.rfc-editor.org/rfc/rfc4697.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An iterative resolver must not ask a parent server for the NS RRset of a zone whose listed servers are all nonresponsive. The research record locates this support at Section 2.1.1 (Recommendation). - A resolver that caches lame servers must key each entry by zone name, class, and server IP address and suppress queries for a configurable interval. The research record locates this support at Section 2.2.1 (Recommendation), lame-server cache key. - If every server for a zone is marked lame, the resolver should temporarily ignore that status and retry one or more servers. The research record locates this support at Section 2.2.1 (Recommendation), all-servers-lame exception. The source support ends with the statements listed above. Use them to examine authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2.1.1 (Recommendation), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.2.1 (Recommendation), lame-server cache key, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2.2.1 (Recommendation), all-servers-lame exception, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from Section 2.1.1 (Recommendation); Section 2.2.1 (Recommendation), lame-server cache key; Section 2.2.1 (Recommendation), all-servers-lame exception through zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 4697 — Observed DNS Resolution Misbehavior](https://www.rfc-editor.org/rfc/rfc4697.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4697 — Observed DNS Resolution Misbehavior - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4697.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Cap resolver retries that amplify failures into unnecessary query load,” DSE Security, https://update.dsesecurity.com/updates/cap-resolver-retries-that-amplify-failures-into-unnecessary-query-load/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Capture AD Administrative Center actions as reusable PowerShell > Use Use the Active Directory Administrative Center Windows PowerShell History Viewer in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/capture-adac-actions-as-reusable-powershell/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:17+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Use the Active Directory Administrative Center Windows PowerShell History Viewer in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Use the Active Directory Administrative Center Windows PowerShell History Viewer in Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Capture AD Administrative Center actions as reusable PowerShell. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Use the Active Directory Administrative Center Windows PowerShell History Viewer in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/use-active-directory-administrative-center-powershell-history) from Microsoft supports the following bounded statements: - AD Administrative Center records the PowerShell cmdlets it runs together with arguments and values. The research record locates this support at Opening overview. - Administrators can copy and filter the history for learning, modification, and reuse. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Recorded commands still require review, least privilege, and testing before automation. No current deployment state or change approval follows from the source alone. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Use the Active Directory Administrative Center Windows PowerShell History Viewer in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/use-active-directory-administrative-center-powershell-history) — Microsoft ## Primary reference - Name: Use the Active Directory Administrative Center Windows PowerShell History Viewer in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/use-active-directory-administrative-center-powershell-history - Source publication date: 2024-09-05 ## Citation and use Preferred citation: “Capture AD Administrative Center actions as reusable PowerShell,” DSE Security, https://update.dsesecurity.com/updates/capture-adac-actions-as-reusable-powershell/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Capture domain-controller system state with two supported methods > Use AD Forest Recovery - Backing up the System State data to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/capture-dc-system-state-with-supported-methods/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:34+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use AD Forest Recovery - Backing up the System State data to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of AD Forest Recovery - Backing up the System State data ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Capture domain-controller system state with two supported methods. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [AD Forest Recovery – Backing up the System State data](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-backing-up-system-state) from Microsoft supports the following bounded statements: - The forest-recovery procedure creates domain-controller system-state backups with Windows Server Backup or wbadmin.exe. The research record locates this support at Opening overview. - Microsoft documents separate GUI and command-line procedures for the same recovery input. The research record locates this support at Sections: Windows Server Backup; Wbadmin.exe. Keep the evidence boundary at these traced claims. They support a review of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish A completed job is not sufficient evidence; verify backup integrity, retention, and restore usability. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: Windows Server Backup; Wbadmin.exe, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Sections: Windows Server Backup; Wbadmin.exe through backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [AD Forest Recovery – Backing up the System State data](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-backing-up-system-state) — Microsoft ## Primary reference - Name: AD Forest Recovery - Backing up the System State data - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-backing-up-system-state - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Capture domain-controller system state with two supported methods,” DSE Security, https://update.dsesecurity.com/updates/capture-dc-system-state-with-supported-methods/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Capture ETW evidence for failing LDAP connections > Use Using ETW to troubleshoot LDAP connections to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/capture-etw-evidence-for-failing-ldap-connections/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:16+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Using ETW to troubleshoot LDAP connections to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Using ETW to troubleshoot LDAP connections ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Capture ETW evidence for failing LDAP connections. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Using ETW to troubleshoot LDAP connections](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/troubleshoot-ldap-using-etw) from Microsoft supports the following bounded statements: - ETW can trace LDAP communications between Windows clients and LDAP servers, including AD DS domain controllers. The research record locates this support at Opening overview. - Microsoft documents how to start, stop, and scope the trace with trace flags. The research record locates this support at Sections: turn on ETW and start a trace; end a tracing session; Values for trace flags. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps only where the source and recorded environment align. ## What the source does not establish Collect only the duration and providers required for diagnosis, then secure or delete trace data under policy. A correct source interpretation can still be inapplicable to a particular design. Confirm offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: turn on ETW and start a trace; end a tracing session; Values for trace flags, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from Opening overview; Sections: turn on ETW and start a trace; end a tracing session; Values for trace flags to the observed environment. Useful domain evidence includes backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Using ETW to troubleshoot LDAP connections](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/troubleshoot-ldap-using-etw) — Microsoft ## Primary reference - Name: Using ETW to troubleshoot LDAP connections - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/troubleshoot-ldap-using-etw - Source publication date: 2019-11-22 ## Citation and use Preferred citation: “Capture ETW evidence for failing LDAP connections,” DSE Security, https://update.dsesecurity.com/updates/capture-etw-evidence-for-failing-ldap-connections/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Capture Health Service metrics as timed snapshots, not historical trends > What context should accompany a Storage Spaces Direct Health Service performance report? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-153-capture-health-service-metrics-as-timed-snapshots-not-historical-trends/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:38+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What context should accompany a Storage Spaces Direct Health Service performance report? ## Potentially affected Use this review when collecting cluster metrics for an investigation or capacity discussion. ## DSE recommendation Record timestamps and cluster membership with each captured report. ## Article ## Source facts Microsoft’s Health Service reports provide live capacity and performance metrics aggregated across cluster nodes, with membership detection. The values represent the point in time at which they are collected. The documented object model distinguishes the storage subsystem, nodes, data volumes, and Health Service. Its streaming example receives successive metric samples and handles the end of the stream separately. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/failover-clustering/health-service-reports). ## Applicability Use this review when collecting cluster metrics for an investigation or capacity discussion. Identify the cluster, requested objects, sampling time, and workload conditions. Decide whether a single observation or a retained sequence is needed. ## DSE recommendation Record timestamps and cluster membership with each captured report. Select a consistent observation interval when the question concerns change over time, and arrange an approved destination for retained samples. Ask the storage owner to define the workload context needed to interpret the values. Keep a missing sample distinguishable from a measured low value in the record. ## Verification Compare repeated observations collected under the agreed method and verify that they refer to the intended cluster and volumes. Check the handling of an interrupted collection session rather than assuming continuous coverage. Document gaps, membership changes, and workload differences alongside any conclusion. Preserve the original samples so a later reviewer can separate observations from interpretation. ## Official references [Microsoft Learn: Health Service reports](https://learn.microsoft.com/en-us/windows-server/failover-clustering/health-service-reports). Source reviewed September 8, 2026. ## Primary reference - Name: Health Service reports - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/health-service-reports - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Capture Health Service metrics as timed snapshots, not historical trends,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-153-capture-health-service-metrics-as-timed-snapshots-not-historical-trends/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Carry RMP compliance into air-permit terms and certification > Use 40 CFR 68.215 - Permit content and authority requirements to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/carry-rmp-compliance-into-air-permit-terms-and-certification/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:50+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.215 - Permit content and authority requirements to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.215 - Permit content and authority requirements ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Carry RMP compliance into air-permit terms and certification. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.215 – Permit content and authority requirements](https://www.ecfr.gov/current/title-40/section-68.215) from Environmental Protection Agency via eCFR supports the following bounded statements: - For a stationary source subject to part 68 and part 70 or 71, the air permit must list part 68 as applicable and require either a compliance schedule or certification of part 68 compliance, including RMP registration and submission. The research record locates this support at 40 CFR 68.215(a)(1), 68.215(a)(2)(i), and 68.215(a)(2)(ii), read with 40 CFR 68.215(a) (eCFR anchors p-68.215(a)(1), p-68.215(a)(2)(i), and p-68.215(a)(2)(ii)). - A pre-deadline part 70 or 71 permit lacking those conditions must be revised or reopened under the applicable permit procedures. The research record locates this support at 40 CFR 68.215(c) (eCFR anchor p-68.215(c)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths and the conditions the source actually describes. ## What the source does not establish This applies only to stationary sources jointly subject to 40 CFR parts 68 and 70 or 71. The permitting authority determines permit action, completeness, inspection, and enforcement. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.215(a)(1), 68.215(a)(2)(i), and 68.215(a)(2)(ii), read with 40 CFR 68.215(a) (eCFR anchors p-68.215(a)(1), p-68.215(a)(2)(i), and p-68.215(a)(2)(ii)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.215(c) (eCFR anchor p-68.215(c)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations 40 CFR 68.215(a)(1), 68.215(a)(2)(i), and 68.215(a)(2)(ii), read with 40 CFR 68.215(a) (eCFR anchors p-68.215(a)(1), p-68.215(a)(2)(i), and p-68.215(a)(2)(ii)); 40 CFR 68.215(c) (eCFR anchor p-68.215(c)) adjacent to the sanitized artifacts used for comparison. Prefer facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [40 CFR 68.215 – Permit content and authority requirements](https://www.ecfr.gov/current/title-40/section-68.215) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.215 - Permit content and authority requirements - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.215 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Carry RMP compliance into air-permit terms and certification,” DSE Security, https://update.dsesecurity.com/updates/carry-rmp-compliance-into-air-permit-terms-and-certification/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Categorize security impact before choosing controls > Security impact is not a single generic rating. Evaluate confidentiality, integrity, and availability separately, document the consequences of loss, then use the high-water mark without losing the underlying distinctions. - Canonical URL: https://update.dsesecurity.com/updates/categorize-security-impact-before-choosing-controls/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:34:00+00:00 - Modified: 2026-08-11T15:22:46+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Security impact is not a single generic rating. Evaluate confidentiality, integrity, and availability separately, document the consequences of loss, then use the high-water mark without losing the underlying distinctions. ## Potentially affected Risk assessments, system inventories, data owners, business impact analyses, control selection, recovery priorities, procurement decisions, security reviews, and exception approvals. ## DSE recommendation Select a bounded service, identify its information types, assess loss of confidentiality, integrity, and availability with business owners, record assumptions, and approve both the component ratings and overall category. ## Article ## Source facts: security impact has three independent objectives Federal Information Processing Standard 199 provides a method for categorizing federal information and information systems by the potential impact of losing confidentiality, integrity, or availability. Confidentiality concerns unauthorized disclosure. Integrity concerns unauthorized modification or destruction, including authenticity and non-repudiation. Availability concerns timely and reliable access to and use of information. For each objective, FIPS 199 defines low, moderate, and high potential impact. Low means the loss could be expected to have a limited adverse effect; moderate means a serious adverse effect; and high means a severe or catastrophic adverse effect on operations, assets, or individuals. The standard describes consequences such as degraded mission capability, significant financial loss, serious harm, and—at the high level—major damage or loss of life. An information type receives a three-part security category. A system that processes several information types takes the high-water mark for each objective across those types. Its overall impact level is then the highest value among confidentiality, integrity, and availability. That roll-up is useful for baseline decisions, but it does not erase the three component values or the reasoning behind them. ## DSE recommendation: categorize consequences, not technology labels Choose a bounded service and identify the business owner, information owner, security owner, and continuity owner. Describe the service in plain language, including who relies on it, what decisions it supports, what external promises apply, and which manual or alternate processes exist. Avoid assigning impact from a server name, vendor tier, or inherited label alone. List distinct information types and transactions. Then ask three separate loss questions. What happens if the information is disclosed to an unauthorized party? What happens if it is changed, fabricated, deleted, delayed, or presented without trustworthy origin? What happens if authorized people cannot reach it when required? Consider harm to people, operations, contractual duties, finances, legal obligations, safety, reputation, and downstream partners. ## DSE recommendation: preserve rationale and context - Record the scenario. A rating without a loss scenario is difficult to review. State the assumed duration, scale, population, timing, and whether other safeguards or alternatives remain available. - Separate ordinary and peak periods. Availability consequences may change during payroll, elections, emergency operations, seasonal production, or a regulatory deadline. Integrity consequences may rise when data drives physical or financial action. - Follow aggregation. Individually modest records can create greater harm when assembled. Document volume and whether correlation reveals sensitive behavior or produces a high-value decision set. - Examine dependencies. A low-profile component may carry high-impact authentication, routing, time, or safety data for another service. Include inherited consequences rather than rating it in isolation. - Approve adjustments. If the organization raises or lowers a provisional category, identify the authority, justification, compensating facts, and next review date. ## DSE recommendation: use the category without letting it become permanent Translate the result into control selection, assessment depth, supplier requirements, logging, recovery priority, exercise frequency, separation of duties, and exception authority. Keep the component ratings visible: a high overall category driven by availability does not automatically explain confidentiality handling, and a system dominated by integrity risk requires evidence that restored information is trustworthy, not merely reachable. Review categorization when information types, user populations, integrations, operating locations, automated decisions, legal obligations, or tolerable downtime change. Link the category to the inventory and change process so a new data flow triggers review. The deliverable should show the loss scenarios, participants, component ratings, high-water calculation, unresolved assumptions, approval, and date. Require the approving owner to confirm that each consequence statement still reflects the current service and its dependent operations. That record makes later controls and risk decisions traceable. ## Official references - National Institute of Standards and Technology, [FIPS Publication 199: Standards for Security Categorization of Federal Information and Information Systems](https://csrc.nist.gov/pubs/fips/199/final), February 2004; reviewed August 11, 2026. ## Primary reference - Name: NIST FIPS 199: Standards for Security Categorization - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/fips/199/final - Source publication date: 2004-02-01 ## Citation and use Preferred citation: “Categorize security impact before choosing controls,” DSE Security, https://update.dsesecurity.com/updates/categorize-security-impact-before-choosing-controls/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Centralize multi-forest GPO administration in GPMC > Use Group Policy Management Console in Windows to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/centralize-multi-forest-gpo-administration-in-gpmc/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:46+00:00 - Modified: 2026-08-27T12:56:26+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Group Policy Management Console in Windows to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Group Policy Management Console in Windows ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Centralize multi-forest GPO administration in GPMC. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Group Policy Management Console in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-management-console) from Microsoft supports the following bounded statements: - GPMC provides unified Group Policy management across multiple forests. The research record locates this support at Opening overview. - It manages GPOs, WMI filters, and Group Policy permissions and exposes scriptable interfaces. The research record locates this support at Opening overview. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles and the conditions the source actually describes. ## What the source does not establish Console reach does not imply cross-forest authority; preserve delegated permissions and change control. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Opening overview. Favor directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Group Policy Management Console in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-management-console) — Microsoft ## Primary reference - Name: Group Policy Management Console in Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-management-console - Source publication date: 2025-05-14 ## Citation and use Preferred citation: “Centralize multi-forest GPO administration in GPMC,” DSE Security, https://update.dsesecurity.com/updates/centralize-multi-forest-gpo-administration-in-gpmc/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Centralize TPM command and lockout controls with Group Policy > Use TPM Group Policy settings to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/centralize-tpm-command-and-lockout-controls-with-gpo/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:54+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Use TPM Group Policy settings to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of TPM Group Policy settings ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Centralize TPM command and lockout controls with Group Policy. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [TPM Group Policy settings](https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/trusted-platform-module-services-group-policy-settings) from Microsoft supports the following bounded statements: - Windows exposes TPM Services policy under Computer Configuration administrative templates. The research record locates this support at Opening overview. - The policies control blocked TPM commands, owner-authorization availability, and standard-user lockout duration and thresholds. The research record locates this support at Sections: blocked commands; owner authorization; lockout settings. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows only where the source and recorded environment align. ## What the source does not establish Test command-block policies against firmware, BitLocker, and management workflows before broad enforcement. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: blocked commands; owner authorization; lockout settings, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations and sanitize protected material before retention. ## Verification and evidence Keep the source locations Opening overview; Sections: blocked commands; owner authorization; lockout settings adjacent to the sanitized artifacts used for comparison. Prefer policy and feature state, security events, test detections, administrative assignments, exception approvals, and response tickets, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [TPM Group Policy settings](https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/trusted-platform-module-services-group-policy-settings) — Microsoft ## Primary reference - Name: TPM Group Policy settings - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/trusted-platform-module-services-group-policy-settings - Source publication date: 2025-08-15 ## Citation and use Preferred citation: “Centralize TPM command and lockout controls with Group Policy,” DSE Security, https://update.dsesecurity.com/updates/centralize-tpm-command-and-lockout-controls-with-gpo/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Challenge suspicious TCP resets, SYNs, and data before aborting a connection > Use RFC 5961 — Improving TCP's Robustness to Blind In-Window Attacks to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/challenge-suspicious-tcp-resets-syns-and-data-before-aborting-a-connection/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:36+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 5961 — Improving TCP's Robustness to Blind In-Window Attacks to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 5961 — Improving TCP's Robustness to Blind In-Window Attacks ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Challenge suspicious TCP resets, SYNs, and data before aborting a connection. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 5961 — Improving TCP’s Robustness to Blind In-Window Attacks](https://www.rfc-editor.org/rfc/rfc5961.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - In a synchronized state, TCP resets only on an RST whose sequence exactly equals RCV.NXT; it discards an out-of-window RST and challenges an in-window nonmatching RST with an ACK before dropping it. The research record locates this support at Section 3.2 (Mitigation). - A SYN received in a synchronized state triggers a challenge ACK and is dropped; the connection terminates only after a valid reset confirms the peer closed it. The research record locates this support at Section 4.2 (Mitigation). - The optional data-injection mitigation accepts an ACK only from SND.UNA minus MAX.SND.WND through SND.NXT and challenges then discards a segment outside that range. The research record locates this support at Section 5.2 (Mitigation). Keep the evidence boundary at these traced claims. They support a review of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 3.2 (Mitigation), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4.2 (Mitigation), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5.2 (Mitigation), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations Section 3.2 (Mitigation); Section 4.2 (Mitigation); Section 5.2 (Mitigation) adjacent to the sanitized artifacts used for comparison. Prefer configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 5961 — Improving TCP’s Robustness to Blind In-Window Attacks](https://www.rfc-editor.org/rfc/rfc5961.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 5961 — Improving TCP's Robustness to Blind In-Window Attacks - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5961.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Challenge suspicious TCP resets, SYNs, and data before aborting a connection,” DSE Security, https://update.dsesecurity.com/updates/challenge-suspicious-tcp-resets-syns-and-data-before-aborting-a-connection/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Change Windows DNS zones through an explicit storage and replication plan > Use Manage DNS zones using DNS server in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/change-windows-dns-zones-through-an-explicit-storage-and-replication-plan/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:38+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Manage DNS zones using DNS server in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Manage DNS zones using DNS server in Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Change Windows DNS zones through an explicit storage and replication plan. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Manage DNS zones using DNS server in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-dns-zones) from Microsoft supports the following bounded statements: - Windows Server provides DNS Manager and PowerShell procedures to create and manage DNS zones. The research record locates this support at Article introduction. - The page provides DNS Manager and PowerShell procedures to create primary, secondary, stub, and reverse zones and to configure zone transfers and delegation. The research record locates this support at Create a DNS zone; Primary zones; Secondary zones; Stub zones; Reverse lookup zones; Zone transfers; Zone delegation. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The procedures do not select a safe zone type, replication scope, transfer policy, or maintenance window for a specific environment. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Article introduction, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Create a DNS zone; Primary zones; Secondary zones; Stub zones; Reverse lookup zones; Zone transfers; Zone delegation, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Article introduction; Create a DNS zone; Primary zones; Secondary zones; Stub zones; Reverse lookup zones; Zone transfers; Zone delegation. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Manage DNS zones using DNS server in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-dns-zones) — Microsoft ## Primary reference - Name: Manage DNS zones using DNS server in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-dns-zones - Source publication date: 2025-01-02 ## Citation and use Preferred citation: “Change Windows DNS zones through an explicit storage and replication plan,” DSE Security, https://update.dsesecurity.com/updates/change-windows-dns-zones-through-an-explicit-storage-and-replication-plan/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check both ends of a Hyper-V integration service > Why can an integration feature remain unavailable when its host setting is enabled? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-239-check-both-ends-of-a-hyper-v-integration-service/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:12+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know Why can an integration feature remain unavailable when its host setting is enabled? ## Potentially affected Operators managing integration services in supported Windows or Linux Hyper-V guests. ## DSE recommendation Ask the workload owner which integration functions the guest requires. ## Article ## Source facts Hyper-V integration services coordinate functions between the host and guest operating systems; the individual services can be controlled separately. For a service to function fully, its host-side setting must be enabled and the corresponding service must run inside the guest. Microsoft recommends controlling integration services from Hyper-V. Outdated guest integration services can prevent features from working correctly; Microsoft documents checking their Windows version from inside the guest. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/Manage-Hyper-V-integration-services). ## Applicability Use this review for one named integration feature, not as a reason to enable every available service. Identify the guest operating system and its documented service-management method. Separate the virtual machine setting from the service state observed within that guest. ## DSE recommendation Ask the workload owner which integration functions the guest requires. For a failing function, pair the host setting with the corresponding guest service and version evidence before changing either side. Keep unnecessary services outside the approved scope. If an update or service change is proposed, arrange a guest maintenance window and preserve the previous setting so the owner can reverse that individual change. ## Verification Exercise the selected function from its normal management path. Record the host enablement state, guest service state, guest integration version, and observed result together. If the result still fails, retain the two-sided evidence for investigation rather than repeatedly toggling unrelated integration features. ## Official references [Microsoft Learn: Manage Hyper-V Integration Services](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/Manage-Hyper-V-integration-services). Source reviewed September 8, 2026. ## Primary reference - Name: Manage Hyper-V Integration Services - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/Manage-Hyper-V-integration-services - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check both ends of a Hyper-V integration service,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-239-check-both-ends-of-a-hyper-v-integration-service/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check EAP profile trust after a Windows 11 upgrade > Why can a formerly working EAP profile fail server validation after an upgrade? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-218-check-eap-profile-trust-after-a-windows-11-upgrade/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:33+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Why can a formerly working EAP profile fail server validation after an upgrade? ## Potentially affected Administrators troubleshooting Windows 11 EAP server-certificate validation for Wi-Fi, Ethernet, or VPN. ## DSE recommendation Compare an affected pilot profile with its intended root and server-name settings. ## Article ## Source facts Windows 11 applies a consistent server-certificate validation model across the EAP methods supplied with Windows, including wired, wireless, and VPN use. Microsoft notes that some Windows 10 PEAP or EAP-TLS connections could validate with only a root certificate in the trusted store; upgrade failures therefore warrant checking the connection profile. For the documented upgrade issue, specifying the root certificate thumbprint in the profile is usually sufficient when that root already exists in the trusted store. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/windows-11-changes). ## Applicability Confirm that the failure concerns server validation and identify the exact profile used by the upgraded client. Read all applicable trust conditions, including configured server-name validation. Do not infer that a trusted-store entry alone satisfies the Windows 11 profile. ## DSE recommendation Compare an affected pilot profile with its intended root and server-name settings. Ask the identity and network owners to verify the certificate actually presented by the authentication service. Correct the managed profile only after that identity is established. Preserve server validation rather than disabling it to restore connectivity, and retain the original profile for comparison. ## Verification Reapply the reviewed profile and repeat the approved connection. Confirm the expected server certificate and profile trust settings, then capture the authentication result. Include a controlled wrong-server or untrusted-certificate case in the test plan so restored connectivity is not the only acceptance condition. ## Official references [Microsoft Learn: EAP – What’s changed in Windows 11](https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/windows-11-changes). Source reviewed September 8, 2026. ## Primary reference - Name: EAP - What's changed in Windows 11 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/windows-11-changes - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check EAP profile trust after a Windows 11 upgrade,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-218-check-eap-profile-trust-after-a-windows-11-upgrade/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check FEMA flood-hazard data before siting recovery equipment > Use official FEMA flood-hazard products as an early screening input before locating generators, network rooms, archives, or recovery stock. - Canonical URL: https://update.dsesecurity.com/updates/check-fema-flood-data-before-siting-equipment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:20+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use official FEMA flood-hazard products as an early screening input before locating generators, network rooms, archives, or recovery stock. ## Potentially affected U.S. facilities placing or reviewing critical equipment, alternate operations, records, fuel, or recovery supplies in areas with flood exposure ## DSE recommendation Screen candidate locations with current FEMA products, then obtain site-specific professional and local-authority review before relying on the placement. ## Article Critical recovery equipment should not be placed solely because a room is empty, secure, or near utilities. Flood-hazard information can identify obvious conflicts early, before a generator, rack, records store, or fuel supply becomes another asset needing rescue. ## Source fact: [FEMA’s Flood Hazard Products sheet](https://msc.fema.gov/msccontent/FEMA_Hazard_Products_Direct_Download.pdf) identifies the Flood Map Service Center as the official online source for flood-hazard information produced under the National Flood Insurance Program. It states that Flood Insurance Rate Maps, Flood Insurance Studies, and National Flood Hazard Layer geodatabases are available through the center. These products support location-based review of mapped flood hazards and related study data. The products are authoritative inputs for the NFIP context, but they are not a universal site-design decision. Different products have effective dates and purposes, and conditions can change after mapping. A map result does not establish exact finished-floor elevation, drainage behavior, future climate exposure, dam or levee performance, local code compliance, or the safe placement of a specific asset. ## Boundary This article is a U.S.-focused screening approach. State, tribal, territorial, and local authorities may maintain additional maps, studies, codes, and permitting requirements. Site-specific engineering and survey work may be necessary. Flood exposure also includes rainfall drainage, sewer backup, roof or pipe failure, groundwater, coastal effects, and access-route loss that an NFIP map alone may not resolve. Do not use this review as a flood certification or insurance determination. ## Applicability questions - What exact coordinates, floor, elevation, access route, and utility connections serve the proposed asset? - Which effective FEMA map, study, amendment, revision, or local product applies to the parcel? - Can flooding reach power, controls, fuel, cooling, communications, doors, loading points, or staff routes before the asset itself? - What residual risk remains from drainage, levee dependence, unmapped streams, or changing conditions? - Which engineer, floodplain administrator, insurer, and authority must review the decision? ## DSE recommendation: Record the candidate location precisely and retrieve the current relevant FEMA products from the official service. Note map and study identifiers, effective dates, mapped zones, elevations where provided, and any Letter of Map Change affecting interpretation. Ask the local floodplain administrator whether newer local data or pending changes exist. Preserve the source artifact and retrieval date. Have a qualified professional relate hazard information to actual site elevation, drainage, building systems, access, anchorage, and code requirements. Prefer locations and utility paths outside credible flood exposure. Where relocation is not practical, evaluate elevation, barriers, water detection, shutdown, fuel protection, alternate access, and geographic redundancy. Test that the recovery plan remains usable when the facility or its normal approach roads are inaccessible. ## Verification and evidence Keep coordinates, FEMA artifacts and identifiers, local data, site survey or professional review, decision record, mitigation design, inspection results, and alternate-site exercise. Recheck after map revisions, construction, drainage changes, acquisition, or a flood event. Evidence should state assumptions and residual risk rather than declaring an asset “flood proof” or safe solely because it lies outside a mapped special flood hazard area. ## Official references - [FEMA Flood Hazard Products Direct Download](https://msc.fema.gov/msccontent/FEMA_Hazard_Products_Direct_Download.pdf) - [FEMA Flood Maps: Products and Tools](https://www.fema.gov/flood-maps/products-tools) - [FEMA Flood Map Service Center](https://msc.fema.gov/portal/home) ## Primary reference - Name: Flood Hazard Products Direct Download - Authority: msc.fema.gov - URL: https://msc.fema.gov/msccontent/FEMA_Hazard_Products_Direct_Download.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check FEMA flood-hazard data before siting recovery equipment,” DSE Security, https://update.dsesecurity.com/updates/check-fema-flood-data-before-siting-equipment/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check hybrid connectivity before creating an Azure VM in Windows Admin Center > Which existing connections are prerequisites for the documented Windows Admin Center Azure VM workflow? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-187-check-hybrid-connectivity-before-creating-an-azure-vm-in-windows-admin-center/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:04+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know Which existing connections are prerequisites for the documented Windows Admin Center Azure VM workflow? ## Potentially affected Administrators using Windows Admin Center to create Azure VMs for hybrid workloads. ## DSE recommendation Prepare a reachability checklist for each required participant before opening the VM creation wizard. ## Article ## Source facts Microsoft documents creating Azure VMs from Windows Admin Center both independently and within Storage Migration Service or Storage Replica workflows. The prerequisites include an Azure subscription, a registered gateway, creation permissions in an existing resource group, and an existing virtual network and subnet. The documented network path must connect the Azure VM with the on-premises clients, domain controllers, management computer, and workload participants that need it. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/create-azure-vms). ## Applicability Review the versioned workflow and offered VM images in the current documentation before starting. Name the actual workload and its source, destination, and management participants. Distinguish creating a new VM from migrating an existing VM image. ## DSE recommendation Prepare a reachability checklist for each required participant before opening the VM creation wizard. Have the Azure owner verify the selected subscription, resource group, network, and permission scope. Ask the workload owner to approve destination sizing and storage assumptions. Record the intended domain-join behavior and an operational contact for correcting a failed deployment without creating an untracked replacement. ## Verification In a pilot, verify the created VM identity, selected resources, required routes, and workload-specific communication. Compare the outcome with the requested configuration, including any automatically created storage or role settings. Continue to the migration or replication workflow only after its participating systems can complete the required test transactions. ## Official references [Microsoft Learn: Deploy Azure Virtual Machines using Windows Admin Center](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/create-azure-vms). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy Azure Virtual Machines using Windows Admin Center - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/create-azure-vms - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check hybrid connectivity before creating an Azure VM in Windows Admin Center,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-187-check-hybrid-connectivity-before-creating-an-azure-vm-in-windows-admin-center/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check immovable files before planning a basic-volume shrink > Why might a basic volume shrink less than the available free-space figure suggests? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-038-check-immovable-files-before-planning-a-basic-volume-shrink/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:33+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know Why might a basic volume shrink less than the available free-space figure suggests? ## Potentially affected Limit this review to an NTFS basic volume; do not apply its file-relocation discussion to a raw partition containing application data. ## DSE recommendation Record the current layout and the space requested for the new purpose. ## Article ## Source facts Windows can shrink a partition from its end to create contiguous unallocated space on the same disk. Microsoft states that ordinary files are relocated during shrinking and that reformatting is not required. Some files, including paging files and shadow-copy storage, cannot be relocated automatically. Their position can limit how far the partition can shrink. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/disk-management/shrink-a-basic-volume). ## Applicability Limit this review to an NTFS basic volume; do not apply its file-relocation discussion to a raw partition containing application data. Identify the disk, partition, intended new boundary, and workload owner. Review the documented filesystem and volume requirements before relying on a capacity estimate. ## DSE recommendation Record the current layout and the space requested for the new purpose. Investigate the reported shrink limit before proposing removal or relocation of system-managed data. Have the owner approve the partition change and verify the relevant recovery arrangements. Keep troubleshooting of a smaller-than-expected shrink separate from authorization to delete files or change shadow-copy retention. ## Verification After the approved operation, compare the resulting volume size and unallocated region with the plan. Test access to representative files and the application that uses the volume. Record the actual reclaimed space rather than the original estimate. If the target size was not achieved, preserve the observed limit and investigate it before attempting another layout change. ## Official references [Microsoft Learn: Shrink a Basic Volume](https://learn.microsoft.com/en-us/windows-server/storage/disk-management/shrink-a-basic-volume). Source reviewed September 8, 2026. ## Primary reference - Name: Shrink a Basic Volume - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/disk-management/shrink-a-basic-volume - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check immovable files before planning a basic-volume shrink,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-038-check-immovable-files-before-planning-a-basic-volume-shrink/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check metadata activity before choosing a Scale-Out File Server > Does the workload’s file-operation pattern fit a Scale-Out File Server? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-174-check-metadata-activity-before-choosing-a-scale-out-file-server/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:17+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Does the workload’s file-operation pattern fit a Scale-Out File Server? ## Potentially affected Administrators evaluating Scale-Out File Server for application data. ## DSE recommendation Ask the application owner to describe and measure the representative access pattern before selecting the clustered file-server type. ## Article ## Source facts Microsoft designs Scale-Out File Server for continuously available shares used by server applications, with the same folder shared from multiple cluster nodes. The guidance advises against this design for workloads with many metadata operations, including opening, closing, creating, and renaming files. It identifies typical information-worker activity as generating many such operations. Server application storage is the intended application category. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/failover-clustering/sofs-overview). ## Applicability Identify the application, storage protocol requirements, actual file-operation pattern, and supported deployment. Review whether the proposed share serves application data or predominantly interactive user-file activity. ## DSE recommendation Ask the application owner to describe and measure the representative access pattern before selecting the clustered file-server type. Include both large data operations and frequent file-management activity in the comparison. Document the reason the selected workload fits the source’s intended scenario. ## Verification Pilot the workload on the proposed supported design and measure its agreed application operations. Include the metadata-heavy portions of the workflow and an approved node-maintenance event. Record performance and continuity results separately, and revisit the design if the observed access pattern differs from the planning assumptions. ## Official references [Microsoft Learn: Scale-Out File Server for application data overview for Windows Server](https://learn.microsoft.com/en-us/windows-server/failover-clustering/sofs-overview). Source reviewed September 8, 2026. ## Primary reference - Name: Scale-Out File Server for application data overview for Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/sofs-overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check metadata activity before choosing a Scale-Out File Server,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-174-check-metadata-activity-before-choosing-a-scale-out-file-server/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check Network ATC prerequisites before creating the first intent > What must be settled before an initial Network ATC host-network deployment? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-006-check-network-atc-prerequisites-before-creating-the-first-intent/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:17:05+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What must be settled before an initial Network ATC host-network deployment? ## Potentially affected Use this review before creating the first intent. ## DSE recommendation Prepare a node-by-node prerequisite worksheet and an adapter-role diagram. ## Article ## Source facts Network ATC expresses management, compute, or storage requirements as adapter intents and automates the corresponding host-network configuration. The retrieved deployment guide requires Windows Server 2025 or later across a Windows Server cluster, or Azure Local 2311.2 or later for that platform. Microsoft emphasizes that ATC changes the deployment method, while the selected network scenario must still be supported. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/network-atc/network-atc). ## Applicability Use this review before creating the first intent. Identify the cluster platform and releases, intended adapter roles, and supported network scenario. Check the complete current requirements rather than inferring readiness from an installed feature. ## DSE recommendation Prepare a node-by-node prerequisite worksheet and an adapter-role diagram. Have the network owner approve the intended management, compute, and storage arrangement before automation is invoked. Review the documented default values and record deliberate deviations. Preserve a working management route and identify who will investigate an intent that does not deploy successfully. ## Verification After the approved pilot deployment, inspect the resulting intent state on each node and compare adapter assignments with the diagram. Test the selected management and workload paths. Record missing prerequisites or unexpected defaults as findings rather than manually changing unrelated settings. Resolve them before creating additional intents or extending the configuration to another cluster. ## Official references [Microsoft Learn: Deploy host networking with Network ATC](https://learn.microsoft.com/en-us/windows-server/networking/network-atc/network-atc). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy host networking with Network ATC - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/network-atc/network-atc - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check Network ATC prerequisites before creating the first intent,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-006-check-network-atc-prerequisites-before-creating-the-first-intent/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check prerequisites before enabling kernel hardware stack protection > How should a pilot for kernel hardware-enforced stack protection be prepared? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-014-check-prerequisites-before-enabling-kernel-hardware-stack-protection/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:57+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should a pilot for kernel hardware-enforced stack protection be prepared? ## Potentially affected Use this review when evaluating the protection on a Windows system. ## DSE recommendation Inventory the hardware and installed drivers for the pilot system, and name the owner of any compatibility investigation. ## Article ## Source facts Microsoft describes kernel-mode hardware stack protection as a defense against return-oriented programming attacks on kernel stacks. The mechanism pairs kernel stacks with shadow stacks to check control-flow integrity. Virtualization-based security and hypervisor-enforced code integrity must be enabled before the feature is enabled; the documentation also specifies supported hardware and Windows prerequisites. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection). ## Applicability Use this review when evaluating the protection on a Windows system. Verify the exact operating-system, application, processor, and security prerequisites in the current source. Do not infer eligibility from the article’s placement within Windows Server documentation. ## DSE recommendation Inventory the hardware and installed drivers for the pilot system, and name the owner of any compatibility investigation. Record the starting state of the prerequisite protections. Agree on essential workload tests and a supported recovery procedure before enabling the feature. Select a representative system whose failure can be investigated without interrupting an unapproved production workload. ## Verification After the approved change and any requested restart, inspect the protection state and record whether it became active. Exercise the chosen applications and device functions. Preserve reported incompatibilities or unexpected failures with the relevant driver and system details. Expand only after the pilot owner accepts both the security-state evidence and the workload results. ## Official references [Microsoft Learn: Kernel Mode Hardware-enforced Stack Protection](https://learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection). Source reviewed September 8, 2026. ## Primary reference - Name: Kernel Mode Hardware-enforced Stack Protection - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check prerequisites before enabling kernel hardware stack protection,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-014-check-prerequisites-before-enabling-kernel-hardware-stack-protection/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check that NPS can select an auto-enrolled server certificate > How can an NPS administrator verify an enrolled certificate without leaving a test policy behind? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-140-check-that-nps-can-select-an-auto-enrolled-server-certificate/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:51+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How can an NPS administrator verify an enrolled certificate without leaving a test policy behind? ## Potentially affected Administrators checking NPS server certificates after configuring certificate auto-enrollment. ## DSE recommendation Record the expected certificate identity and have the PKI and authentication owners review it together. ## Article ## Source facts Microsoft’s NPS auto-enrollment procedure uses Group Policy to manage certificate issuance and renewal in an Active Directory environment. After refreshing policy, its verification procedure begins a test network-policy workflow so NPS can confirm that the enrolled certificate is usable for authentication. The administrator does not finish that wizard. Consequently, the certificate can be checked without creating the test network policy. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/configure-server-certificate-auto-enrollment). ## Applicability Identify the NPS server, certificate template, policy scope, issuing authority, and intended authentication method. Review the source’s enrollment prerequisites and confirm that the certificate being inspected belongs to the intended server. ## DSE recommendation Record the expected certificate identity and have the PKI and authentication owners review it together. Follow the documented inspection workflow, noting where the wizard must be cancelled. Keep certificate inspection separate from approval of any new access policy. ## Verification Confirm that the expected certificate is offered and accepted in the relevant NPS authentication configuration. Cancel the temporary workflow and verify that no unintended policy was left behind. Then conduct the approved authentication test and preserve the certificate identity and result without recording private-key material. ## Official references [Microsoft Learn: Configure Certificate Auto-Enrollment for Network Policy Server](https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/configure-server-certificate-auto-enrollment). Source reviewed September 8, 2026. ## Primary reference - Name: Configure Certificate Auto-Enrollment for Network Policy Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/configure-server-certificate-auto-enrollment - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check that NPS can select an auto-enrolled server certificate,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-140-check-that-nps-can-select-an-auto-enrolled-server-certificate/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check the attestation version before registering a host TPM with HGS > Which TPM certificate requirement applies when registering a guarded host with HGS? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-096-check-the-attestation-version-before-registering-a-host-tpm-with-hgs/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:35+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which TPM certificate requirement applies when registering a guarded host with HGS? ## Potentially affected Administrators preparing TPM-mode attestation evidence for Host Guardian Service. ## DSE recommendation Create a host-registration record containing the hardware identity, TPM readiness evidence, certificate availability, and intended policy version. ## Article ## Source facts Microsoft states that the v2 attestation method introduced in Windows Server 2019 requires a TPM certificate when adding a host’s endorsement-key public identifier to HGS. The Force option used with the earlier method does not bypass that requirement in v2. The source documents explicitly selecting v1 when registration without a certificate is necessary. Before collection, the host TPM must be initialized and have ownership established; Microsoft describes checking that state with the TPM console or Get-Tpm. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tpm-trusted-attestation-capturing-hardware). ## Applicability Identify the HGS version, intended attestation policy, host hardware class, and TPM readiness. Review the policy implications of any exception before selecting a legacy attestation method. ## DSE recommendation Create a host-registration record containing the hardware identity, TPM readiness evidence, certificate availability, and intended policy version. Have the guarded-fabric owner review exceptions individually. Keep this enrollment decision separate from the protection and recovery of virtual-machine keys. ## Verification Perform registration for a representative host under the approved policy and preserve the selected attestation version and resulting status. Investigate certificate or readiness failures without silently changing the method. Repeat collection for each relevant hardware class and verify that a record from one host has not been reused for another. ## Official references [Microsoft Learn: Capture TPM-mode information required by HGS](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tpm-trusted-attestation-capturing-hardware). Source reviewed September 8, 2026. ## Primary reference - Name: Capture TPM-mode information required by HGS - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tpm-trusted-attestation-capturing-hardware - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check the attestation version before registering a host TPM with HGS,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-096-check-the-attestation-version-before-registering-a-host-tpm-with-hgs/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check the limits of SDN virtual network peering > Which connections must be configured explicitly when SDN virtual networks are peered? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-162-check-the-limits-of-sdn-virtual-network-peering/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:29+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which connections must be configured explicitly when SDN virtual networks are peered? ## Potentially affected Administrators designing peering between Windows Server SDN virtual networks. ## DSE recommendation Draw the intended connections as explicit network pairs. ## Article ## Source facts Microsoft describes peered virtual machines communicating over private addresses through the underlying infrastructure, without an internet connection or gateway for that communication. Peering does not extend transitively: connecting the first network to a second, and the second to a third, does not connect the first and third. Access control lists can restrict communication between peered networks, subnets, or individual virtual machines. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/sdn/vnet-peering/sdn-vnet-peering). ## Applicability List every network pair that the application requires. Identify the relevant SDN implementation before applying this behavior to another networking product. Treat peering reachability, permitted application flows, and on-premises gateway use as separate design entries. ## DSE recommendation Draw the intended connections as explicit network pairs. Beside each pair, identify the initiating workload, destination service, and permitted traffic. Have the network owner approve any broad connectivity before the application team enables it. Include a deliberately unpeered pair in the acceptance plan so an indirect relationship cannot silently become the assumed route. Preserve the prior peering and filtering configuration. ## Verification Test an allowed flow and a prohibited flow across each configured pair. Then test between the first and third networks in the three-network example. Record the actual routes, applied access rules, and results from both ends. Resolve unexpected connectivity before extending the design to additional tenants. ## Official references [Microsoft Learn: Virtual network peering](https://learn.microsoft.com/en-us/windows-server/networking/sdn/vnet-peering/sdn-vnet-peering). Source reviewed September 8, 2026. ## Primary reference - Name: Virtual network peering - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/sdn/vnet-peering/sdn-vnet-peering - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check the limits of SDN virtual network peering,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-162-check-the-limits-of-sdn-virtual-network-peering/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check the position of unallocated space before extending a Windows volume > Why might available disk space be unusable for the planned volume extension? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-078-check-the-position-of-unallocated-space-before-extending-a-windows-volume/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:53+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Why might available disk space be unusable for the planned volume extension? ## Potentially affected Use this review when an existing Windows volume needs more capacity. ## DSE recommendation Capture the current disk layout and have another administrator verify the target and adjacent unallocated region. ## Article ## Source facts Windows volume extension adds unallocated space to an existing volume through Disk Management or PowerShell. The documented procedure requires the unallocated region to immediately follow the target volume; an intervening volume prevents that extension. The source also requires the volume to use NTFS or ReFS. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/disk-management/extend-a-basic-volume). ## Applicability Use this review when an existing Windows volume needs more capacity. Identify the exact disk, filesystem, partition order, and requested new size. Check all documented prerequisites rather than relying on a total-free-space figure. ## DSE recommendation Capture the current disk layout and have another administrator verify the target and adjacent unallocated region. Ask the data owner to approve the intended capacity change and confirm recovery arrangements. Treat deleting or moving an intervening partition as a separate decision requiring its own supported procedure and data review. ## Verification After an approved extension, compare the resulting size and partition layout with the plan. Verify representative file access and the application’s usable capacity. Retain the observed result and any error from the operation. If the required adjacent space is absent, return to storage planning instead of repeatedly attempting the same extension. ## Official references [Microsoft Learn: Extend a basic or dynamic volume in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/storage/disk-management/extend-a-basic-volume). Source reviewed September 8, 2026. ## Primary reference - Name: Extend a basic or dynamic volume in Windows and Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/disk-management/extend-a-basic-volume - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check the position of unallocated space before extending a Windows volume,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-078-check-the-position-of-unallocated-space-before-extending-a-windows-volume/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check the preview and access requirements for portal-based WAC management > What must be approved before managing an Arc-enabled server with Windows Admin Center in Azure? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-203-check-the-preview-and-access-requirements-for-portal-based-wac-management/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:48+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What must be approved before managing an Arc-enabled server with Windows Admin Center in Azure? ## Potentially affected Administrators evaluating Windows Admin Center in the Azure portal for Arc-enabled hybrid servers. ## DSE recommendation Document the proposed management operations and obtain the environment owner's decision on preview use. ## Article ## Source facts The cited Microsoft guidance labels Windows Admin Center in the Azure portal as a preview. It describes managing an individual hybrid Windows Server machine without opening inbound firewall ports. The machine must already be connected to Azure Arc and have the WAC agent installed. Installing the extension requires one of the documented Azure roles. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/manage-arc-hybrid-machines). ## Applicability Check the current preview status, regional availability, server requirements, and role requirements in the official page before deployment. Identify the target Arc resource and the person authorized to install its management extension. Separate acceptance of a preview feature from ordinary server onboarding. ## DSE recommendation Document the proposed management operations and obtain the environment owner’s decision on preview use. Assign the narrowest suitable documented role and verify the target resource scope with the Azure administrator. Pilot the extension on one approved machine, recording how operators will reach the server if the portal path is unavailable. Include extension ownership and removal criteria in the management plan. ## Verification Verify the extension state and open the intended management tools against the selected server. Confirm an authorized operator can perform the agreed task and an unauthorized identity cannot. Record connectivity and permission failures separately. Retain the observed preview version and revisit acceptance when the feature or its availability changes. ## Official references [Microsoft Learn: Manage Azure Arc-enabled Servers using Windows Admin Center in Azure](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/manage-arc-hybrid-machines). Source reviewed September 8, 2026. ## Primary reference - Name: Manage Azure Arc-enabled Servers using Windows Admin Center in Azure - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/manage-arc-hybrid-machines - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check the preview and access requirements for portal-based WAC management,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-203-check-the-preview-and-access-requirements-for-portal-based-wac-management/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check the subject and user-name fields in NPS certificate templates > Which identity fields must be populated for the documented NPS server and user certificates? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-232-check-the-subject-and-user-name-fields-in-nps-certificate-templates/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:19+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Which identity fields must be populated for the documented NPS server and user certificates? ## Potentially affected Administrators preparing AD CS certificate templates for PEAP and EAP network authentication. ## DSE recommendation Have the PKI and network-access owners review the intended Subject and UPN population before enrolling pilot identities. ## Article ## Source facts Microsoft says an NPS server certificate with a blank Subject is unavailable for NPS authentication. Its template instructions choose a Subject name format other than None and build the name from directory information. For user certificates, the documented client requirement places the user principal name in the Subject Alternative Name extension. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-cert-requirements). ## Applicability Identify whether the template issues a server or user certificate and review the complete requirements for the chosen authentication method. Inspect an actual issued certificate as well as the template. Keep these identity fields separate from the certificate’s issuer, purposes, validity, and trust-chain checks. ## DSE recommendation Have the PKI and network-access owners review the intended Subject and UPN population before enrolling pilot identities. Record the template version, enrollment scope, and expected certificate fields. Use a dedicated test server or user so the resulting certificate can be inspected without changing an entire deployment. Preserve the prior template configuration and document any requested correction. ## Verification Examine the issued certificate and compare its Subject or user UPN field with the approved identity. Confirm the intended server certificate is available in NPS and exercise the selected authentication method with the pilot. Record missing fields and selection failures separately from other chain-validation errors before widening enrollment. ## Official references [Microsoft Learn: Configure Certificate Templates for PEAP and EAP requirements](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-cert-requirements). Source reviewed September 8, 2026. ## Primary reference - Name: Configure Certificate Templates for PEAP and EAP requirements - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-cert-requirements - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check the subject and user-name fields in NPS certificate templates,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-232-check-the-subject-and-user-name-fields-in-nps-certificate-templates/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check what remains in a cluster WER report before relying on it > Which cluster diagnostic artifacts should be preserved before a WER report is archived? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-123-check-what-remains-in-a-cluster-wer-report-before-relying-on-it/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:08+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which cluster diagnostic artifacts should be preserved before a WER report is archived? ## Potentially affected Administrators collecting failover-cluster evidence through Windows Error Reporting. ## DSE recommendation Agree on the diagnostic collection with the cluster owner before reproducing a failure. ## Article ## Source facts Microsoft describes Windows Error Reporting as an event-driven mechanism for collecting information about detected Windows hardware and software problems. For cluster diagnostics, the DumpLogQuery resource property holds multiple XPath queries used to collect logs after the relevant event channels are enabled. Microsoft notes that uploaded reports in the WER archive retain Report.wer while the accompanying report data is deleted. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/failover-clustering/troubleshooting-using-WER-reports). ## Applicability Identify the failing cluster resource, event time, collection configuration, report location, and support case. Review which event channels are needed for the investigation and the permissions required to collect them. ## DSE recommendation Agree on the diagnostic collection with the cluster owner before reproducing a failure. Preserve the report and relevant logs through the organization’s approved evidence process, documenting their origin and timestamps. Check the actual files present instead of assuming an archived report still contains every original artifact. ## Verification Open the retained evidence and confirm that it covers the resource and failure window being investigated. Compare the collection queries with the included event channels and list missing files explicitly. Use supported analysis tools and keep any gap in the report separate from a conclusion about the cluster’s root cause. ## Official references [Microsoft Learn: Troubleshooting a Failover Cluster using Windows Error Reporting](https://learn.microsoft.com/en-us/windows-server/failover-clustering/troubleshooting-using-WER-reports). Source reviewed September 8, 2026. ## Primary reference - Name: Troubleshooting a Failover Cluster using Windows Error Reporting - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/troubleshooting-using-WER-reports - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check what remains in a cluster WER report before relying on it,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-123-check-what-remains-in-a-cluster-wer-report-before-relying-on-it/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check where SDN virtual network encryption stops > Which traffic is covered by encryption on an SDN virtual subnet? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-176-check-where-sdn-virtual-network-encryption-stops/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:15+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Which traffic is covered by encryption on an SDN virtual subnet? ## Potentially affected Administrators enabling encryption on Windows Server SDN virtual networks. ## DSE recommendation Create a protection matrix with one row per application flow. ## Article ## Source facts Microsoft describes subnet encryption using DTLS for virtual machines communicating inside an encryption-enabled subnet. The configuration requires encryption certificates on the SDN Hyper-V hosts and a Network Controller credential referencing the certificate thumbprint. The source states that traffic crossing between subnets, or leaving the virtual network, is not encrypted by this feature even when the subnets are marked for encryption. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/sdn/vnet-encryption/sdn-config-vnet-encryption). ## Applicability Map the actual source and destination subnets for the protected workload. Distinguish a same-subnet conversation from cross-subnet and external traffic. Decide which additional protection is needed for each path rather than treating one enabled setting as a complete traffic inventory. ## DSE recommendation Create a protection matrix with one row per application flow. Identify the certificate and credential objects used by the intended hosts, the subnet setting, and the expected protection at every boundary. Ask the workload owner to approve coverage gaps explicitly. Keep certificate handling and renewal ownership in the configuration record and preserve the original settings for the pilot. ## Verification Test representative traffic within a protected subnet, across a subnet boundary, and outside the virtual network. Use authorized observations that can distinguish the relevant protection without collecting unnecessary payloads. Compare the evidence with the flow matrix and investigate any unsupported assumption before expanding encryption to more workloads. ## Official references [Microsoft Learn: Configure Encryption for a Virtual Network](https://learn.microsoft.com/en-us/windows-server/networking/sdn/vnet-encryption/sdn-config-vnet-encryption). Source reviewed September 8, 2026. ## Primary reference - Name: Configure Encryption for a Virtual Network - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/sdn/vnet-encryption/sdn-config-vnet-encryption - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check where SDN virtual network encryption stops,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-176-check-where-sdn-virtual-network-encryption-stops/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check Windows 11 guest CPU features before changing Hyper-V compatibility settings > Which CPU-feature requirement should be reviewed for a Windows 11 Hyper-V guest? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-151-check-windows-11-guest-cpu-features-before-changing-hyper-v-compatibility-settings/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:40+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which CPU-feature requirement should be reviewed for a Windows 11 Hyper-V guest? ## Potentially affected Administrators validating Windows 11 guests on supported Hyper-V hosts. ## DSE recommendation Document the required CPU features and the compatibility mode proposed for the actual topology. ## Article ## Source facts Microsoft’s Windows guest-support table states that Windows 11 needs the POPCNT and SSE4.2 processor instructions for installation and boot. For the listed standalone configurations and Windows Server 2022 hosts, the guidance disables processor compatibility to expose those features, which restricts live migration to hosts with matching processor features. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/Supported-Windows-guest-operating-systems-for-Hyper-V-on-Windows). ## Applicability Identify the exact guest and host releases, VM generation, physical CPUs, and intended migration destinations. Review the source’s separate Windows Server 2025 cluster guidance rather than applying the standalone instruction to every host. ## DSE recommendation Document the required CPU features and the compatibility mode proposed for the actual topology. Have the virtualization owner compare all intended destination CPUs before changing that setting. Keep guest-startup requirements and migration requirements visible in the same approval record. ## Verification Verify guest installation or boot and inspect the exposed processor features in the approved configuration. Test the intended migration destinations where authorized and record unsupported combinations explicitly. Resolve a mismatch before treating successful startup on one host as proof that the guest can move across the whole fabric. ## Official references [Microsoft Learn: Supported Windows guest operating systems for Hyper-V on Windows, Windows Server, and Azure Local](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/Supported-Windows-guest-operating-systems-for-Hyper-V-on-Windows). Source reviewed September 8, 2026. ## Primary reference - Name: Supported Windows guest operating systems for Hyper-V on Windows, Windows Server, and Azure Local - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/Supported-Windows-guest-operating-systems-for-Hyper-V-on-Windows - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Check Windows 11 guest CPU features before changing Hyper-V compatibility settings,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-151-check-windows-11-guest-cpu-features-before-changing-hyper-v-compatibility-settings/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Check Windows Autopatch prerequisites before registering production devices > Windows Autopatch eligibility depends on licensing, Intune enrollment, corporate ownership, join and co-management state, recent check-in, Microsoft endpoints, diagnostic data, edition, and update channel. - Canonical URL: https://update.dsesecurity.com/updates/windows-autopatch-production-prerequisites/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:15+00:00 - Modified: 2026-07-19T21:28:15+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 2 minutes ## What you need to know Windows Autopatch eligibility depends on licensing, Intune enrollment, corporate ownership, join and co-management state, recent check-in, Microsoft endpoints, diagnostic data, edition, and update channel. ## Potentially affected Organizations considering Windows Autopatch for supported corporate-owned Windows 10 or Windows 11 devices managed by Microsoft Intune or supported co-management. ## DSE recommendation Validate tenant and device prerequisites, network and privacy requirements, update authorities, representative pilot readiness, reporting, support ownership, and rollback before registering a production population. ## Article ## Source fact: what Microsoft documents Microsoft documents Windows Autopatch availability with Microsoft 365 Business Premium, supported Windows 10 or 11 Education A3/A5 and Enterprise E3/E5 entitlements, eligible Microsoft 365 F3/E3/E5 suites, and Windows Enterprise VDA. Feature and support entitlements differ by subscription. Microsoft Entra ID P1 or P2 and Microsoft Intune are required. Devices must already be enrolled in Intune before Autopatch registration, or use supported Configuration Manager co-management. Intune must be the mobile-device-management authority, and the Windows Update policies and Device configuration workloads must be assigned to Intune or Pilot Intune for targeted devices. Configuration Manager-only devices are not supported. Microsoft requires corporate-owned devices; Windows bring-your-own devices are blocked during prerequisite checks. A device must have communicated with Intune within the previous 28 days, have internet connectivity, and reach required Microsoft service endpoints. Tailored deployment protections require diagnostic data at the documented level. Supported Windows client editions use the General Availability Channel. Supported LTSC devices can receive quality-update management, but Autopatch does not offer LTSC feature updates. ## Applicability and cautions Windows edition, architecture, build, channel, licensing, device ownership, Entra join, Intune enrollment, co-management workloads, proxy and firewall configuration, diagnostic-data policy, WSUS scan source, and recent check-in all affect eligibility. Windows 10 support status and individual LTSC lifecycle must be checked. Hotpatching has separate prerequisites. Autopatch automates supported update management; it does not remove the need for application testing, incident ownership, recovery, or business validation. ## DSE recommendation: production-safe operational steps - Confirm tenant subscriptions, Entra and Intune entitlements, Autopatch feature coverage, and support rights with current Microsoft product terms. - Export device edition, version, architecture, channel, ownership, join state, Intune enrollment, last check-in, management authority, co-management workloads, and existing update policies. - Identify unsupported BYOD, Configuration Manager-only, stale, LTSC, end-of-support, virtual, kiosk, or specialized devices and define a separate servicing plan. - Validate required Microsoft endpoints through the real proxy, firewall, VPN, DNS, TLS inspection, and branch paths. Record the test and exception owner. - Obtain the required privacy and security approval for diagnostic data and document what features change if the required level is unavailable. - Reconcile WSUS, scan-source, update-ring, feature, quality, driver, firmware, and Configuration Manager settings before registration. - Register a representative pilot, review readiness and update reports, validate business applications and recovery, and expand only after defined exit criteria pass. DSE recommends preserving the pre-registration configuration and assigning an operator who can pause, correct, or remove a failed pilot. Registration success is not production acceptance; verify actual update installation, restart, application health, endpoint security, and user support outcomes. ## Official reference [Windows Autopatch prerequisites](https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites) — licensing, feature entitlement, Intune and Entra requirements, connectivity, ownership, diagnostic data, editions, channels, and co-management. ## Primary reference - Name: Microsoft Learn: Windows Autopatch prerequisites - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites - Source publication date: 2026-02-27 ## Citation and use Preferred citation: “Check Windows Autopatch prerequisites before registering production devices,” DSE Security, https://update.dsesecurity.com/updates/windows-autopatch-production-prerequisites/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose a DFS namespace type before designing its availability > Which namespace type and mode fit the organization's directory and availability requirements? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-077-choose-a-dfs-namespace-type-before-designing-its-availability/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:54+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Which namespace type and mode fit the organization's directory and availability requirements? ## Potentially affected Use this review before creating a namespace. ## DSE recommendation Prepare a short design record explaining why the chosen type fits those requirements. ## Article ## Source facts Microsoft distinguishes standalone and domain-based DFS namespaces, with a further namespace-mode choice for domain-based deployments. Its standalone guidance includes organizations without AD DS and designs that use a failover cluster for namespace availability. For domain-based namespaces, Microsoft describes Windows Server 2008 mode as supporting access-based enumeration and increased scale compared with Windows 2000 Server mode. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/choose-a-namespace-type). ## Applicability Use this review before creating a namespace. Identify the available directory services, required namespace availability, planned folder count, and desired visibility features. Verify the actual requirements for the selected namespace mode in the current source. ## DSE recommendation Prepare a short design record explaining why the chosen type fits those requirements. Have the directory and file-service owners review the decision together, including any cluster dependency. Keep the namespace mode terminology separate from the operating systems proposed for deployment. Record the intended namespace name and ownership before proceeding to target and referral configuration. ## Verification Create an approved limited test namespace and inspect its actual type and mode. Exercise the required visibility and client-access behavior, then compare it with the design record. Verify the proposed availability arrangement through its separately approved test. Resolve an unmet requirement before adding production folder targets or treating the test namespace as the final design. ## Official references [Microsoft Learn: Choose a Namespace Type](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/choose-a-namespace-type). Source reviewed September 8, 2026. ## Primary reference - Name: Choose a Namespace Type - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/choose-a-namespace-type - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose a DFS namespace type before designing its availability,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-077-choose-a-dfs-namespace-type-before-designing-its-availability/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose a Hyper-V VM generation from guest and boot requirements > Which guest and boot requirements should determine a new Hyper-V VM generation? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-046-choose-a-hyper-v-vm-generation-from-guest-and-boot-requirements/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:25+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know Which guest and boot requirements should determine a new Hyper-V VM generation? ## Potentially affected Use this review before creating a virtual machine. ## DSE recommendation Record the selected generation and the requirement that justified it. ## Article ## Source facts Microsoft says VM-generation selection depends on the guest operating system and the intended installation boot method, and generally recommends generation 2 subject to documented exceptions. Generation 2 enables Secure Boot by default and checks the boot loader against trusted UEFI authorities. The documentation provides guest support guidance for each generation, including differences for Windows, Linux, and FreeBSD. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/Should-I-create-a-generation-1-or-2-virtual-machine-in-Hyper-V). ## Applicability Use this review before creating a virtual machine. Identify the exact guest release, installation media, boot method, and application owner. Consult the current guest-support table instead of inferring compatibility from a broad operating-system family. ## DSE recommendation Record the selected generation and the requirement that justified it. Verify the installation media and intended Secure Boot configuration in an approved pilot. Ask the guest owner to include application installation and recovery tooling in the acceptance plan. Keep exceptions to the preferred generation explicit and linked to the requirement, rather than allowing copied VM settings to become an undocumented standard. ## Verification Create the approved test VM and record its generation, boot settings, and successful guest installation. Exercise the selected application and recovery boot path. Preserve any failure with the exact media and guest version. Resolve a compatibility mismatch before using the configuration as a template for additional virtual machines. ## Official references [Microsoft Learn: Should I create a generation 1 or 2 virtual machine in Hyper-V?](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/Should-I-create-a-generation-1-or-2-virtual-machine-in-Hyper-V). Source reviewed September 8, 2026. ## Primary reference - Name: Should I create a generation 1 or 2 virtual machine in Hyper-V? - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/Should-I-create-a-generation-1-or-2-virtual-machine-in-Hyper-V - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose a Hyper-V VM generation from guest and boot requirements,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-046-choose-a-hyper-v-vm-generation-from-guest-and-boot-requirements/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose a networking approach before enabling nested Hyper-V > Which networking assumptions should be checked when running Hyper-V inside a virtual machine? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-093-choose-a-networking-approach-before-enabling-nested-hyper-v/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:38+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which networking assumptions should be checked when running Hyper-V inside a virtual machine? ## Potentially affected Administrators preparing supported nested Hyper-V test environments. ## DSE recommendation Draw the host, first-level VM, nested guests, switches, and proposed address path. ## Article ## Source facts Nested virtualization allows Hyper-V to run within a virtual machine. Microsoft performs the processor-exposure configuration while that virtual machine is powered off. For packets to traverse two virtual-switch layers, the documented approach enables MAC address spoofing at the first virtual-machine level. Microsoft also describes NAT as an alternative when spoofing cannot be used, including public-cloud scenarios. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/enable-nested-virtualization). ## Applicability Check the physical processor, host release, guest release, VM configuration, and platform restrictions against the source prerequisites. Define which nested guests require outside connectivity and which should remain isolated. ## DSE recommendation Draw the host, first-level VM, nested guests, switches, and proposed address path. Have the network owner approve the chosen method and its boundary. Schedule the required VM shutdown and retain the original processor and network settings before enabling the nested environment. ## Verification Test connectivity from a nested guest to each intended destination and check an explicitly disallowed path. Confirm the address observed outside the nested environment and record the forwarding configuration. Recheck the first-level VM after a restart, and preserve any difference from the approved network diagram as an unresolved finding. ## Official references [Microsoft Learn: Run Hyper-V in a Virtual Machine with Nested Virtualization](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/enable-nested-virtualization). Source reviewed September 8, 2026. ## Primary reference - Name: Run Hyper-V in a Virtual Machine with Nested Virtualization - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/enable-nested-virtualization - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose a networking approach before enabling nested Hyper-V,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-093-choose-a-networking-approach-before-enabling-nested-hyper-v/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose a Windows Admin Center gateway location > Should administrators use a local client installation or a designated gateway server? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-231-choose-a-windows-admin-center-gateway-location/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:20+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Should administrators use a local client installation or a designated gateway server? ## Potentially affected Teams choosing where to install Windows Admin Center for server management. ## DSE recommendation Draw the browser-to-gateway and gateway-to-managed-server paths for the proposed location. ## Article ## Source facts Microsoft describes a local Windows client installation for small-scale or ad hoc use and a designated gateway server for larger-scale access from client browsers. Microsoft does not recommend managing the gateway’s own server locally through that installation. Installing Windows Admin Center on a domain controller is unsupported. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/plan/installation-options). ## Applicability Identify the administrator population, intended managed servers, and available management endpoints before selecting the installation mode. Confirm the supported operating system and current gateway-version requirements. Keep this placement decision separate from assigning users to gateway roles. ## DSE recommendation Draw the browser-to-gateway and gateway-to-managed-server paths for the proposed location. Select a designated owner for gateway updates, certificates, and recovery. For a local-client trial, document who can continue management when that workstation is unavailable. Exclude domain controllers from the placement candidates and use a separate management route for the server hosting the gateway. ## Verification From an intended administrator device, connect through the selected gateway and open a representative managed server. Confirm that the recorded gateway host is the endpoint actually serving the session. Review the loss-of-gateway scenario with the operations owner and verify that its alternate management route is usable. ## Official references [Microsoft Learn: What type of installation is right for you](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/plan/installation-options). Source reviewed September 8, 2026. ## Primary reference - Name: What type of installation is right for you - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/plan/installation-options - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose a Windows Admin Center gateway location,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-231-choose-a-windows-admin-center-gateway-location/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose AD group scope from the resource and trust boundary > Use Active Directory Security Groups to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/choose-ad-group-scope-from-resource-trust-boundary/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:52+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Active Directory Security Groups to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Active Directory Security Groups ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Choose AD group scope from the resource and trust boundary. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Active Directory Security Groups](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups) from Microsoft supports the following bounded statements: - AD security groups are authorization principals distinct from distribution groups. The research record locates this support at Sections: Security groups; Distribution groups. - Group scope controls where a group can be granted permissions and which principals it can contain. The research record locates this support at Section: Group scope. The source support ends with the statements listed above. Use them to examine forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Model nesting and trust paths before changing group scope or membership. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Sections: Security groups; Distribution groups, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section: Group scope, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to Sections: Security groups; Distribution groups; Section: Group scope and to observable material such as directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Active Directory Security Groups](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups) — Microsoft ## Primary reference - Name: Active Directory Security Groups - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-groups - Source publication date: 2025-07-02 ## Citation and use Preferred citation: “Choose AD group scope from the resource and trust boundary,” DSE Security, https://update.dsesecurity.com/updates/choose-ad-group-scope-from-resource-trust-boundary/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose an Offline Files synchronization policy for metered connections > When should background Offline Files synchronization be permitted on a metered network? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-021-choose-an-offline-files-synchronization-policy-for-metered-connections/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:50+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know When should background Offline Files synchronization be permitted on a metered network? ## Potentially affected Use this review for managed clients whose Offline Files data must be synchronized while users travel. ## DSE recommendation Ask the business owner to balance data freshness against the organization's connection-cost policy. ## Article ## Source facts Microsoft documents background synchronization controls that account for roaming and bandwidth limits on metered connections. Users can also initiate synchronization manually. The Enable file synchronization on costed networks Group Policy setting permits background Offline Files synchronization while connected to a metered network. The documented domain-based procedure requires AD DS and domain-joined clients, without additional functional-level or schema requirements. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/enable-background-synchronization). ## Applicability Use this review for managed clients whose Offline Files data must be synchronized while users travel. Identify the data owner, metered network use, and expected synchronization needs before selecting a policy scope. ## DSE recommendation Ask the business owner to balance data freshness against the organization’s connection-cost policy. Define which users need background synchronization, which networks they use, and how support staff should handle an overdue synchronization. Pilot the policy with a small representative group. Communicate the intended behavior and the circumstances in which a manual synchronization should be requested. ## Verification Inspect the applied policy on a pilot client and record its network classification during the test. Observe a permitted background synchronization and a separately initiated manual one. Confirm the selected files and timestamps at both endpoints. Record unexpected transfers or absent updates with the connection conditions before expanding the policy. ## Official references [Microsoft Learn: Enable Background File Synchronization on Metered Networks in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/enable-background-synchronization). Source reviewed September 8, 2026. ## Primary reference - Name: Enable Background File Synchronization on Metered Networks in Windows and Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/enable-background-synchronization - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose an Offline Files synchronization policy for metered connections,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-021-choose-an-offline-files-synchronization-policy-for-metered-connections/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose and secure a DFS namespace root before adding folder targets > What decisions and permissions should be checked when creating a DFS namespace? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-097-choose-and-secure-a-dfs-namespace-root-before-adding-folder-targets/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:34+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What decisions and permissions should be checked when creating a DFS namespace? ## Potentially affected Administrators creating Windows Server DFS namespace roots. ## DSE recommendation Have the file-service owner approve the namespace name and type. ## Article ## Source facts A DFS namespace presents shared folders through a virtual hierarchy and a common access path. Microsoft offers a choice between a namespace associated with a domain and a standalone namespace during creation. Creation requires administrative or equivalent permissions on the selected computer. After creation, Microsoft directs administrators to restrict access to the namespace folder for both namespace types to protect the configuration. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/create-a-dfs-namespace). ## Applicability Identify the namespace server, desired path, namespace type, and intended administrators. Review any delegated permissions against the source before starting the wizard or adapting its PowerShell procedure. ## DSE recommendation Have the file-service owner approve the namespace name and type. Record who can manage the root and the access restrictions to be applied immediately after creation. Keep the root design separate from the later choices of folder targets, referral preference, and replication membership. ## Verification After creating the root in an approved environment, verify its type, hosting server, visible path, and management permissions. Test access with an intended user and an account outside the approved administrative group. Record the actual results before adding production folder targets or distributing the namespace path. ## Official references [Microsoft Learn: Create a DFS Namespace in Windows Server](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/create-a-dfs-namespace). Source reviewed September 8, 2026. ## Primary reference - Name: Create a DFS Namespace in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/create-a-dfs-namespace - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose and secure a DFS namespace root before adding folder targets,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-097-choose-and-secure-a-dfs-namespace-root-before-adding-folder-targets/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose automatic or manual sensor activation from the domain-controller inventory > Use Activate the Defender for Identity sensor v3.x on a domain controller to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/choose-automatic-or-manual-sensor-activation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:39+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Activate the Defender for Identity sensor v3.x on a domain controller to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Activate the Defender for Identity sensor v3.x on a domain controller ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Choose automatic or manual sensor activation from the domain-controller inventory. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Activate the Defender for Identity sensor v3.x on a domain controller](https://learn.microsoft.com/en-us/defender-for-identity/deploy/activate-sensor) from Microsoft supports the following bounded statements: - Microsoft calls for activating the sensor on all applicable servers and directs older or non-domain-controller identity roles to sensor v2.x instead. The research record locates this support at Opening applicability paragraph. - Eligible domain controllers can be activated automatically when discovered or manually by selecting servers from the inventory. The research record locates this support at Activation options section. The source support ends with the statements listed above. Use them to examine Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Activation state is not evidence of complete event auditing, identity configuration, or telemetry validation. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening applicability paragraph, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Activation options section, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening applicability paragraph; Activation options section. Favor sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Activate the Defender for Identity sensor v3.x on a domain controller](https://learn.microsoft.com/en-us/defender-for-identity/deploy/activate-sensor) — Microsoft ## Primary reference - Name: Activate the Defender for Identity sensor v3.x on a domain controller - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/activate-sensor - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Choose automatic or manual sensor activation from the domain-controller inventory,” DSE Security, https://update.dsesecurity.com/updates/choose-automatic-or-manual-sensor-activation/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose block access or DAX before deploying persistent-memory storage > Which persistent-memory access model matches the application and filesystem requirements? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-165-choose-block-access-or-dax-before-deploying-persistent-memory-storage/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:26+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which persistent-memory access model matches the application and filesystem requirements? ## Potentially affected Administrators evaluating persistent-memory storage on supported Windows Server platforms. ## DSE recommendation Have the application and storage owners choose the access model explicitly. ## Article ## Source facts Persistent memory retains its contents across power cycles and can be used as storage. Microsoft distinguishes block access through the normal filesystem and storage stacks from direct access, or DAX. Block access supports NTFS and ReFS; DAX is limited to NTFS. The guidance warns that incorrect DAX use can lose data and recommends a block translation table to reduce the risk of torn writes. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/deploy-persistent-memory). ## Applicability Identify the hardware, server release, application access model, filesystem, and supported deployment requirements. Review the application’s documented persistent-memory behavior before selecting DAX because of a latency goal. ## DSE recommendation Have the application and storage owners choose the access model explicitly. Record the required filesystem, protective configuration, and recovery method. Keep the access-model decision separate from whether a memory module is healthy or whether a persistent-memory region has been detected. ## Verification Deploy a representative supported test configuration and confirm that the application uses the intended access path. Validate controlled data writes and the approved recovery exercise, preserving configuration and outcome evidence. Investigate any unsupported access assumption before allowing important data onto the proposed design. ## Official references [Microsoft Learn: Understand and deploy persistent memory](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/deploy-persistent-memory). Source reviewed September 8, 2026. ## Primary reference - Name: Understand and deploy persistent memory - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/deploy-persistent-memory - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose block access or DAX before deploying persistent-memory storage,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-165-choose-block-access-or-dax-before-deploying-persistent-memory-storage/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose credible alternative release scenarios that reach an offsite endpoint > Use 40 CFR 68.28 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/choose-credible-alternative-release-scenarios-that-reach-an-offsite-endpoint/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:16+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.28 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.28 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Choose credible alternative release scenarios that reach an offsite endpoint. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.28 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.28) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that for each scenario required under paragraph (a) of this section, the owner or operator select a scenario: that will reach an endpoint offsite, unless no such scenario exists. The research record locates this support at 40 CFR 68.28(b)(1)(ii), read with 40 CFR 68.28(b)(1) (eCFR anchor p-68.28(b)(1)(ii)). - Under 40 CFR 68, the rule requires that the owner or operator identify and analyze at least one alternative release scenario for each regulated toxic substance held in a covered process(es) and at least one alternative release scenario to represent all flammable substances held in covered processes. The research record locates this support at 40 CFR 68.28(a) (eCFR anchor p-68.28(a)). The source support ends with the statements listed above. Use them to examine critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 40 CFR 68.28(b)(1)(ii), read with 40 CFR 68.28(b)(1) (eCFR anchor p-68.28(b)(1)(ii)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.28(a) (eCFR anchor p-68.28(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from 40 CFR 68.28(b)(1)(ii), read with 40 CFR 68.28(b)(1) (eCFR anchor p-68.28(b)(1)(ii)); 40 CFR 68.28(a) (eCFR anchor p-68.28(a)) to the observed environment. Useful domain evidence includes facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [40 CFR 68.28 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.28) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.28 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.28 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose credible alternative release scenarios that reach an offsite endpoint,” DSE Security, https://update.dsesecurity.com/updates/choose-credible-alternative-release-scenarios-that-reach-an-offsite-endpoint/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose dedicated or partitioned GPU access for Hyper-V workloads > Does a virtualized workload require a whole physical GPU or a partition of one? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-146-choose-dedicated-or-partitioned-gpu-access-for-hyper-v-workloads/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:45+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Does a virtualized workload require a whole physical GPU or a partition of one? ## Potentially affected Architects planning GPU acceleration for Hyper-V workloads on Windows Server. ## DSE recommendation Compare a dedicated-device design with a partitioned design using the actual application requirements. ## Article ## Source facts Microsoft distinguishes native GPU access on a physical Windows Server from the graphics virtualization needed inside Hyper-V VMs. Discrete Device Assignment dedicates one or more physical GPUs to a VM, which uses the native driver. Starting with Windows Server 2025, GPU partitioning lets multiple VMs receive dedicated portions of a physical GPU rather than each receiving the entire device. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-for-gpu-acceleration-in-windows-server). ## Applicability Identify the application, guest and host releases, GPU model, driver, and required features. Review the support requirements for the chosen mode, including any guest-platform restrictions, before deciding from density alone. ## DSE recommendation Compare a dedicated-device design with a partitioned design using the actual application requirements. Have the workload and virtualization owners document the required GPU resources and acceptable sharing model. Include maintenance and migration expectations in the design review and retain the supported configuration evidence. ## Verification Run the representative workload in the chosen supported configuration and inspect the GPU resources visible to the guest. Measure the agreed application tasks with the planned number of simultaneous VMs. Record unsupported features or an unmet performance target explicitly before approving the allocation model for wider use. ## Official references [Microsoft Learn: Plan for GPU acceleration in Windows Server](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-for-gpu-acceleration-in-windows-server). Source reviewed September 8, 2026. ## Primary reference - Name: Plan for GPU acceleration in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-for-gpu-acceleration-in-windows-server - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose dedicated or partitioned GPU access for Hyper-V workloads,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-146-choose-dedicated-or-partitioned-gpu-access-for-hyper-v-workloads/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose DFS referral ordering without losing an off-site access path > Compare DFS referral ordering choices, site-only limits, and the exception for explicitly prioritized targets. - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-017-choose-dfs-referral-ordering-without-losing-an-off-site-access-path/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:54+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Explainer - DSE priority: Information - Topics: Business Continuity, IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Compare DFS referral ordering choices, site-only limits, and the exception for explicitly prioritized targets. ## Potentially affected Administrators configuring referral ordering for DFS namespace roots or folders with targets. ## DSE recommendation Test referral results from each client site, including a site without an available local target, before changing ordering policy. ## Article ## Source facts [Microsoft’s DFS documentation](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/set-the-ordering-method-for-targets-in-referrals) describes referrals as ordered target lists: clients try the first target and move to the next when it is unavailable. The lowest-cost method places same-site targets first, then orders remote targets by cost; equal-cost targets are randomized. Without an overriding target priority, the site-only method returns only same-site targets; if none exist, the client receives no referral. Targets prioritized first or last across all targets remain in referrals despite site-only ordering. ## Applicability Decide whether the change concerns the namespace root or a folder. Review client site placement and the intended target set. Treat a requirement to avoid remote access and a requirement to retain access during a local outage as separate business decisions that need an owner. ## DSE recommendation Write down the intended outcome for each site before choosing the ordering method. Include the normal local target, acceptable remote alternatives, and conditions under which access should deliberately be unavailable. Ask the application or file-service owner to approve that last condition explicitly. Preserve the prior ordering configuration so the change can be reversed. ## Verification Collect actual referrals and successful file-access results from representative clients. Repeat the exercise with an approved unavailable-target scenario and with a client site lacking a local target. Compare the returned order with the approved design. Record the target actually reached, not merely whether the namespace name resolved. ## Official references [Microsoft Learn: Set the Ordering Method for Targets in Referrals](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/set-the-ordering-method-for-targets-in-referrals). Source reviewed September 8, 2026. ## Primary reference - Name: Set the Ordering Method for Targets in Referrals - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/set-the-ordering-method-for-targets-in-referrals - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose DFS referral ordering without losing an off-site access path,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-017-choose-dfs-referral-ordering-without-losing-an-off-site-access-path/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose GRE endpoints for a tenant-to-physical-network connection > Where do GRE endpoints sit when a tenant virtual network needs a provider-side physical service? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-009-choose-gre-endpoints-for-a-tenant-to-physical-network-connection/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:17:02+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Where do GRE endpoints sit when a tenant virtual network needs a provider-side physical service? ## Potentially affected Use this review when designing a specific provider-side service path for a tenant. ## DSE recommendation Draw the tunnel endpoints and the traffic path to the physical service. ## Article ## Source facts Microsoft’s GRE implementation can encapsulate IPv4 and IPv6 through virtual point-to-point links over an IP network. In the documented tenant-to-physical-network scenario, one tunnel endpoint is a multitenant gateway and the other is a third-party device on the provider’s physical network. Layer 3 traffic is routed between tenant VMs and that device. Another documented scenario connects a VLAN-isolated physical load balancer to the virtual network through GRE. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-access/ras-gateway/gre-tunneling-windows-server). ## Applicability Use this review when designing a specific provider-side service path for a tenant. Identify the gateway, physical device, tenant network, and required routing behavior. Confirm support on both endpoints before selecting this topology. ## DSE recommendation Draw the tunnel endpoints and the traffic path to the physical service. Have the tenant and provider network owners agree on which routes and service addresses are in scope. Record the third-party device’s role and the configuration owner at each end. Keep the endpoint design distinct from any separate performance, packet-size, or confidentiality requirement. ## Verification Test a representative tenant connection to the intended physical service and record the actual endpoint and routing context. Include a tenant that should not reach that service. Compare both results with the approved diagram and investigate an unexpected cross-tenant path before accepting the connection. Preserve the mapping for later device replacement. ## Official references [Microsoft Learn: GRE Tunneling in Windows Server 2016](https://learn.microsoft.com/en-us/windows-server/remote/remote-access/ras-gateway/gre-tunneling-windows-server). Source reviewed September 8, 2026. ## Primary reference - Name: GRE Tunneling in Windows Server 2016 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-access/ras-gateway/gre-tunneling-windows-server - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose GRE endpoints for a tenant-to-physical-network connection,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-009-choose-gre-endpoints-for-a-tenant-to-physical-network-connection/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose Hyper-V import identity and running-file locations > When should an imported virtual machine keep its identity or receive a new one? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-248-choose-hyper-v-import-identity-and-running-file-locations/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:03+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know When should an imported virtual machine keep its identity or receive a new one? ## Potentially affected Operators importing exported Hyper-V virtual machines into a host. ## DSE recommendation Write down the intended identity relationship between the original and imported machine, along with the final configuration and disk locations. ## Article ## Source facts Registering a virtual machine in place preserves its identity and turns the export location into its running-file location. The copy import option lets the operator choose a file location and assigns a new virtual-machine identity, allowing repeated imports to the same host. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/Export-and-import-virtual-machines). ## Applicability Decide whether the request is to register an existing workload or create a separate copy before choosing the import type. Identify any already-registered instance. Treat the export directory as potentially live storage until the selected import behavior is understood. ## DSE recommendation Write down the intended identity relationship between the original and imported machine, along with the final configuration and disk locations. Keep the source export under change control while the choice is reviewed. For a separate test copy, plan its network isolation and application identity handling with the workload owner. Do not remove an existing registration merely to clear an import error without that owner’s approval. ## Verification Inspect the imported machine identifier and all attached disk paths before starting it. Confirm that the running-file locations match the chosen import type. Mark any export directory now serving as live storage so it is not cleaned up as disposable transfer material. Start the workload only in its approved network context. ## Official references [Microsoft Learn: Export and import virtual machines](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/Export-and-import-virtual-machines). Source reviewed September 8, 2026. ## Primary reference - Name: Export and import virtual machines - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/Export-and-import-virtual-machines - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose Hyper-V import identity and running-file locations,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-248-choose-hyper-v-import-identity-and-running-file-locations/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose manual or automatic LAPS account management explicitly > Use Windows LAPS account management modes to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/choose-laps-account-management-mode-explicitly/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:02+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Windows LAPS account management modes to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Windows LAPS account management modes ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Choose manual or automatic LAPS account management explicitly. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Windows LAPS account management modes](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-concepts-account-management-modes) from Microsoft supports the following bounded statements: - Windows LAPS supports distinct manual and automatic local-account management modes. The research record locates this support at Sections: Manual account management mode; Automatic account management mode. - Automatic account management requires Windows 11 24H2, Windows Server 2025, or later. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Do not enable automatic account creation or naming until OS support and local-account policy interaction are tested. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Sections: Manual account management mode; Automatic account management mode, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios are in and out of scope? - Which condition in Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to Sections: Manual account management mode; Automatic account management mode; Opening overview and to observable material such as policy exports, directory access-control entries, sanitized client events, rotation tests, retrieval authorization, and exception records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Windows LAPS account management modes](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-concepts-account-management-modes) — Microsoft ## Primary reference - Name: Windows LAPS account management modes - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-concepts-account-management-modes - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Choose manual or automatic LAPS account management explicitly,” DSE Security, https://update.dsesecurity.com/updates/choose-laps-account-management-mode-explicitly/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose Microsoft 365 Apps update channels by job, then manage the exceptions > Microsoft 365 Apps channels are device settings with different feature and support cadences. Put preview users, representative production pilots, general users, and exception devices on deliberate paths—and monitor the build actually installed. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-365-apps-update-channels-by-job/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:21:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Microsoft 365 Apps channels are device settings with different feature and support cadences. Put preview users, representative production pilots, general users, and exception devices on deliberate paths—and monitor the build actually installed. ## Potentially affected Microsoft 365 Apps for enterprise and business on Windows; subscription Project and Visio; Office Deployment Tool, Group Policy, Microsoft 365 Apps admin center, Intune, Configuration Manager, and Office CDN delivery. ## DSE recommendation Inventory installed channel and build by device, define preview, pilot, production, and exception populations, align support windows with change needs, and reconcile devices that drift from the approved channel or supported build. ## Article ## Source facts: the channel belongs to the device Microsoft’s [update-channel overview](https://learn.microsoft.com/en-us/microsoft-365-apps/updates/overview-update-channels) describes Current Channel, Monthly Enterprise Channel, Semi-Annual Enterprise Channel, and preview options for Microsoft 365 Apps on Windows. Current Channel is the default for Microsoft 365 Apps for enterprise and business and for subscription Project and Visio when no other channel is specified. The channel is device-specific; it does not follow a person between computers. A device can use only one Microsoft 365 Apps channel, and subscription Office, Project, and Visio installed together on that device must use the same channel. One organization may deliberately use different channels for different device groups, but users can then see different feature sets while collaborating. Current Channel delivers features as they become ready and commonly has multiple releases in a month. Monthly Enterprise Channel provides a more predictable monthly feature cadence. Semi-Annual Enterprise Channel continues with January and July feature releases, but Microsoft’s current documentation says that beginning in July 2026 each feature release is supported for one month, followed by a two-month rollback period in which the previous feature release can receive updates—an effective three-month operating window that is materially shorter than the former model. Current Channel versions are generally supported only until the next Current Channel version arrives. Microsoft 365 Apps updates are cumulative Click-to-Run builds, not a menu of individually selected Office fixes from Windows Update. Microsoft recommends the Office content delivery network for many Current and Monthly Enterprise deployments and describes Delivery Optimization as a way to reduce repeated network transfer. OneDrive and Teams have separate update processes and are not governed by the Microsoft 365 Apps channel. ## DSE recommendation: create a channel map with measurable exit rules Start with business roles, application dependencies, and support tolerance. A channel should answer who receives a change, when they receive it, how the result is observed, and what happens when a build cannot advance. - Discovery group. Place a small set of IT staff and application owners on Current Channel (Preview) where appropriate. They should exercise upcoming behavior with real add-ins, templates, macros, document workflows, printing, and line-of-business integrations. - Production pilot. Use a representative subset on the intended production channel. Include different hardware, languages, remote and office locations, shared devices, accessibility tooling, and the business units with important Office automation. - Broad population. Select Current Channel or Monthly Enterprise Channel according to the organization’s need for feature timing and a repeatable change rhythm. Do not assume the default is a documented decision. - Named exceptions. Keep an owner, justification, target channel, required build, expiration date, and remediation plan for every device that cannot follow the standard. Reassess exceptions before their channel version leaves support. Before changing channels, inventory the channel, version, build, architecture, language packs, update source, and management authority actually present on each device. Microsoft notes that moving from a faster channel to Semi-Annual Enterprise can remove features not yet available there. Test the change on a pilot and communicate any feature difference rather than treating a channel move as invisible maintenance. Monitor installed outcomes, not merely assigned policy. Useful measures include devices on the intended channel, devices on a supported build, time to adopt the approved release, failed or stalled updates, add-in or macro incidents, restart completion, help-desk contacts, and exception age. Validate Word, Excel, Outlook, PowerPoint, Project, and Visio workflows that matter to the organization; a successful installation alone does not prove those workflows. Review Microsoft’s channel documentation and update history on a recurring schedule because servicing windows can change—as the July 2026 Semi-Annual Enterprise change demonstrates. The goal is not to make every device identical. It is to make every difference intentional, supported, observable, and temporary where possible. ## Official references - Microsoft Learn, [Overview of update channels for Microsoft 365 Apps](https://learn.microsoft.com/en-us/microsoft-365-apps/updates/overview-update-channels), May 27, 2026. - Microsoft Learn, [Overview of the update process for Microsoft 365 Apps](https://learn.microsoft.com/en-us/microsoft-365-apps/updates/overview-update-process-microsoft-365-apps). ## Primary reference - Name: Microsoft Learn: Overview of update channels for Microsoft 365 Apps - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/microsoft-365-apps/updates/overview-update-channels - Source publication date: 2026-05-27 ## Citation and use Preferred citation: “Choose Microsoft 365 Apps update channels by job, then manage the exceptions,” DSE Security, https://update.dsesecurity.com/updates/microsoft-365-apps-update-channels-by-job/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose node recovery or cluster-configuration recovery deliberately > When does a Storage Spaces Direct recovery require restoring cluster configuration authoritatively? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-210-choose-node-recovery-or-cluster-configuration-recovery-deliberately/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:41+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know When does a Storage Spaces Direct recovery require restoring cluster configuration authoritatively? ## Potentially affected Administrators planning backup-based recovery of S2D cluster nodes and configuration. ## DSE recommendation Have the cluster and workload owners document what must be recovered and which current state must be preserved. ## Article ## Source facts Microsoft distinguishes nonauthoritative restoration of a cluster node from authoritative restoration of the cluster configuration. A nonauthoritative restore is described for recovering a node when the current cluster information remains good. An authoritative restore returns cluster configuration to an earlier state and is reserved for cases where that configuration itself was lost. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/Storage-Spaces-Direct-Disaster-Recovery). ## Applicability Determine whether the failure concerns one node, application data, or the shared cluster configuration. Identify a suitable backup and compare its scope and time with the incident. Do not choose an authoritative operation simply because a node is unavailable. ## DSE recommendation Have the cluster and workload owners document what must be recovered and which current state must be preserved. Name the restore point and explain why its configuration is appropriate. Use a representative recovery exercise to distinguish node repair from restoring a deleted or lost cluster resource definition. Keep the selected recovery type and its approval visible in the runbook. ## Verification After the approved exercise, verify node membership, resource definitions, workload ownership, and the application’s expected behavior. Compare restored configuration with the chosen backup and with any legitimate changes made afterward. Record which state was intentionally returned to an earlier point. Resolve unexplained configuration loss before treating the recovery as complete. ## Official references [Microsoft Learn: Disaster Recovery Scenarios for Storage Spaces Direct in Windows Server](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/Storage-Spaces-Direct-Disaster-Recovery). Source reviewed September 8, 2026. ## Primary reference - Name: Disaster Recovery Scenarios for Storage Spaces Direct in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/Storage-Spaces-Direct-Disaster-Recovery - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose node recovery or cluster-configuration recovery deliberately,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-210-choose-node-recovery-or-cluster-configuration-recovery-deliberately/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose notification or enforcement when creating an FSRM file screen > Should an FSRM file screen block matching files or only report them? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-069-choose-notification-or-enforcement-when-creating-an-fsrm-file-screen/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:02+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Should an FSRM file screen block matching files or only report them? ## Potentially affected Use this review when creating a screen for a defined file-service policy. ## DSE recommendation Prepare examples of files that should match and files that should remain unaffected. ## Article ## Source facts Microsoft distinguishes active file screening, which prevents saving files in blocked groups and can notify administrators, from passive screening, which sends configured notifications without blocking the save. A file screen applies to its selected folder and all subfolders. A template can retain a relationship with derived screens so later template changes can be applied to them. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/fsrm/create-file-screen). ## Applicability Use this review when creating a screen for a defined file-service policy. Identify the folder tree, file groups, notification recipients, and data owner. Choose the behavior deliberately before configuring the screen. ## DSE recommendation Prepare examples of files that should match and files that should remain unaffected. Have the owner decide whether the first deployment should observe activity or prevent it. Review inherited template relationships alongside the folder scope. Tell support staff what users should experience and who will review the notifications, and preserve the original configuration before enabling enforcement. ## Verification Test matching and nonmatching files in the selected folder and a representative subfolder. Record whether saving was allowed and whether the expected notification arrived. Inspect a location outside the scope to confirm the intended boundary. Reconcile incorrect matches or missing notifications before broadening the screen or switching from passive observation to active blocking. ## Official references [Microsoft Learn: Create a File Screen](https://learn.microsoft.com/en-us/windows-server/storage/fsrm/create-file-screen). Source reviewed September 8, 2026. ## Primary reference - Name: Create a File Screen - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/fsrm/create-file-screen - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose notification or enforcement when creating an FSRM file screen,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-069-choose-notification-or-enforcement-when-creating-an-fsrm-file-screen/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose parallel or fallback destinations for NPS accounting > Should NPS write accounting records to both SQL and text, or use text only after SQL failure? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-105-choose-parallel-or-fallback-destinations-for-nps-accounting/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:26+00:00 - Modified: 2026-09-08T18:23:26+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Should NPS write accounting records to both SQL and text, or use text only after SQL failure? ## Potentially affected Administrators configuring Network Policy Server accounting destinations. ## DSE recommendation Have the authentication and database teams agree on the selected mode and ownership of failure alerts. ## Article ## Source facts NPS can record accounting for authentication requests, acceptance and rejection messages, accounting exchanges, and periodic status updates. Microsoft offers text-only and SQL-only destinations, as well as two combined modes. Parallel logging writes to both destinations simultaneously. SQL logging with backup uses the text destination if SQL logging fails. NPS event logging is a separate facility used principally to audit and troubleshoot connection attempts. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-accounting-configure). ## Applicability Identify the accounting consumers, selected destination, database owner, retention requirements, and handling rules. Distinguish a requirement for simultaneous copies from a requirement for a fallback during a database outage. ## DSE recommendation Have the authentication and database teams agree on the selected mode and ownership of failure alerts. Document where operators should look for records during normal operation and during a logging failure. Review destination access and capacity before enabling the chosen accounting path. ## Verification Generate controlled accepted and rejected connection attempts and reconcile their timestamps with the expected records. In an approved test, make the SQL destination unavailable and inspect the documented fallback behavior. Record missing events or ambiguous destination ownership before relying on the accounting collection for investigations. ## Official references [Microsoft Learn: Configure Network Policy Server Accounting](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-accounting-configure). Source reviewed September 8, 2026. ## Primary reference - Name: Configure Network Policy Server Accounting - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-accounting-configure - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose parallel or fallback destinations for NPS accounting,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-105-choose-parallel-or-fallback-destinations-for-nps-accounting/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose personal RDS host assignment and privileges independently > How should personal-session host assignment be separated from granting administrator rights? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-148-choose-personal-rds-host-assignment-and-privileges-independently/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:43+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How should personal-session host assignment be separated from granting administrator rights? ## Potentially affected Administrators configuring Remote Desktop Services personal session collections. ## DSE recommendation Prepare a user-to-host allocation record and approve privileges independently of assignment. ## Article ## Source facts Microsoft’s personal-session collection parameter associates users with their own session hosts instead of assigning the next available host at sign-in. A separate option grants the assigned user administrative privileges; omitting it leaves standard-user privileges. Automatic assignment also has its own option. With it, a new user needs an unassigned host or receives an error; without it, an administrator must assign the host before sign-in. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-personal-session-desktops). ## Applicability Identify the intended users, available hosts, assignment method, privilege requirement, and collection. Review whether a personal host is needed and whether local administrative rights are separately justified. ## DSE recommendation Prepare a user-to-host allocation record and approve privileges independently of assignment. Have the service owner define who can reassign a host and how departing users are handled. Check available unassigned capacity before enabling automatic assignment for additional users. ## Verification Query the collection’s actual associations and sign in with representative assigned and unassigned users. Check the resulting host and privilege level, including the no-capacity case in an approved test. Record an unexpected assignment or excessive privilege as a configuration failure before opening the collection more broadly. ## Official references [Microsoft Learn: Use personal session desktops with Remote Desktop Services](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-personal-session-desktops). Source reviewed September 8, 2026. ## Primary reference - Name: Use personal session desktops with Remote Desktop Services - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-personal-session-desktops - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose personal RDS host assignment and privileges independently,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-148-choose-personal-rds-host-assignment-and-privileges-independently/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose Storage bus cache provisioning mode before enabling the feature > Which Storage bus cache choice must be made before enablement on a standalone server? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-134-choose-storage-bus-cache-provisioning-mode-before-enabling-the-feature/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:57+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which Storage bus cache choice must be made before enablement on a standalone server? ## Potentially affected Administrators evaluating Storage bus cache on standalone Windows Server storage. ## DSE recommendation Write down the intended use of the faster media before enabling the cache. ## Article ## Source facts Storage bus cache combines faster and slower media into tiers on a standalone server. Microsoft’s default reserves only part of the faster tier for caching. Provision Mode determines whether all or part of the faster tier is used as cache. Microsoft states that this field cannot be changed after enabling the feature. The instructions require any necessary configuration to be completed before enablement. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-storage-bus-cache). ## Applicability Check the exact server release, media combination, installed features, and volume design against the source prerequisites. Distinguish this standalone feature from Storage Spaces Direct caching across cluster nodes. ## DSE recommendation Write down the intended use of the faster media before enabling the cache. Have the storage owner review the capacity allocated to cache and to workload storage, including the selected Provision Mode. Retain the current disk inventory and approved recovery procedure before changing the storage configuration. ## Verification Inspect the resulting mode, device roles, and capacity allocation and compare them with the approved design. Measure a representative workload under documented conditions and record any unresolved discrepancy. Do not assume that a successful enablement proves the chosen split meets the application’s capacity or performance needs. ## Official references [Microsoft Learn: Storage bus cache on Storage Spaces](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-storage-bus-cache). Source reviewed September 8, 2026. ## Primary reference - Name: Storage bus cache on Storage Spaces - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-storage-bus-cache - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose Storage bus cache provisioning mode before enabling the feature,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-134-choose-storage-bus-cache-provisioning-mode-before-enabling-the-feature/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose strict, feasible, or loose uRPF for asymmetric routing paths > Use RFC 3704 — Ingress Filtering for Multihomed Networks to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/choose-strict-feasible-or-loose-urpf-for-asymmetric-routing-paths/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:35+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3704 — Ingress Filtering for Multihomed Networks to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3704 — Ingress Filtering for Multihomed Networks ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Choose strict, feasible, or loose uRPF for asymmetric routing paths. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3704 — Ingress Filtering for Multihomed Networks](https://www.rfc-editor.org/rfc/rfc3704.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Strict reverse-path forwarding accepts a source only when the packet arrived on the interface selected by the best forwarding path back to that source. The research record locates this support at Section 2.2 (Strict Reverse Path Forwarding). - Feasible-path reverse-path forwarding also treats routing-protocol-derived alternative paths as valid, accommodating multihoming and asymmetric routing better than strict mode. The research record locates this support at Section 2.3 (Feasible Path Reverse Path Forwarding). - Loose reverse-path forwarding checks only that some route to the source exists, which tolerates asymmetry but rejects only unrouted or martian sources when no route is present. The research record locates this support at Sections 2.4 (Loose Reverse Path Forwarding) and 4.1 (Use Loose RPF When Appropriate). The source support ends with the statements listed above. Use them to examine address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 2.2 (Strict Reverse Path Forwarding), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.3 (Feasible Path Reverse Path Forwarding), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 2.4 (Loose Reverse Path Forwarding) and 4.1 (Use Loose RPF When Appropriate), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Section 2.2 (Strict Reverse Path Forwarding); Section 2.3 (Feasible Path Reverse Path Forwarding); Sections 2.4 (Loose Reverse Path Forwarding) and 4.1 (Use Loose RPF When Appropriate) through configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 3704 — Ingress Filtering for Multihomed Networks](https://www.rfc-editor.org/rfc/rfc3704.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 3704 — Ingress Filtering for Multihomed Networks - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3704.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose strict, feasible, or loose uRPF for asymmetric routing paths,” DSE Security, https://update.dsesecurity.com/updates/choose-strict-feasible-or-loose-urpf-for-asymmetric-routing-paths/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose Teams external access, guest access, or neither for each collaboration need > Teams external access supports chat, calls, meetings, and separately enabled file sharing in federated chats, while guest access creates an Entra B2B identity for team and broader resource collaboration. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-teams-external-versus-guest-access/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:15+00:00 - Modified: 2026-07-19T21:28:15+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Teams external access supports chat, calls, meetings, and separately enabled file sharing in federated chats, while guest access creates an Entra B2B identity for team and broader resource collaboration. ## Potentially affected Microsoft Teams organizations collaborating with vendors, customers, partners, unmanaged Teams accounts, other Microsoft 365 tenants, or guests who need access to team resources. ## DSE recommendation Classify the collaboration need, inventory current tenant controls and guests, choose the least-access model, test cross-tenant behavior, enforce sponsorship and expiry, and audit removal. ## Article ## Source fact: what Microsoft documents Microsoft Teams external access lets users find, chat with, call, and meet people who use supported Microsoft identities outside the organization. It does not make an external user a member of a team. Direct file upload in external or federated chats is off by default, but administrators can enable it through the Teams files policy. When enabled, files remain in the sender’s OneDrive and existing Microsoft 365, SharePoint/OneDrive, and Microsoft Entra policies continue to apply. When direct upload is disabled, users can still paste existing file links into the chat. Guest access adds an external person to a team and creates or uses a Microsoft Entra B2B guest account in the tenant. A guest can collaborate in channels, meetings, applications, and files according to Teams, Microsoft 365 Groups, SharePoint, and Entra configuration. Guests sign in to the host organization and may need to switch organizations in Teams. Microsoft notes that access can take up to 12 hours after addition. Public preview: Microsoft labels automatic permission sharing for files and Loop components uploaded to external chats as public preview. Microsoft also labels guest-initiated sharing from a guest’s home-tenant OneDrive as public preview; those files remain stored in the guest’s home organization. Neither preview capability should be assumed available or treated as generally available for every tenant. Shared channels provide another external-collaboration model without the same guest-account experience. The right choice depends on identity, content, tenant, channel, and application requirements. Leaving a team does not delete the Entra guest object. ## Licensing and applicability Microsoft documents guest access for Microsoft 365 Business Standard, Enterprise, and Education subscriptions without an extra Microsoft 365 license for the guest. Microsoft Entra External ID billing and Microsoft 365 or Entra service limits still apply. Cross-cloud, government, sovereign, unmanaged-account, shared-channel, Conditional Access, sensitivity-label, compliance, and application behavior differ. Verify the source and target tenant combination. ## DSE recommendation: production-safe operational steps - Document whether the external person needs communication only, file or Loop sharing in an external chat, or persistent team, channel, application, and content access. - Inventory organization-wide external-access settings, allowed and blocked domains, unmanaged-account policy, Teams files policy, preview auto-sharing policy, guest settings, existing guest objects, team ownership, shared channels, and SharePoint and OneDrive sharing. - Choose external access when federated communication and, if approved, separately enabled chat file sharing are sufficient. Use guest or shared-channel collaboration only when the documented content and membership need justifies it. - Require a named internal sponsor, purpose, expected end date, approved organization, and data classification before persistent collaboration. - Test sign-in, tenant switching, chat, meetings, direct upload enabled and disabled, pasted links, file permissions, applications, mobile access, Conditional Access, invitation redemption, and removal with a representative external identity. - Audit guest creation and team membership, review access periodically, and notify sponsors before expiry. - At the end of collaboration, remove team or channel access, revoke applicable sessions and links, and remove stale Entra guest objects according to the retention process. DSE recommends avoiding a tenant-wide relaxation to solve one partner’s access problem. Troubleshoot the relevant Teams, Entra, group, SharePoint, cross-tenant, and licensing layer. Document any exception with a sponsor and expiration instead of making it permanent. ## Official references - [Use guest access and external access to collaborate with people outside your organization](https://learn.microsoft.com/en-us/microsoftteams/communicate-with-users-from-other-organizations) — external and guest identity models, defaults, cross-cloud notes, and collaboration choices. - [Share Files and Loop components in external chats](https://learn.microsoft.com/en-us/microsoftteams/share-files-loop-in-external-chats) — file-policy controls, OneDrive storage, governing policies, and public-preview capabilities. ## Primary reference - Name: Microsoft Learn: Use guest access and external access to collaborate with people outside your organization - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/microsoftteams/communicate-with-users-from-other-organizations - Source publication date: 2026-07-01 ## Citation and use Preferred citation: “Choose Teams external access, guest access, or neither for each collaboration need,” DSE Security, https://update.dsesecurity.com/updates/microsoft-teams-external-versus-guest-access/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose the authoritative node before forced-quorum recovery > What decisions must precede force-starting a cluster that has lost quorum? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-179-choose-the-authoritative-node-before-forced-quorum-recovery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:12+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What decisions must precede force-starting a cluster that has lost quorum? ## Potentially affected Administrators recovering a Windows Server failover cluster without quorum. ## DSE recommendation Prepare a recovery worksheet naming the selected node, unavailable components, data-state assessment, and personnel controlling the remaining nodes. ## Article ## Source facts Microsoft first directs administrators to investigate the quorum configuration and the reason the cluster lost sufficient votes. When healthy nodes or the witness cannot restore quorum, force-starting overrides the normal quorum configuration. After one node is force-started, Microsoft directs remaining nodes to start with quorum prevented so they join the running cluster instead of forming a competing instance. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/failover-clustering/recover-failover-cluster-without-quorum). ## Applicability Confirm which nodes and sites are reachable and who controls the recovery operation. Distinguish an ordinary unavailable witness from a situation requiring forced recovery. Use the documented procedure only after the responsible cluster administrator establishes the intended authoritative instance. ## DSE recommendation Prepare a recovery worksheet naming the selected node, unavailable components, data-state assessment, and personnel controlling the remaining nodes. Require a shared decision before executing force-start actions. Keep the planned sequence visible to every operator involved, and explicitly assign responsibility for preventing a second competing instance. Retain the original quorum observations and the reason ordinary restoration was not possible. ## Verification After the approved recovery sequence, verify cluster membership, workload ownership, and application data with the service owner. Confirm that returning nodes join the intended instance. Record every deviation and stop if competing ownership or unexplained state appears. Complete a follow-up review of the quorum failure rather than treating service startup as the entire recovery. ## Official references [Microsoft Learn: Recover a failover cluster without quorum in Windows Server](https://learn.microsoft.com/en-us/windows-server/failover-clustering/recover-failover-cluster-without-quorum). Source reviewed September 8, 2026. ## Primary reference - Name: Recover a failover cluster without quorum in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/recover-failover-cluster-without-quorum - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose the authoritative node before forced-quorum recovery,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-179-choose-the-authoritative-node-before-forced-quorum-recovery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose the correct Storage Spaces Direct deployment branch > Which steps apply to converged versus hyperconverged Storage Spaces Direct deployment? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-081-choose-the-correct-storage-spaces-direct-deployment-branch/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:50+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Which steps apply to converged versus hyperconverged Storage Spaces Direct deployment? ## Potentially affected Use this review before beginning a Windows Server Storage Spaces Direct installation. ## DSE recommendation Map the chosen topology to the source's deployment stages and assign an owner to each prerequisite. ## Article ## Source facts Microsoft documents converged, also called disaggregated, and hyperconverged deployment options. Its initial three deployment stages apply to both, while the fourth stage is only needed for converged deployment. The Windows Server procedure requires Datacenter edition and permits either Server Core or Desktop Experience. The management computer must meet the documented version, network, domain-trust, and administration-tool requirements. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/deploy-storage-spaces-direct). ## Applicability Use this review before beginning a Windows Server Storage Spaces Direct installation. Identify whether storage and compute are separated or combined, the selected server edition, and the management host that will run the procedure. ## DSE recommendation Map the chosen topology to the source’s deployment stages and assign an owner to each prerequisite. Verify management access before making storage changes. Have the infrastructure owners review the node inventory and selected installation option. Keep the initial build record distinct from later decisions about volume geometry, resiliency, and workload placement. ## Verification At each approved stage, inspect the actual state and preserve the required validation output. Confirm that the management host can operate the intended servers through the supported tools. Before accepting the deployment, compare the completed stages with the selected topology and test the intended storage-consuming workload. Resolve an omitted or inapplicable stage before production use. ## Official references [Microsoft Learn: Deploy Storage Spaces Direct on Windows Server](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/deploy-storage-spaces-direct). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy Storage Spaces Direct on Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/deploy-storage-spaces-direct - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose the correct Storage Spaces Direct deployment branch,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-081-choose-the-correct-storage-spaces-direct-deployment-branch/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose the disk and installation path for a new Hyper-V guest > What must be decided before finishing the new virtual-machine wizard? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-236-choose-the-disk-and-installation-path-for-a-new-hyper-v-guest/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:15+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What must be decided before finishing the new virtual-machine wizard? ## Potentially affected Administrators provisioning a new guest on an already-enabled Hyper-V host. ## DSE recommendation Have the workload owner decide whether to create a new disk or attach an approved existing one. ## Article ## Source facts The Hyper-V wizard permits a new virtual disk, an existing virtual disk, or attaching a disk later. Network attachment can be deferred if a virtual switch has not yet been created. The wizard includes an option to install the guest operating system later. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Create-a-virtual-machine-in-Hyper-V). ## Applicability Start with the workload’s approved disk image or installation media and its intended storage locations. Distinguish an empty VM configuration from an installed operating system. Select generation and startup resources from the supported requirements of the intended guest, not a copied example. ## DSE recommendation Have the workload owner decide whether to create a new disk or attach an approved existing one. Record the configuration-file location, disk path, installation source, and intended network before completing the wizard. For an unfinished or unqualified image, leave network attachment for the approved follow-up step. Review the wizard summary against that record before allowing the new guest to start. ## Verification Inspect the resulting VM settings and confirm that the disk path and boot source are the intended ones. Start it in the approved test context and observe whether it boots the existing image or begins the expected installation. Record any deliberately deferred disk, operating-system, or network work before handing the guest to its owner. ## Official references [Microsoft Learn: Create a virtual machine in Hyper-V](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Create-a-virtual-machine-in-Hyper-V). Source reviewed September 8, 2026. ## Primary reference - Name: Create a virtual machine in Hyper-V - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Create-a-virtual-machine-in-Hyper-V - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose the disk and installation path for a new Hyper-V guest,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-236-choose-the-disk-and-installation-path-for-a-new-hyper-v-guest/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose the right DSE channel: Updates, helpdesk, or main site > Use DSE Updates for public advisories and education, the DSE support library and helpdesk for customer-specific documentation and service requests, and the main DSE Security site for capabilities, assessments, projects, and contact routing. - Canonical URL: https://update.dsesecurity.com/updates/choose-dse-updates-helpdesk-main-site/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:57+00:00 - Modified: 2026-07-19T19:03:57+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Information - Topics: DSE World - Reading time: 2 minutes ## What you need to know Use DSE Updates for public advisories and education, the DSE support library and helpdesk for customer-specific documentation and service requests, and the main DSE Security site for capabilities, assessments, projects, and contact routing. ## Potentially affected Visitors, customers, prospects, and staff deciding where to find guidance or send a question or service request. ## DSE recommendation Match the need to the channel below, confirm the exact HTTPS domain, and keep customer-specific or sensitive material out of public pages. ## Article DSE maintains different public and customer-facing channels because a general advisory, a support request, and a new project conversation require different context and handling. Choosing the correct channel helps keep public guidance useful and customer information in the appropriate workflow. ## DSE Updates: public education and advisories Use update.dsesecurity.com for public articles about security, managed technology, lifecycle planning, vendor or government guidance, and broadly applicable actions. Updates should explain the source, affected audience, review date, recommended next step, and important limits. DSE recommendation: use an Updates article to understand an issue and prepare questions. Do not assume that a public alert proves a particular customer device, account, site, or service is affected. Customer applicability requires current inventory and configuration evidence. ## Support library and helpdesk: documentation and active requests Use help.dsesecurity.com for DSE’s self-service support documentation. The public library covers ticket workflows and customer-safe preparation and troubleshooting guidance. When a customer-specific issue needs triage, use the production ticket path identified by the help center, including the signed-in portal at helpdesk.dsesecurity.com. A support request should identify the company and site, affected user or device, observed behavior, start time, scope of impact, and safe evidence. Reply on the same DSE ticket when continuing an existing issue so the history remains together. Confirm the exact HTTPS domain and signed-in account before entering customer information. Do not place passwords, MFA codes, recovery keys, private keys, full payment-card data, or unrelated customer records in a ticket. Redact screenshots and attachments to the information needed for the request. ## Main site: services, assessments, and new work Use dsesecurity.com to review DSE’s published commercial security, financial security, managed IT, networking, Microsoft cloud, voice, and cybersecurity capabilities. Its contact page routes new assessments, project conversations, security service, and managed IT support to the appropriate path. DSE recommendation: use the main-site contact path when planning new work, requesting an assessment, or discussing a service that is not already an active ticket. Use the helpdesk for an existing customer issue that needs tracking and response. ## Urgent and safety-related situations Web content and ordinary tickets are not substitutes for emergency services. For immediate danger, fire, crime in progress, or a life-safety emergency, contact the appropriate emergency authority first. Then follow the organization’s approved escalation procedure. Avoid making uncontrolled changes to locks, access control, alarms, power, networks, or security systems during an urgent event. ## Quick routing rule - Learn about a public issue: DSE Updates. - Follow a documented support workflow: DSE support library. - Report or continue a customer-specific problem: DSE helpdesk. - Explore services or start a project: main DSE Security site. ## Primary reference - Name: DSE Security contact and support routing - Authority: DSE Security - URL: https://dsesecurity.com/contact-us/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose the right DSE channel: Updates, helpdesk, or main site,” DSE Security, https://update.dsesecurity.com/updates/choose-dse-updates-helpdesk-main-site/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose the shutter architecture after measuring target motion > Rolling and global shutters expose a scene differently. Select between them only after defining target speed, direction, exposure time, illumination, and the image detail the operator or analytic must preserve. - Canonical URL: https://update.dsesecurity.com/updates/choose-global-rolling-shutter-from-target-motion/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Robert Dix - Published: 2026-08-11T10:18:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Advisory - Topics: Video Surveillance - Reading time: 3 minutes ## What you need to know Rolling and global shutters expose a scene differently. Select between them only after defining target speed, direction, exposure time, illumination, and the image detail the operator or analytic must preserve. ## Potentially affected Cameras viewing fast vehicles, conveyors, rotating machinery, gates, production lines, sports activity, strobed illumination, and other scenes where objects cross the image rapidly. ## DSE recommendation Measure the target motion and required detail, test candidate cameras with the production lens and illumination, and accept the shutter design only from recorded day-and-night sequences at the real operating speed. ## Article ## Source facts: motion blur and rolling-shutter distortion are different Axis Communications’ July 2026 white paper, [Global shutter vs rolling shutter](https://whitepapers.axis.com/en-us/global-shutter-vs-rolling-shutter), explains that a rolling-shutter sensor exposes its pixel rows at slightly different times. A global-shutter sensor exposes all pixels simultaneously and stores the result before row-by-row readout. The timing offset in a rolling shutter can distort fast motion: a passing vehicle may tilt, a golf club may appear bent, or rotating blades may lose their true shape. This distortion is not the same as motion blur. Exposure duration causes blur; the offset between row exposures causes rolling-shutter distortion. A longer exposure can smear the distortion until it is less obvious, but it does not remove it. Conversely, a very short exposure can freeze the object while revealing the rolling-shutter shape error more clearly. Axis notes that modern rolling-shutter sensors produce clean results in most ordinary surveillance scenes. The effect becomes important when objects move very quickly across the image, rotate rapidly, or must be measured by their true shape. Resolution and sensor readout time also affect the amount of distortion. A global shutter is therefore a use-case decision, not an automatic quality upgrade. ## Source facts: a global shutter does not remove the need for light Global-shutter benefits depend on an exposure short enough to control motion blur. Short exposures collect fewer photons, so fast-motion work commonly requires more visible or infrared illumination. Axis describes approximately 1/1000 second as common in traffic applications and even shorter exposure for rapidly spinning equipment, while emphasizing that the actual requirement belongs to the scene. A global shutter can synchronize a short, high-intensity light pulse with the whole frame. A rolling shutter exposed row by row may record that pulse only across a band. Mixed installations also need attention: a strobe serving one camera can create bands or split images in another. Global-shutter sensors may cost more and can introduce more noise than rolling-shutter designs, especially under limited light. ## DSE recommendation: specify the event before the sensor Define the evidence or machine decision first. Record the target type, fastest expected speed, direction through the field of view, distance, required shape or marking, and whether a human, analytic, or industrial process will use the image. A parking overview, a vehicle classification lane, and a conveyor inspection point have different tolerances even when all contain fast motion. - Measure the installed geometry. Motion across the sensor can be more demanding than motion toward the camera. Test the planned height, angle, focal length, target distance, and crop. - Set an exposure range deliberately. Verify the camera can hold the necessary exposure under both daylight and the darkest required condition without unacceptable gain, noise, or blur. - Design the illumination with the camera. Confirm wavelength, beam, intensity, duty cycle, synchronization, power, reflections, and effects on nearby cameras. Never assume a strobe is invisible to another sensor. - Record real-speed passes. Use the production stream, codec, frame rate, VMS, and playback client. Review consecutive frames rather than selecting one favorable still. - Compare failure modes. Look separately for blur, tilted objects, bent edges, bright bands, split exposures, missed analytic events, and low-light noise. ## DSE recommendation: preserve a repeatable acceptance record Document camera model, firmware, sensor type, lens, resolution, exposure limit, gain, frame rate, illumination, target speed, weather, test direction, and result. Retain short clips from the hardest passing and failing conditions. If a rolling shutter meets the written requirement, it may be the more economical and lower-noise choice. If it changes the shape or position needed for a decision, specify global shutter and the supporting light. Repeat the test after changes to the camera, lens, exposure policy, illumination, mounting angle, encoder profile, or analytic. The durable outcome is not “global shutter installed.” It is a recorded sequence that preserves the required information while the target moves at the speed the system was designed to handle. ## Official references - Axis Communications, [Global shutter vs rolling shutter](https://whitepapers.axis.com/en-us/global-shutter-vs-rolling-shutter), July 2026. ## Primary reference - Name: Axis Communications: Global shutter vs rolling shutter - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/global-shutter-vs-rolling-shutter - Source publication date: 2026-07-01 ## Citation and use Preferred citation: “Choose the shutter architecture after measuring target motion,” DSE Security, https://update.dsesecurity.com/updates/choose-global-rolling-shutter-from-target-motion/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose the SYSVOL authoritative-restore method from restore type > Use AD Forest Recovery - Performing an authoritative synchronization of DFSR-replicated SYSVOL to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/choose-sysvol-authoritative-restore-method/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:28+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use AD Forest Recovery - Performing an authoritative synchronization of DFSR-replicated SYSVOL to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of AD Forest Recovery - Performing an authoritative synchronization of DFSR-replicated SYSVOL ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Choose the SYSVOL authoritative-restore method from restore type. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [AD Forest Recovery – Performing an authoritative synchronization of DFSR-replicated SYSVOL](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-authoritative-recovery-sysvol) from Microsoft supports the following bounded statements: - DFSR-replicated SYSVOL can be restored authoritatively with msDFSR-Options or wbadmin -authsysvol. The research record locates this support at Opening overview. - Microsoft describes wbadmin as simpler for same-hardware system-state restore and the attribute method as necessary for bare-metal restore. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Resolve which controller is authoritative before changing SYSVOL recovery state. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [AD Forest Recovery – Performing an authoritative synchronization of DFSR-replicated SYSVOL](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-authoritative-recovery-sysvol) — Microsoft ## Primary reference - Name: AD Forest Recovery - Performing an authoritative synchronization of DFSR-replicated SYSVOL - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-authoritative-recovery-sysvol - Source publication date: 2023-06-21 ## Citation and use Preferred citation: “Choose the SYSVOL authoritative-restore method from restore type,” DSE Security, https://update.dsesecurity.com/updates/choose-sysvol-authoritative-restore-method/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose the version-appropriate path for moving a cluster between domains > What must be checked before planning a failover cluster domain move? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-189-choose-the-version-appropriate-path-for-moving-a-cluster-between-domains/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:02+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What must be checked before planning a failover cluster domain move? ## Potentially affected Administrators planning Windows Server failover cluster domain migration. ## DSE recommendation Have the cluster and directory owners write one migration sequence with named responsibilities at each domain boundary. ## Article ## Source facts Microsoft says Windows Server 2016 and earlier cluster services could not move a cluster directly from one domain to another. Its older-version alternatives include changing node membership and recreating the cluster and resources. Windows Server 2019 introduced cross-domain cluster migration that avoids rebuilding the cluster in the documented scenarios. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/failover-clustering/Cluster-Domain-Migration). ## Applicability Inventory every node version, cluster role, domain dependency, and witness configuration. Consult the documented migration steps and known issues for that specific configuration before selecting a method. Treat the source domain, target domain, and workload identities as separate planning items. ## DSE recommendation Have the cluster and directory owners write one migration sequence with named responsibilities at each domain boundary. Identify the cluster and role names that must remain usable, the maintenance window, and the evidence needed to authorize each transition. Preserve the pre-migration configuration and arrange a recovery path before changing membership. Review the witness separately instead of assuming it will survive the move unchanged. ## Verification In a representative test, verify cluster membership, role startup, client access names, and application access from the target domain. Check expected directory objects and witness behavior after the move. Record any recreated resource or changed identity explicitly, and resolve differences before applying the plan to the production cluster. ## Official references [Microsoft Learn: Cross Domain Cluster Migration in Windows Server 2016/2019](https://learn.microsoft.com/en-us/windows-server/failover-clustering/Cluster-Domain-Migration). Source reviewed September 8, 2026. ## Primary reference - Name: Cross Domain Cluster Migration in Windows Server 2016/2019 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/Cluster-Domain-Migration - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose the version-appropriate path for moving a cluster between domains,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-189-choose-the-version-appropriate-path-for-moving-a-cluster-between-domains/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose vital-record media that can still be read after disruption > Use 36 CFR 1223.18 - Form and format of vital records to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/choose-vital-record-media-that-can-still-be-read-after-disruption/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:33+00:00 - Modified: 2026-08-27T13:07:00+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 36 CFR 1223.18 - Form and format of vital records to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 36 CFR 1223.18 - Form and format of vital records ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Choose vital-record media that can still be read after disruption. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [36 CFR 1223.18 – Form and format of vital records](https://www.ecfr.gov/current/title-36/section-1223.18) from National Archives and Records Administration via eCFR supports the following bounded statements: - Under 36 CFR 1223, records may be maintained on a variety of media including paper, magnetic tape, optical disk, photographic film, and microform. The research record locates this support at 36 CFR 1223.18(b) (eCFR anchor p-1223.18(b)). - Under 36 CFR 1223, vital records can be original records or copies of records. The research record locates this support at 36 CFR 1223.18(a) (eCFR anchor p-1223.18(a)). The source support ends with the statements listed above. Use them to examine essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Federal agency records-management regulation; media longevity, format, encryption, keys, software, hardware, power, and qualified operators all require lifecycle planning. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 36 CFR 1223.18(b) (eCFR anchor p-1223.18(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 36 CFR 1223.18(a) (eCFR anchor p-1223.18(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from 36 CFR 1223.18(b) (eCFR anchor p-1223.18(b)); 36 CFR 1223.18(a) (eCFR anchor p-1223.18(a)) to the observed environment. Useful domain evidence includes business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [36 CFR 1223.18 – Form and format of vital records](https://www.ecfr.gov/current/title-36/section-1223.18) — National Archives and Records Administration via eCFR ## Primary reference - Name: 36 CFR 1223.18 - Form and format of vital records - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-36/section-1223.18 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose vital-record media that can still be read after disruption,” DSE Security, https://update.dsesecurity.com/updates/choose-vital-record-media-that-can-still-be-read-after-disruption/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose where a branch office will keep its BranchCache content > Should a branch use distributed client caching or a hosted cache server? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-004-choose-where-a-branch-office-will-keep-its-branchcache-content/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:17:07+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Should a branch use distributed client caching or a hosted cache server? ## Potentially affected Use this review when choosing a supported BranchCache mode for a particular office. ## DSE recommendation Ask the branch owner to describe normal device availability and the content-sharing pattern. ## Article ## Source facts Distributed BranchCache keeps cached content across branch client computers. Hosted-cache mode places that content on one or more branch servers. Microsoft explains that a hosted cache can keep content available when the client that originally fetched it is offline. Different branches can use different modes, but the source specifies one mode per branch. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/branchcache/BranchCache). ## Applicability Use this review when choosing a supported BranchCache mode for a particular office. Identify client availability, existing server capacity, content sources, and the people responsible for maintaining the cache location. ## DSE recommendation Ask the branch owner to describe normal device availability and the content-sharing pattern. Compare those requirements with the operational responsibility of running a cache server. Record the selected mode for each branch and the reason for the choice. Keep the decision separate from the later client-policy rollout and server installation, which require their own scoped configuration plans. ## Verification Run an approved content-access test with representative clients. Include the situation in which the original requesting client is offline and observe the selected design. Record the cache location and relevant network activity. Revisit the mode choice if branch device availability or the ability to operate a server changes materially. ## Official references [Microsoft Learn: BranchCache](https://learn.microsoft.com/en-us/windows-server/networking/branchcache/BranchCache). Source reviewed September 8, 2026. ## Primary reference - Name: BranchCache - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/branchcache/BranchCache - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose where a branch office will keep its BranchCache content,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-004-choose-where-a-branch-office-will-keep-its-branchcache-content/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose where VDI image optimizations belong before changing desktop settings > Which configuration layer should hold an optimization for a nonpersistent VDI desktop? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-010-choose-where-vdi-image-optimizations-belong-before-changing-desktop-settings/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:17:01+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which configuration layer should hold an optimization for a nonpersistent VDI desktop? ## Potentially affected Use this review when planning changes to a VDI image. ## DSE recommendation Create an image change record that names the user experience being improved and the setting being changed. ## Article ## Source facts Microsoft distinguishes persistent, nonpersistent, and session-based virtual desktop implementations. Some implementations deliver desktops derived from a shared base operating-system image. For nonpersistent desktops built from a gold image, Microsoft places most optimization work in that image, supplemented by local settings and policies. Microsoft identifies Sysprep as the tool for preparing a customized Windows 10 or Windows 11 image for duplication. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-services-vdi-optimize-configuration). ## Applicability Use this review when planning changes to a VDI image. Identify the desktop model, image owner, provisioning method, and policy layers. Check the source sections applicable to that model before applying an optimization list. ## DSE recommendation Create an image change record that names the user experience being improved and the setting being changed. Test one focused group of settings at a time. Include the desktop team and the owners of essential applications in acceptance criteria. Keep the previous image available through the approved image-management process and specify how a failed pilot will return to it. ## Verification Test a freshly provisioned desktop and a subsequent user session. Record application behavior, sign-in experience, and whether the intended settings remain where expected after reprovisioning. Include representative user tasks, not only an idle desktop observation. Document each accepted setting and any exception before updating the broader image population. ## Official references [Microsoft Learn: Optimizing Windows configuration for VDI desktops](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-services-vdi-optimize-configuration). Source reviewed September 8, 2026. ## Primary reference - Name: Optimizing Windows configuration for VDI desktops - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-services-vdi-optimize-configuration - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose where VDI image optimizations belong before changing desktop settings,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-010-choose-where-vdi-image-optimizations-belong-before-changing-desktop-settings/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose whether cluster anti-affinity should yield during a node outage > Should two clustered roles stay separated even when only one node remains available? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-158-choose-whether-cluster-anti-affinity-should-yield-during-a-node-outage/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:33+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Should two clustered roles stay separated even when only one node remains available? ## Potentially affected Administrators setting anti-affinity for Windows failover-cluster roles. ## DSE recommendation Record that tradeoff before choosing the anti-affinity setting. ## Article ## Source facts Microsoft uses anti-affinity to try to keep selected roles on different nodes. The AntiAffinityClassNames setting is a soft constraint; the documentation also describes enforcing a hard separation. Microsoft warns that, in a two-node configuration with enforced anti-affinity, losing one node means both separated groups cannot run. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/failover-clustering/Cluster-Affinity). ## Applicability Identify the roles, their resource demand, available nodes, and service priorities. Ask workload owners whether maintaining separation or keeping both services running should take precedence during reduced capacity. ## DSE recommendation Record that tradeoff before choosing the anti-affinity setting. Name the roles that belong to the same separation class and define the accepted outage behavior. Have the cluster owner review capacity and the application owners approve any intentional loss of service under enforcement. ## Verification Inspect the configured class values and observe placement under normal conditions. In an approved maintenance test, remove one eligible node and compare the resulting role state with the decision. Preserve an unavailable role as an expected or unexpected outcome explicitly; do not equate policy enforcement with application availability. ## Official references [Microsoft Learn: Cluster affinity](https://learn.microsoft.com/en-us/windows-server/failover-clustering/Cluster-Affinity). Source reviewed September 8, 2026. ## Primary reference - Name: Cluster affinity - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/Cluster-Affinity - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose whether cluster anti-affinity should yield during a node outage,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-158-choose-whether-cluster-anti-affinity-should-yield-during-a-node-outage/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose whether cluster compute and storage should scale together > Should a planned failover cluster add compute and storage in the same growth unit? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-092-choose-whether-cluster-compute-and-storage-should-scale-together/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:39+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Should a planned failover cluster add compute and storage in the same growth unit? ## Potentially affected Architects comparing Windows Server failover-cluster storage layouts. ## DSE recommendation Compare two concrete expansion scenarios: adding capacity without additional application compute, and adding compute without additional storage. ## Article ## Source facts Microsoft distinguishes storage separated from compute from hyperconverged Storage Spaces Direct. With separate SAN or NAS storage, cluster nodes reach storage across a network and compute and storage can grow independently. In the hyperconverged model, Storage Spaces Direct combines drives from the nodes into a shared pool and exposes Cluster Shared Volumes. Adding nodes increases compute resources and storage together. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/failover-clustering/storage-architectures). ## Applicability Start with workload growth, storage growth, existing equipment, and ownership requirements. Check the applicable hardware and operating-system requirements for each proposed design before treating a diagram as an approved configuration. ## DSE recommendation Compare two concrete expansion scenarios: adding capacity without additional application compute, and adding compute without additional storage. Record which servers, fabric components, and owners participate in each option. Ask application and storage teams to agree on the expansion unit and the maintenance responsibilities it creates. ## Verification Review a representative workload placement and maintenance event against the selected architecture. Confirm where its data resides, which nodes can reach it, and how expansion would be performed under the approved design. Keep capacity assumptions and measured application requirements explicit so later growth does not rely on an undocumented architectural shortcut. ## Official references [Microsoft Learn: Failover Clustering Storage Architectures in Windows Server](https://learn.microsoft.com/en-us/windows-server/failover-clustering/storage-architectures). Source reviewed September 8, 2026. ## Primary reference - Name: Failover Clustering Storage Architectures in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/storage-architectures - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose whether cluster compute and storage should scale together,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-092-choose-whether-cluster-compute-and-storage-should-scale-together/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose Windows DNS forwarders, conditional forwarders, and delegation boundaries deliberately > Use DNS Forwarding in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/choose-windows-dns-forwarders-conditional-forwarders-and-delegation-boundaries-deliberately/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:37+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use DNS Forwarding in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of DNS Forwarding in Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Choose Windows DNS forwarders, conditional forwarders, and delegation boundaries deliberately. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [DNS Forwarding in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/forwarding) from Microsoft supports the following bounded statements: - Windows Server DNS supports forwarding and conditional forwarding for name resolution. The research record locates this support at Forwarding; Forwarders and delegation; Conditional forwarders; Intranet name resolution. - Delegation, conditional forwarders, and intranet name resolution are distinct design elements in the documented forwarding model. The research record locates this support at Forwarding; Forwarders and delegation; Conditional forwarders; Intranet name resolution. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish A forwarding configuration is not evidence that every suffix, failure path, DNSSEC requirement, or recursion boundary behaves as intended. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Forwarding; Forwarders and delegation; Conditional forwarders; Intranet name resolution, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Forwarding; Forwarders and delegation; Conditional forwarders; Intranet name resolution, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Forwarding; Forwarders and delegation; Conditional forwarders; Intranet name resolution; Forwarding; Forwarders and delegation; Conditional forwarders; Intranet name resolution. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [DNS Forwarding in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/forwarding) — Microsoft ## Primary reference - Name: DNS Forwarding in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/forwarding - Source publication date: 2026-05-13 ## Citation and use Preferred citation: “Choose Windows DNS forwarders, conditional forwarders, and delegation boundaries deliberately,” DSE Security, https://update.dsesecurity.com/updates/choose-windows-dns-forwarders-conditional-forwarders-and-delegation-boundaries-deliberately/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose Windows primary, secondary, stub, and AD-integrated zones by replication need > Use DNS zones in DNS Server on Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/choose-windows-primary-secondary-stub-and-ad-integrated-zones-by-replication-need/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:36+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use DNS zones in DNS Server on Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of DNS zones in DNS Server on Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Choose Windows primary, secondary, stub, and AD-integrated zones by replication need. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [DNS zones in DNS Server on Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/zone-types) from Microsoft supports the following bounded statements: - Windows DNS Server supports primary, secondary, stub, and reverse lookup zones. The research record locates this support at Section ‘DNS zone types’. - Zone data can be file-backed or stored in Active Directory Domain Services; secondary zones are read-only copies. The research record locates this support at Primary zones; Secondary zone. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The zone-type descriptions do not determine the right administrative boundary, transfer authorization, or Active Directory replication scope for a deployment. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section ‘DNS zone types’, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Primary zones; Secondary zone, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section ‘DNS zone types’; Primary zones; Secondary zone. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [DNS zones in DNS Server on Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/zone-types) — Microsoft ## Primary reference - Name: DNS zones in DNS Server on Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/zone-types - Source publication date: 2025-03-24 ## Citation and use Preferred citation: “Choose Windows primary, secondary, stub, and AD-integrated zones by replication need,” DSE Security, https://update.dsesecurity.com/updates/choose-windows-primary-secondary-stub-and-ad-integrated-zones-by-replication-need/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Choose Work Folders server placement around site dependencies > Which site dependencies should influence where Work Folders sync servers are placed? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-090-choose-work-folders-server-placement-around-site-dependencies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:41+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which site dependencies should influence where Work Folders sync servers are placed? ## Potentially affected Administrators planning Work Folders server locations across organizational sites. ## DSE recommendation Create a placement decision for each user group and identify the network or authentication dependencies that could interrupt its service. ## Article ## Source facts Microsoft describes centralized, distributed, and hosted Work Folders deployment patterns. A centralized deployment depends on connectivity between the central location and branch offices; branch users can lose service when those network paths are interrupted. Distributing sync servers adds coordination of storage and AD DS so users reach the correct server. Hosted servers still require access to the organization’s Active Directory domain for authentication, even when users can reach the servers through the internet. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/work-folders/plan-work-folders). ## Applicability Map the users, offices, candidate server locations, authentication paths, and service owners. Review site-specific connectivity assumptions before selecting a deployment pattern or assigning users to a sync server. ## DSE recommendation Create a placement decision for each user group and identify the network or authentication dependencies that could interrupt its service. Ask branch and central infrastructure owners to review the same map. Include an explicit support owner for the connection between any hosted server and the organization’s directory. ## Verification Test representative clients from the intended locations, including an approved interruption scenario for a selected dependency. Record which sync server each client reaches and the observed authentication and synchronization results. Use those observations to accept or revise placement decisions before adding more users. ## Official references [Microsoft Learn: Planning a Work Folders deployment](https://learn.microsoft.com/en-us/windows-server/storage/work-folders/plan-work-folders). Source reviewed September 8, 2026. ## Primary reference - Name: Planning a Work Folders deployment - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/work-folders/plan-work-folders - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Choose Work Folders server placement around site dependencies,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-090-choose-work-folders-server-placement-around-site-dependencies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Classify IPv6 unicast, anycast, and multicast addresses before policy > Use RFC 4291 — IP Version 6 Addressing Architecture to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/classify-ipv6-unicast-anycast-and-multicast-addresses-before-policy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:34+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4291 — IP Version 6 Addressing Architecture to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4291 — IP Version 6 Addressing Architecture ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Classify IPv6 unicast, anycast, and multicast addresses before policy. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4291 — IP Version 6 Addressing Architecture](https://www.rfc-editor.org/rfc/rfc4291.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An IPv6 unicast address identifies one interface, and traffic sent to it is delivered to that interface. The research record locates this support at Section 2 (IPv6 Addressing), Unicast definition. - An IPv6 anycast address identifies multiple interfaces and delivers a packet to the nearest one according to routing distance. The research record locates this support at Sections 2 (IPv6 Addressing) and 2.6 (Anycast Addresses). - An IPv6 multicast address delivers to every interface in its group, and multicast replaces IPv6 broadcast addressing. The research record locates this support at Section 2 (IPv6 Addressing), Multicast definition. The source support ends with the statements listed above. Use them to examine address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 2 (IPv6 Addressing), Unicast definition, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 2 (IPv6 Addressing) and 2.6 (Anycast Addresses), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2 (IPv6 Addressing), Multicast definition, which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from Section 2 (IPv6 Addressing), Unicast definition; Sections 2 (IPv6 Addressing) and 2.6 (Anycast Addresses); Section 2 (IPv6 Addressing), Multicast definition through configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 4291 — IP Version 6 Addressing Architecture](https://www.rfc-editor.org/rfc/rfc4291.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4291 — IP Version 6 Addressing Architecture - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4291.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Classify IPv6 unicast, anycast, and multicast addresses before policy,” DSE Security, https://update.dsesecurity.com/updates/classify-ipv6-unicast-anycast-and-multicast-addresses-before-policy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Classify Unicode code points before admitting them to an IDNA label > Use RFC 5892 — The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/classify-unicode-code-points-before-admitting-them-to-an-idna-label/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:45+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 5892 — The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 5892 — The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Classify Unicode code points before admitting them to an IDNA label. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 5892 — The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)](https://www.rfc-editor.org/rfc/rfc5892.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - IDNA2008 assigns each Unicode code point one derived property: PVALID, CONTEXTJ, CONTEXTO, DISALLOWED, or UNASSIGNED. The research record locates this support at Section 1 (Introduction). - The property derivation applies the category rules in order, and the first matching rule determines the code point’s property. The research record locates this support at Section 2 (Category Definitions Used to Calculate Derived Property Value). - Unassigned code points in Unicode general category Cn are classified UNASSIGNED unless an earlier rule, such as noncharacter handling, applies. The research record locates this support at Section 2.10 (Unassigned Code Points). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 1 (Introduction), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2 (Category Definitions Used to Calculate Derived Property Value), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2.10 (Unassigned Code Points), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to Section 1 (Introduction); Section 2 (Category Definitions Used to Calculate Derived Property Value); Section 2.10 (Unassigned Code Points) and to observable material such as zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 5892 — The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)](https://www.rfc-editor.org/rfc/rfc5892.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 5892 — The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5892.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Classify Unicode code points before admitting them to an IDNA label,” DSE Security, https://update.dsesecurity.com/updates/classify-unicode-code-points-before-admitting-them-to-an-idna-label/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Clean AD metadata immediately after forced domain-controller removal > Use Clean up AD DS server metadata to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/clean-ad-metadata-after-forced-dc-removal/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:02+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Clean up AD DS server metadata to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Clean up AD DS server metadata ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Clean AD metadata immediately after forced domain-controller removal. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Clean up AD DS server metadata](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup) from Microsoft supports the following bounded statements: - Metadata cleanup is required after forced removal of AD DS from a domain controller. The research record locates this support at Opening overview. - Cleanup removes replication, FRS, and DFSR references and attempts to transfer or seize held FSMO roles. The research record locates this support at Opening overview. Only the traced statements above are asserted as source facts. Apply the review to forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles after confirming that the source and deployed context match. ## What the source does not establish Resolve the exact retired controller and domain before deleting metadata. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations Opening overview; Opening overview adjacent to the sanitized artifacts used for comparison. Prefer directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Clean up AD DS server metadata](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup) — Microsoft ## Primary reference - Name: Clean up AD DS server metadata - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Clean AD metadata immediately after forced domain-controller removal,” DSE Security, https://update.dsesecurity.com/updates/clean-ad-metadata-after-forced-dc-removal/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Clean up stale Intune records without mistaking hiding for retirement > Intune device cleanup rules hide stale records from the admin center and reports. They do not wipe, retire, or remove the corresponding Microsoft Entra device object. - Canonical URL: https://update.dsesecurity.com/updates/intune-device-cleanup-rules-stale-records/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:53+00:00 - Modified: 2026-07-19T21:27:53+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Information - Topics: IT, Microsoft 365 & Identity - Reading time: 2 minutes ## What you need to know Intune device cleanup rules hide stale records from the admin center and reports. They do not wipe, retire, or remove the corresponding Microsoft Entra device object. ## Potentially affected Microsoft Intune tenants with stale, duplicate, seasonal, long-offline, replaced, or unenrolled device records across supported platforms. ## DSE recommendation Preview affected devices, reconcile owners and exceptions, select a conservative platform-wide inactivity threshold, monitor audit events, and manage Intune and Entra lifecycle records separately. ## Article ## Source fact: what Microsoft documents Microsoft Intune device cleanup rules run on a schedule and automatically hide records for devices that have not checked in during a configured period. Microsoft explicitly states that a cleanup rule does not wipe, retire, or otherwise send an action to the physical device. A hidden record can reappear if the device checks in again before its management certificate expires; after expiry, reenrollment is required. The inactivity setting accepts 30 through 270 days. Administrators can create a rule for all platforms and one rule per individual platform. If both an all-platform rule and a platform-specific rule apply, Microsoft uses the rule with fewer days. A rule applies to all Intune records for that platform rather than to a selected device group. Jamf-managed devices are not supported. Cleanup does not remove the related Microsoft Entra device object. Microsoft documents separate Entra stale-device management. Intune audit logs record devices hidden by a cleanup rule, and the admin center can preview currently affected devices before rule creation. ## Licensing and applicability Users or devices benefiting from Intune generally require applicable Intune licensing. Configuring cleanup requires an Intune Administrator or a custom role with cleanup-setting permissions and visibility into the devices. Platform-wide behavior means seasonal equipment, spares, kiosks, disaster-recovery devices, long-term leave, ships, remote sites, and devices awaiting repair can be hidden even when they still have an owner and purpose. ## DSE recommendation: production-safe operational steps - Export current device records with platform, serial number, ownership, enrollment type, last check-in, compliance, management certificate, primary user, and corresponding Entra object. - Ask service owners to identify legitimate long-offline populations and decide how they will be tracked outside the normal active-device view. - Choose a conservative threshold based on real check-in patterns, certificate life, remote operations, replacement cycles, and support requirements. - Use Preview affected devices and investigate unexpected critical, shared, or recently issued assets before creating the rule. - Start with one platform. Review Intune audit events, hidden-device behavior, reporting impact, reenrollment cases, and device reappearance. - Maintain a separate process for wipe, retire, corporate-data removal, Entra object cleanup, inventory disposal, license recovery, and evidence retention. - Review the threshold and exceptions after organizational, enrollment, or certificate changes. DSE recommends treating cleanup as an administrative-view control, not a security containment or asset-disposal control. Do not cite a disappeared Intune record as proof that access was removed or company data was erased. During an investigation, preserve the record and relevant exports before a cleanup rule hides it. ## Official reference [Device cleanup rules](https://learn.microsoft.com/en-us/intune/governance/configure-cleanup-rules) — hiding behavior, thresholds, platform scope, preview, Entra separation, and audit logging. ## Primary reference - Name: Microsoft Learn: Device cleanup rules - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/intune/governance/configure-cleanup-rules - Source publication date: 2026-05-05 ## Citation and use Preferred citation: “Clean up stale Intune records without mistaking hiding for retirement,” DSE Security, https://update.dsesecurity.com/updates/intune-device-cleanup-rules-stale-records/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Clear-ADAccountExpiration: clear adaccount expiration under AD/DNS change control > Use Clear-ADAccountExpiration to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/clear-adaccountexpiration-clear-adaccount-expiration-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:25+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Clear-ADAccountExpiration to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Clear-ADAccountExpiration ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Clear-ADAccountExpiration: clear adaccount expiration under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Clear-ADAccountExpiration](https://learn.microsoft.com/en-us/powershell/module/activedirectory/clear-adaccountexpiration?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Clear-ADAccountExpiration cmdlet clears the expiration date for an Active Directory user or computer account.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “When you clear the expiration date for an account, the account does not expire.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations DESCRIPTION; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-181 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Clear-ADAccountExpiration](https://learn.microsoft.com/en-us/powershell/module/activedirectory/clear-adaccountexpiration?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Clear-ADAccountExpiration - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/clear-adaccountexpiration?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Clear-ADAccountExpiration: clear adaccount expiration under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/clear-adaccountexpiration-clear-adaccount-expiration-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Clear-ADClaimTransformLink: clear adclaim transform link with bounded evidence > Use Clear-ADClaimTransformLink to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/clear-adclaimtransformlink-clear-adclaim-transform-link-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:06+00:00 - Modified: 2026-08-27T17:18:35+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Clear-ADClaimTransformLink to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Clear-ADClaimTransformLink ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Clear-ADClaimTransformLink: clear adclaim transform link with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Clear-ADClaimTransformLink](https://learn.microsoft.com/en-us/powershell/module/activedirectory/clear-adclaimtransformlink?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Removes a claims transformation from being applied to one or more cross-forest trust relationships in Active Directory.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Clear-ADClaimTransformLink cmdlet removes a claims transformation from being applied to one or more cross-forest trust relationships in Active Directory.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations SYNOPSIS; DESCRIPTION. Favor sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-200 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Clear-ADClaimTransformLink](https://learn.microsoft.com/en-us/powershell/module/activedirectory/clear-adclaimtransformlink?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Clear-ADClaimTransformLink - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/clear-adclaimtransformlink?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Clear-ADClaimTransformLink: clear adclaim transform link with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/clear-adclaimtransformlink-clear-adclaim-transform-link-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Clear-DnsServerCache: clear dns server cache against recorded identity and DNS state > Use Clear-DnsServerCache to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/clear-dnsservercache-clear-dns-server-cache-against-recorded-identity-and-dns-state/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:48+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Clear-DnsServerCache to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Clear-DnsServerCache ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Clear-DnsServerCache: clear dns server cache against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Clear-DnsServerCache](https://learn.microsoft.com/en-us/powershell/module/dnsserver/clear-dnsservercache?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Clears resource records from a cache on the DNS server.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Clear-DnsServerCache cmdlet clears resource records from a Domain Name System (DNS) server cache.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-278 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Clear-DnsServerCache](https://learn.microsoft.com/en-us/powershell/module/dnsserver/clear-dnsservercache?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Clear-DnsServerCache - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/clear-dnsservercache?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Clear-DnsServerCache: clear dns server cache against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/clear-dnsservercache-clear-dns-server-cache-against-recorded-identity-and-dns-state/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Clear-DnsServerStatistics: clear dns server statistics with bounded evidence > Use Clear-DnsServerStatistics to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/clear-dnsserverstatistics-clear-dns-server-statistics-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:06+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Clear-DnsServerStatistics to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Clear-DnsServerStatistics ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Clear-DnsServerStatistics: clear dns server statistics with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Clear-DnsServerStatistics](https://learn.microsoft.com/en-us/powershell/module/dnsserver/clear-dnsserverstatistics?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Clear-DnsServerStatistics cmdlet clears all Domain Name System (DNS) server statistics.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “After you have cleared the statistics, you cannot retrieve them.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-260 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Clear-DnsServerStatistics](https://learn.microsoft.com/en-us/powershell/module/dnsserver/clear-dnsserverstatistics?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Clear-DnsServerStatistics - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/clear-dnsserverstatistics?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Clear-DnsServerStatistics: clear dns server statistics with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/clear-dnsserverstatistics-clear-dns-server-statistics-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Close corrective actions after exercises—not at the after-action meeting > An after-action report creates value only when findings become owned, funded, verified improvements. Preserve evidence, identify root conditions, assign measurable actions, manage risk and dependencies, retest, and require closure proof. - Canonical URL: https://update.dsesecurity.com/updates/close-exercise-corrective-actions-through-verification/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:45:00+00:00 - Modified: 2026-08-17T19:22:10+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know An after-action report creates value only when findings become owned, funded, verified improvements. Preserve evidence, identify root conditions, assign measurable actions, manage risk and dependencies, retest, and require closure proof. ## Potentially affected Business continuity, disaster recovery, cybersecurity, safety and emergency exercises; after-action reports; improvement plans; risk registers; budgets; system owners; suppliers; training; change control; and executive oversight. ## DSE recommendation Translate observations into evidence-backed findings, assign corrective actions and accountable owners, define measures and due dates, track dependencies and accepted risk, verify implementation, retest the capability, and report overdue work. ## Article ## Source facts: evaluation should feed a managed improvement process FEMA’s [Homeland Security Exercise and Evaluation Program policy and guidance resources](https://preptoolkit.fema.gov/web/hseep-resources/policy-and-guidance) describe a common approach to exercise program management, design, conduct, evaluation, and improvement planning. The model connects observed performance and analysis to corrective actions rather than treating the exercise as complete when participation ends. NIST [SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities](https://csrc.nist.gov/pubs/sp/800/84/final), addresses designing, developing, conducting, and evaluating tests, training events, and exercises for information-technology plans and capabilities. It distinguishes activity types and emphasizes using results to improve plans, procedures, and readiness. These sources do not set one universal deadline, evidence type, risk-acceptance authority, or closure threshold. An organization must define them according to mission, impact, obligation, and resources. An observation can also be misunderstood; evidence and analysis should separate a one-time participant error from a structural process or technology weakness. ## DSE recommendation: require verified capability change before closure Open improvement work while evidence is fresh, then manage it through the same disciplined ownership, change, and risk processes used for production systems. - Preserve the exercise record. Capture objectives, scenario boundaries, assumptions, participants and roles, timestamps, injects, decisions, communications, system evidence, workarounds, safety issues, evaluator notes, and whether actions were simulated. Protect sensitive architecture and personnel details appropriately. - Separate observation from finding. State what occurred, expected behavior, consequence, contributing conditions, and supporting evidence. Determine whether the issue involved documentation, training, authority, staffing, supplier dependency, technology, data, communications, or the exercise design itself. - Write an outcome-based corrective action. Define the capability to be restored or improved, affected scope, accountable owner, sponsor, milestones, resources, dependencies, due date, success measure, evidence required, and retest method. Avoid tasks such as review the plan that do not describe a verifiable result. - Integrate change and risk. Link the action to service, asset, project, ticket, policy, risk, budget, vendor, and change records. Assess whether interim controls are needed. If leadership accepts delay or residual risk, record the authority, basis, duration, monitoring, and review trigger. - Track blockers and escalation. Review aging, scope changes, missed milestones, dependency conflicts, and repeated findings. Escalate based on impact and overdue status rather than allowing the exercise team to carry problems it cannot fund or authorize. - Verify implementation independently. Inspect the changed configuration, procedure, contract, training record, equipment, contact data, or monitoring evidence. Confirm the change reached the full intended scope and did not introduce a new control or continuity gap. - Retest and close. Use a focused test or the next suitable exercise to demonstrate the original objective under representative conditions. Record results and residual limitations. Close only when the named authority accepts verification and retest evidence—not when a document was uploaded or a meeting occurred. Use trend review to keep the program honest. Compare findings across exercises and real incidents by capability, root condition, owner, supplier, location, and age. Repeated workarounds or findings that migrate between teams often indicate an unresolved design or governance problem rather than a training gap. Close exercise-design findings too. If objectives were unmeasurable, evaluators lacked system evidence, participants received unrealistic information, or the scenario skipped a critical dependency, improve the next exercise. Do not treat a favorable outcome produced by artificial assumptions as proof that the operational capability will work. Factual boundary: FEMA and NIST offer program guidance; the organization defines ownership, due dates, evidence, retest depth, risk authority, and closure. A finding can reveal risk without proving that a particular remediation is the only or safest solution. Measure actions open and overdue, median closure time, repeat findings, actions closed without retest, accepted-risk age, dependency delays, and improvement in objective performance. The after-action meeting should start the improvement cycle; verification should end it. ## Official references - FEMA, [Homeland Security Exercise and Evaluation Program policy and guidance](https://preptoolkit.fema.gov/web/hseep-resources/policy-and-guidance). - NIST, [SP 800-84: Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities](https://csrc.nist.gov/pubs/sp/800/84/final). ## Primary reference - Name: FEMA Homeland Security Exercise and Evaluation Program guidance - Authority: Federal Emergency Management Agency - URL: https://preptoolkit.fema.gov/web/hseep-resources/policy-and-guidance - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Close corrective actions after exercises—not at the after-action meeting,” DSE Security, https://update.dsesecurity.com/updates/close-exercise-corrective-actions-through-verification/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Close IPv6 RA-Guard evasion paths before calling the access edge protected > Validate that access switches inspect IPv6 extension-header chains and fragments before relying on Router Advertisement Guard. - Canonical URL: https://update.dsesecurity.com/updates/close-ipv6-ra-guard-evasion-paths/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:53+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Validate that access switches inspect IPv6 extension-header chains and fragments before relying on Router Advertisement Guard. ## Potentially affected IPv6-enabled access networks that use switch-based Router Advertisement Guard or equivalent first-hop controls ## DSE recommendation Test the exact switch hardware, software, and policy against fragmented and extension-header Router Advertisements, then retain packet-level evidence. ## Article Router Advertisement Guard is useful only when the enforcement point can reliably recognize a Router Advertisement. A rule that blocks the obvious packet shape but permits evasive extension-header or fragment arrangements leaves an access segment exposed to unauthorized IPv6 default-router information. ## Source fact: [IETF RFC 7113](https://datatracker.ietf.org/doc/rfc7113/) documents implementation advice for IPv6 RA-Guard. It explains that some implementations can be circumvented when an attacker places the ICMPv6 Router Advertisement behind IPv6 extension headers. The RFC recommends that an enforcement device inspect the entire IPv6 header chain rather than assume that the upper-layer protocol immediately follows the base header. The RFC also addresses fragments. Its guidance includes dropping and logging a first fragment when that fragment does not contain the complete IPv6 header chain, because the device cannot then determine whether a prohibited Router Advertisement follows. It also recommends a default-drop posture when an RA-Guard device encounters an unrecognized next-header value and cannot positively determine that the packet is permitted. ## Boundary RFC 7113 is implementation advice, not a certification of any switch or configuration. Hardware forwarding paths, software releases, policy syntax, logging, and treatment of extension headers vary by platform. A lab result from one model or release does not establish behavior for another. RA-Guard also addresses forged Router Advertisements; it is not a complete IPv6 first-hop security program and does not replace appropriate port authorization, DHCPv6 controls, address monitoring, or endpoint protections. ## Applicability questions - Which user, wireless, voice, guest, and building-system VLANs carry IPv6 today, including link-local traffic? - On which ports should legitimate Router Advertisements enter, and is that role documented? - Can the installed forwarding hardware parse the relevant extension-header chain at line rate? - How does the release handle first fragments, unknown next headers, and packets that exceed its inspection depth? - Are drops observable in counters or logs without creating an operational flood? ## DSE recommendation: Inventory every IPv6-capable access segment and define permitted router-facing ports explicitly. Obtain the vendor’s current feature and limitation documentation for the exact hardware and software combination. In an isolated test VLAN, send an allowed legitimate RA and prohibited RAs in ordinary, extension-header, and fragmented forms. Include benign IPv6 traffic that uses extension headers so the team can identify unacceptable false positives. Promote the policy through change control only after the failure behavior is understood. Record exceptions narrowly, assign an owner, and retest after switch upgrades or replacement. If a platform cannot implement the RFC’s inspection guidance, document the gap and use compensating segmentation or upstream enforcement instead of reporting the segment as protected. ## Verification and evidence Retain the switch model, software version, running policy, port roles, packet captures from both sides of the enforcement point, test-packet definitions, drop counters, and the approved change record. A passing result should show that the legitimate router remains reachable, ordinary endpoint traffic continues, and each prohibited test packet is blocked by the intended control. Re-run a small regression set after relevant firmware, ASIC-profile, or template changes. ## Official references - [IETF RFC 7113](https://datatracker.ietf.org/doc/rfc7113/) - [IETF RFC 6105, IPv6 Router Advertisement Guard](https://www.rfc-editor.org/rfc/rfc6105.html) ## Primary reference - Name: RFC 7113: Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) - Authority: datatracker.ietf.org - URL: https://datatracker.ietf.org/doc/rfc7113/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Close IPv6 RA-Guard evasion paths before calling the access edge protected,” DSE Security, https://update.dsesecurity.com/updates/close-ipv6-ra-guard-evasion-paths/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Close technician offboarding across PSA, RMM, vaults, partner portals, and customer access > Disabling one directory account does not end an MSP technician’s access. Close sessions, groups, RMM and PSA accounts, vault permissions, customer-local identities, API tokens, recovery paths, and shared knowledge. - Canonical URL: https://update.dsesecurity.com/updates/close-technician-offboarding-across-msp-access/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:23:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Disabling one directory account does not end an MSP technician’s access. Close sessions, groups, RMM and PSA accounts, vault permissions, customer-local identities, API tokens, recovery paths, and shared knowledge. ## Potentially affected Technician identities; Microsoft Entra and local directories; PSA and RMM platforms; vaults; backup consoles; partner portals; customer-local accounts; API tokens; remote access; documentation; and recovery mechanisms. ## DSE recommendation Build a role-based access register, trigger offboarding from an authoritative event, disable and revoke sessions immediately, remove delegated and customer-local access, rotate exposed shared secrets, verify closure, and retain evidence. ## Article ## Source facts: account termination must follow the real access graph [NIST SP 800-53 Rev. 5 Update 1](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) includes controls for managing accounts and for terminating access when employment ends. Its account-management guidance addresses creating, enabling, modifying, disabling, and removing accounts; aligning access with authorized users and roles; monitoring account use; and reviewing accounts. Personnel-termination controls include disabling system access, revoking credentials, retrieving property, and notifying responsible roles. Microsoft’s Cloud Solution Provider guidance likewise emphasizes removing users who no longer require access, reviewing administrative relationships and privileged roles, protecting credentials, and monitoring partner activity. CISA’s MSP advisory recommends restricting privileged access, tracking provider accounts, logging actions, and coordinating responsibilities between providers and customers. Those outcomes cannot be achieved by assuming the primary identity provider is the only control point. MSP access can persist through active browser sessions, local customer accounts, RMM agents, vault exports, API keys, application consents, emergency credentials, shared device codes, documentation copies, SSH keys, vendor portals, and customer-controlled identities. Some paths may not support centralized revocation, and an operator may possess knowledge of a shared credential even after the account that revealed it is disabled. ## DSE recommendation: make offboarding an evidence-backed runbook Build the runbook from the access paths used in daily service delivery. Assign an accountable coordinator, strict target times by risk, and a second person who confirms completion. - Define the trigger. Use an authoritative HR or leadership event with effective time, employment status, role change, legal constraints, equipment location, manager, and offboarding risk level. Restrict advance notice when required, but pre-stage the checklist and owners. - Contain identity first. Disable privileged and standard accounts at the effective time, revoke active sessions and refresh tokens, remove authentication methods, block remote access, and remove the person from privileged groups, approval workflows, on-call systems, and password-recovery roles. - Close the MSP stack. Disable or delete named accounts in PSA, RMM, vault, documentation, backup, security, monitoring, registrar, cloud, telephony, source-control, and vendor systems. Reassign tickets, alerts, automation ownership, secrets, scheduled tasks, and customer communications before removing dependencies. - Close customer paths. Query the access register for GDAP groups, customer-local accounts, VPN profiles, firewall accounts, remote-support tools, certificates, SSH keys, API tokens, and customer-managed identities. Coordinate removals with customers where the provider lacks authority and document pending items. - Rotate exposed shared material. Change passwords, recovery codes, shared keys, and secrets the technician could retrieve or memorize. Prioritize domain administration, network equipment, backup, hypervisor, vault recovery, and emergency access. Validate dependent services after rotation. - Recover assets and data. Collect managed devices, badges, tokens, removable media, paper records, and licensed hardware. Remotely isolate or wipe devices only under approved policy. Preserve required business records and prevent uncontrolled copies of customer data. - Verify independently. A second operator should search for the person’s name, addresses, object IDs, device certificates, tokens, group membership, recent sessions, and customer accounts. Test that old access fails, review post-termination alerts, record exceptions, and obtain owner signoff. Factual boundary: NIST controls describe security outcomes, not product-specific deletion commands or legal procedures. Disabling an identity does not retract information already viewed or copied. Labor, privacy, evidence-preservation, and customer-notification requirements must be determined with the appropriate business and legal owners. Track time from effective termination to session revocation, unresolved customer paths, shared-secret rotations, returned assets, orphaned automations, failed verification tests, and post-departure access attempts. A mature process can answer not just when the employee account was disabled, but when every material customer-access path was closed and who verified it. ## Official references - NIST, [Security and Privacy Controls for Information Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), SP 800-53 Rev. 5 Update 1. - Microsoft Learn, [Security best practices for Cloud Solution Provider partners](https://learn.microsoft.com/en-us/partner-center/security/csp-security-best-practices). - CISA, [Protecting Against Cyber Threats to Managed Service Providers and their Customers](https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-131a). ## Primary reference - Name: CISA: Protecting Against Cyber Threats to Managed Service Providers and their Customers - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-131a - Source publication date: 2022-05-11 ## Citation and use Preferred citation: “Close technician offboarding across PSA, RMM, vaults, partner portals, and customer access,” DSE Security, https://update.dsesecurity.com/updates/close-technician-offboarding-across-msp-access/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Close the loop on strategic-material shipment departure, arrival, and loss > Use 10 CFR 73.27 - Notification requirements to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/close-the-loop-on-strategic-material-shipment-departure-arrival-and-loss/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:54+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.27 - Notification requirements to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.27 - Notification requirements ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Close the loop on strategic-material shipment departure, arrival, and loss. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.27 – Notification requirements](https://www.ecfr.gov/current/title-10/section-73.27) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - A licensee shipping formula quantities of strategic special nuclear material must immediately tell the consignee the departure time and confirm the transportation method, carriers, and estimated arrival time. The research record locates this support at 10 CFR 73.27(a)(1) (eCFR anchor p-73.27(a)(1)). - A licensee responsible for shipment protection must immediately trace a shipment that remains lost or unaccounted for after its estimated arrival and report it under sections 73.1200 and 73.1205. The research record locates this support at 10 CFR 73.27(c) (eCFR anchor p-73.27(c)). The source support ends with the statements listed above. Use them to examine access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This applies only to covered formula-quantity shipments and the notifications and tracing required by 10 CFR 73.27. It does not prescribe a complete transport-security plan. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 10 CFR 73.27(a)(1) (eCFR anchor p-73.27(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.27(c) (eCFR anchor p-73.27(c)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from 10 CFR 73.27(a)(1) (eCFR anchor p-73.27(a)(1)); 10 CFR 73.27(c) (eCFR anchor p-73.27(c)) to the observed environment. Useful domain evidence includes asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [10 CFR 73.27 – Notification requirements](https://www.ecfr.gov/current/title-10/section-73.27) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.27 - Notification requirements - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.27 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Close the loop on strategic-material shipment departure, arrival, and loss,” DSE Security, https://update.dsesecurity.com/updates/close-the-loop-on-strategic-material-shipment-departure-arrival-and-loss/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Collect both ends of an SMB failure before interpreting retransmissions > Which evidence should be collected before investigating an SMB connection failure? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-087-collect-both-ends-of-an-smb-failure-before-interpreting-retransmissions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:44+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which evidence should be collected before investigating an SMB connection failure? ## Potentially affected Administrators diagnosing SMB client-to-server communication failures. ## DSE recommendation Prepare one coordinated collection window covering both endpoints. ## Article ## Source facts Microsoft recommends collecting network traces at both the SMB client and server before troubleshooting. Its guidance emphasizes consistent SMB terminology so that collection and analysis refer to the same operations. A sequence of five retransmissions followed by a TCP reset may indicate lost connectivity or an SMB service that stopped responding. Microsoft presents these as possible explanations, not a unique diagnosis. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/file-server/Troubleshoot/troubleshooting-smb). ## Applicability Define the failed file operation, client, server, share name, and observed time. Review whether the issue can be reproduced safely, and arrange appropriate handling for any sensitive information present in the captured traffic. ## DSE recommendation Prepare one coordinated collection window covering both endpoints. Record the exact reproduction steps and the result the user expected. Ask the network and file-service owners to agree on the timestamps and operation identifiers they will use when comparing captures and logs. ## Verification Confirm that both captures contain the same attempted operation before drawing a conclusion. Compare connection establishment, requests, responses, retransmissions, and termination. Preserve alternative explanations until the endpoint and network evidence distinguishes them; record a missing capture or uncertain time alignment as a collection limitation. ## Official references [Microsoft Learn: Advanced Troubleshooting Server Message Block (SMB)](https://learn.microsoft.com/en-us/windows-server/storage/file-server/Troubleshoot/troubleshooting-smb). Source reviewed September 8, 2026. ## Primary reference - Name: Advanced Troubleshooting Server Message Block (SMB) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/file-server/Troubleshoot/troubleshooting-smb - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Collect both ends of an SMB failure before interpreting retransmissions,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-087-collect-both-ends-of-an-smb-failure-before-interpreting-retransmissions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Collect Windows DNS audit and analytic events with a measured volume budget > Use Enable DNS Logging and Diagnostics in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/collect-windows-dns-audit-and-analytic-events-with-a-measured-volume-budget/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:35+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Enable DNS Logging and Diagnostics in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Enable DNS Logging and Diagnostics in Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Collect Windows DNS audit and analytic events with a measured volume budget. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Enable DNS Logging and Diagnostics in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-logging-and-diagnostics) from Microsoft supports the following bounded statements: - Windows Server exposes enhanced DNS logging, auditing, and analytic events for the DNS Server role. The research record locates this support at Article introduction. - DNS analytical logging is separate from ordinary DNS Server event logging and can create high event volume. The research record locates this support at Enable analytical event logging; Analytic events; Performance considerations. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish Enabling a log channel does not establish retention, collection health, privacy treatment, or an acceptable performance cost. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Article introduction, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Enable analytical event logging; Analytic events; Performance considerations, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Article introduction; Enable analytical event logging; Analytic events; Performance considerations to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Enable DNS Logging and Diagnostics in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-logging-and-diagnostics) — Microsoft ## Primary reference - Name: Enable DNS Logging and Diagnostics in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-logging-and-diagnostics - Source publication date: 2025-02-27 ## Citation and use Preferred citation: “Collect Windows DNS audit and analytic events with a measured volume budget,” DSE Security, https://update.dsesecurity.com/updates/collect-windows-dns-audit-and-analytic-events-with-a-measured-volume-budget/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Combine PAM access controls with Defender for Identity behavior analytics > Use Integrate Defender for Identity with PAM services to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/combine-pam-controls-with-identity-behavior-analytics/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:14+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Integrate Defender for Identity with PAM services to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Integrate Defender for Identity with PAM services ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Combine PAM access controls with Defender for Identity behavior analytics. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Integrate Defender for Identity with PAM services](https://learn.microsoft.com/en-us/defender-for-identity/integrate-microsoft-and-pam-services) from Microsoft supports the following bounded statements: - PAM solutions can vault privileged credentials, control access through approval workflows, monitor sessions, and enforce just-in-time and just-enough-access policies. The research record locates this support at Opening PAM overview. - When integrated with PAM, Defender for Identity combines privileged-access controls with behavioral analytics and automatically tags PAM-managed identities for investigation context. The research record locates this support at Integration benefits section. The source support ends with the statements listed above. Use them to examine identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs in the applicable environment, not to imply a wider guarantee. ## What the source does not establish PAM integration supplements rather than replaces privileged-access governance, credential rotation, session controls, or independent alert validation. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening PAM overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Integration benefits section, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening PAM overview; Integration benefits section. Favor integration configuration, connectivity tests, event timestamps, alert correlation, role assignments, and case records, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Integrate Defender for Identity with PAM services](https://learn.microsoft.com/en-us/defender-for-identity/integrate-microsoft-and-pam-services) — Microsoft ## Primary reference - Name: Integrate Defender for Identity with PAM services - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/integrate-microsoft-and-pam-services - Source publication date: 2025-03-30 ## Citation and use Preferred citation: “Combine PAM access controls with Defender for Identity behavior analytics,” DSE Security, https://update.dsesecurity.com/updates/combine-pam-controls-with-identity-behavior-analytics/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Commission a commercial intrusion alarm to resist false dispatches > A false-alarm-resistant intrusion system depends on verified programming, device-by-device testing, monitoring-center coordination, and a documented user handoff, not merely a panel that supports the right features. - Canonical URL: https://update.dsesecurity.com/updates/commercial-intrusion-alarm-false-dispatch-commissioning-handoff/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-28T14:22:00+00:00 - Modified: 2026-07-28T14:22:00+00:00 - Last reviewed by DSE: 2026-07-28 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Business Continuity - Reading time: 2 minutes ## What you need to know A false-alarm-resistant intrusion system depends on verified programming, device-by-device testing, monitoring-center coordination, and a documented user handoff, not merely a panel that supports the right features. ## Potentially affected Commercial intrusion alarm owners, facility teams, security managers, integrators, monitoring providers, and employees who open, close, arm, disarm, or respond to alarm events. ## DSE recommendation Validate the installed system against manufacturer instructions, applicable alarm rules, monitoring procedures, site operations, and the false-alarm-reduction capabilities addressed by ANSI/SIA CP-01-2019. ## Article ## Source fact: compliant equipment still needs correct commissioning The Security Industry Association’s [official CP-01-2019 release announcement](https://www.securityindustry.org/wp-json/wp/v2/posts?slug=security-industry-association-releases-ansi-approved-cp-01-false-alarm-reduction-standard) says the standard addresses false-alarm-reduction features for security systems, applies to residential and commercial properties, and is intended for use or reference by security-industry professionals. Equipment capability is only one layer: detector selection, installation conditions, programming, monitoring data, permits, user behavior, and maintenance all affect false dispatches. The detailed standard is proprietary. Obtain the authorized standard and current instructions for the exact listed equipment. Confirm applicable requirements with the authority having jurisdiction and monitoring provider. Do not copy delay values or feature settings from an unrelated panel, an old project, or this article; record each selected setting and approved deviation in the project evidence. ## Resolve operating conditions before programming Document opening and closing times, late workers, cleaners, deliveries, occupied areas after arming, expected entry and exit routes, environmental conditions, animals, machinery, and spaces whose use changes seasonally. Confirm permit or registration duties, call and verification procedures, dispatch conditions, testing process, and continuously reachable responsible parties. Assign a customer system administrator, monitoring-account owner, and after-hours decision maker. Place the account on test before generating signals and agree on the start and end. Inspect doors, contacts, cabling, enclosure tamper, detector mounting, motion coverage, power, communications, and exposure to air movement, sunlight, pests, moving stock, or machinery. Correct physical causes instead of hiding them with broad bypasses or unjustified sensitivity changes. ## DSE recommendation: prove the complete alarm chain - Activate each field point individually. Reconcile the physical location, device, panel zone, keypad text, service record, and monitoring-center description. - Test normal, alarm, restore, tamper, and trouble behavior where supported. Exercise approved arming, exit, re-entry, disarming, accidental activation, and cancellation scenarios. - Generate representative events over each reporting path. Confirm the correct account, site, event type, zone text, sequence, restoration, and operator procedure. - Perform manufacturer-approved primary-power and battery checks without creating an unsafe outage. Record equipment versions, measurements, exceptions, and result. - Reconcile the installer’s test sheet with the monitoring event history, then obtain explicit confirmation that the account has returned to service. - Train every operating shift at the actual keypad or application. Users should practice arming, entry, disarming, recognizing trouble, reporting an accidental alarm, and contacting monitoring without sharing personal codes. Deliver an as-built point list, relevant programming record, monitoring test evidence, contact and dispatch plan, permit information, open-defect register, and a secure site-specific quick guide. During an initial stabilization period, review every alarm, cancellation, trouble, and communication failure by cause and owner. Repeated events require investigation, not silent bypass. Final acceptance should show that a correctly identified signal reaches a prepared person who can take the approved action. ## Primary reference - Name: Security Industry Association: ANSI/SIA CP-01-2019 release announcement - Authority: Security Industry Association - URL: https://www.securityindustry.org/wp-json/wp/v2/posts?slug=security-industry-association-releases-ansi-approved-cp-01-false-alarm-reduction-standard - Source publication date: 2019-07-08 ## Citation and use Preferred citation: “Commission a commercial intrusion alarm to resist false dispatches,” DSE Security, https://update.dsesecurity.com/updates/commercial-intrusion-alarm-false-dispatch-commissioning-handoff/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Commission an automatic gate as one safety-and-security system > An automatic gate combines a moving operator, entrapment protection, access decisions, vehicle detection, communications, emergency operation, and physical site conditions. Product labels cover defined scopes; only integrated testing proves the installed workflow. - Canonical URL: https://update.dsesecurity.com/updates/commission-automatic-gate-ul-325-ul-294-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:33:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: Access Control, Business Continuity - Reading time: 3 minutes ## What you need to know An automatic gate combines a moving operator, entrapment protection, access decisions, vehicle detection, communications, emergency operation, and physical site conditions. Product labels cover defined scopes; only integrated testing proves the installed workflow. ## Potentially affected Automatic vehicle gates and barrier arms, gate operators, access controllers, readers and LPR, safety sensors, loops, edges, photoelectric devices, intercoms, emergency controls, power and network links. ## DSE recommendation Confirm the approved design and certification scopes, then witness the complete gate sequence for authorized, denied, obstructed, tailgating, power-loss, communication-loss, emergency, and restoration scenarios. ## Article ## Source facts: safety and access-control evaluations have different scopes UL Solutions’ [Securing Peace of Mind: Access Control and Gate Operators](https://www.ul.com/news/securing-peace-mind-access-control-and-gate-operators) explains that UL 325 is the primary safety standard for automatic gates and door operators. It also states that access-control features associated with a gate are not evaluated for physical or cyber security under UL 325. UL describes UL 294, the Standard for Access Control System Units, as a complementary evaluation for security-related safety, digital security, and performance. That boundary matters when several compliant products become one installed system. The operator moves the gate, while readers, license-plate recognition, intercoms, access controllers, loops, photoelectric devices, edges, relays, network links, schedules, and emergency procedures influence when and how it moves. Certification evidence should be checked for the exact product and application; it is not a substitute for approved design, manufacturer instructions, applicable requirements, or site acceptance. This article does not determine code compliance or prescribe gate safety design. The current adopted requirements, authority having jurisdiction, qualified gate professional, design documents, and instructions for every installed component govern the project. ## DSE recommendation: test the complete movement decision Before operation, assemble a controlled gate record: opening identifier, location and use, gate and operator models, certification files, approved class or application, travel limits, access controller and credentials, safety and presence devices, manual controls, emergency provisions, warning devices and signs, power, network, monitoring, and responsible service parties. Reconcile that record to the installed equipment. - Inspect the physical environment. Check the gate path, adjacent fence and gaps, grade, drainage, vegetation, public approach, pedestrian paths, pinch or reach areas, mounting, guards, fasteners, stops, conduit, cabinets, and changes since design. Escalate any safety concern before powered testing. - Prove safety devices independently. Following the manufacturer’s procedure and approved test method, activate each monitored entrapment-protection or presence device through the relevant travel. Confirm the expected gate response, controller indication, trouble supervision, and behavior if a device is disconnected or faulted. - Exercise access decisions. Test valid, invalid, expired, and disabled credentials; approved vehicle detection; intercom release; remote commands; schedules; and any LPR workflow. Confirm that one authorization creates only the intended movement and event record. - Challenge vehicle sequencing. Test an authorized vehicle that stops, reverses, follows another vehicle, or leaves the detection area, plus a second vehicle approaching during movement. Use controlled tests and qualified personnel; do not place anyone in a hazardous path. - Remove dependencies safely. Exercise approved loss of utility power, standby power behavior, controller or reader communications, network service, and remote-management path. Confirm that failure does not create an undocumented authorization or unsafe movement. - Test emergency and manual operation. With authorized stakeholders, verify the approved fire-service, responder, emergency, and manual-release procedures, including how the gate is secured or returned to service afterward. Capture the event at all relevant layers: device indication, operator behavior, access-control transaction, video or intercom context, monitoring alert, and physical gate movement. Record elapsed time where a delayed network or cloud decision could affect operation. Verify that a remote user can see the correct opening and current state before issuing a command. Deliver a site-specific operating guide that separates normal access, a safety obstruction, equipment trouble, power loss, emergency access, and service mode. Identify who can disable or restore a gate and how that action is documented. Revalidate at the manufacturer’s required intervals and after impact, mechanical adjustment, safety-device replacement, controller or firmware change, access-integration change, paving, fencing, or recurring nuisance behavior. Do not bypass a safety device to keep traffic moving. The acceptance result should demonstrate that safety sensing, access authority, movement, monitoring, and recovery remain coherent as one system. ## Official references - UL Solutions, [Securing Peace of Mind: Access Control and Gate Operators](https://www.ul.com/news/securing-peace-mind-access-control-and-gate-operators), December 2, 2019. - UL Solutions, [Access Control System Testing and Certification](https://www.ul.com/services/access-control-system-testing-and-certification), accessed August 11, 2026. ## Primary reference - Name: UL Solutions: Securing Peace of Mind—Access Control and Gate Operators - Authority: UL Solutions - URL: https://www.ul.com/news/securing-peace-mind-access-control-and-gate-operators - Source publication date: 2019-12-02 ## Citation and use Preferred citation: “Commission an automatic gate as one safety-and-security system,” DSE Security, https://update.dsesecurity.com/updates/commission-automatic-gate-ul-325-ul-294-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Commission exterior security lighting for the people who must use and maintain it > Exterior lighting should support specific human tasks without disabling glare, deep shadow, uncontrolled spill, failed controls, or an unmaintainable layout. Define the task, design to maintained performance, then measure and walk the installed result at night. - Canonical URL: https://update.dsesecurity.com/updates/commission-exterior-security-lighting-for-people-and-maintenance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:07:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity - Reading time: 3 minutes ## What you need to know Exterior lighting should support specific human tasks without disabling glare, deep shadow, uncontrolled spill, failed controls, or an unmaintainable layout. Define the task, design to maintained performance, then measure and walk the installed result at night. ## Potentially affected Entrances, exits, pedestrian paths, parking, loading, gates, fences, building perimeters, guard posts, identification and intercom stations, luminaires, poles, controls, emergency or standby power, and lighting maintenance. ## DSE recommendation Assign a human task to each exterior zone, have qualified professionals design the lighting, document maintained-performance assumptions, test controls and alternate states, measure representative points, walk for glare and shadow, and establish maintenance triggers. ## Article ## Source facts: exterior lighting is designed around tasks and maintained conditions The Department of Defense’s [UFC 3-530-01, Interior and Exterior Lighting Systems and Controls](https://www.wbdg.org/dod/ufc/ufc-3-530-01), published February 9, 2023 and updated by Change 1 on December 15, 2023, provides design requirements based on the Illuminating Engineering Society lighting library and federal energy policy. It covers exterior applications, calculation, equipment, controls, commissioning, and maintenance considerations. The UFC treats lighting as more than fixture wattage. Design criteria vary by application and consider illuminance, uniformity, vertical and horizontal tasks, glare, light trespass, color qualities, controls, energy use, environmental conditions, and light loss over time. Maintained performance matters because lamp or LED depreciation, dirt, component failure, weather, and surface changes can reduce the result after installation. The UFC is mandatory within its stated Department of Defense scope; it is not automatically the code for a private property. Local electrical, energy, building, environmental, accessibility, zoning, and dark-sky rules, the adopted design standard, and qualified professional judgment determine a commercial project. Numeric criteria should come from the applicable task and standard, not a generic “security foot-candle” copied between sites. ## DSE recommendation: accept the nighttime task, not the fixture schedule Divide the site into operating zones and assign each a human task: find an entrance, read a sign, use a credential reader, see a step or obstacle, recognize another person at conversational distance, inspect a vehicle or delivery, observe a gate condition, patrol a boundary, reach an exit discharge, or safely restore equipment. Record who performs the task, viewing direction, distance, hours, adaptation state, and degraded conditions. - Survey the existing night scene. Walk after full darkness with operations, facilities, security, accessibility, and the lighting designer. Mark shadows, glare sources, reflected light, spill onto neighbors or roads, vegetation, snow storage, parked vehicles, signs, level changes, and areas where one bright source makes adjacent space harder to see. - Design to maintained conditions. Require calculations and assumptions for the applicable task plane, uniformity, surface reflectance, dirt and depreciation, temperature, mounting, shielding, controls, and maintenance. Distinguish initial output from the expected condition immediately before scheduled service. - Coordinate physical placement. Confirm poles and luminaires do not create climbing aids, vehicle conflicts, blocked accessible routes, gate interference, door-clearance problems, maintenance hazards, or responder obstructions. Protect accessible disconnects and control equipment according to the approved electrical design. - Test every control state. Exercise schedules, photocells, occupancy or adaptive controls, manual overrides, event modes, curfew levels, power interruption, restart, and emergency or standby operation where provided. Verify who receives a failure report and how the area is protected until repair. - Measure and walk. Have the qualified team measure representative horizontal and vertical points using the approved method, then perform each defined task from the real approach direction. Check darkest points, transitions, perimeter edges, face-level glare, wet pavement, reflective signs, and the view from occupied neighboring property or public roads. - Preserve the accepted baseline. Record fixture and driver, optics, mounting and aim, control settings, measurement grid, weather, surface condition, readings, task results, exceptions, and night photographs. Future maintenance needs a repeatable reference, not a statement that the lot once looked bright. Create inspection triggers for failed or cycling luminaires, shifted aim, dirty lenses, damaged shields, vegetation growth, construction, changed parking, new signage, repeated complaints, and control overrides. Define safe access for cleaning and replacement, compatible parts, and temporary lighting. Recheck task performance after material changes rather than replacing components and assuming equivalence. Avoid judging quality from directly beneath a pole. The person approaching the site experiences contrast, adaptation, glare, and shadow across the whole path. The accepted system should help people make the intended physical decisions while remaining maintainable, energy-conscious, and respectful of adjacent spaces. More light is not automatically more security; usable, controlled, measured light is. ## Official references - U.S. Department of Defense, [UFC 3-530-01, Interior and Exterior Lighting Systems and Controls, Change 1](https://www.wbdg.org/dod/ufc/ufc-3-530-01), December 15, 2023. - Whole Building Design Guide, [Unified Facilities Criteria public library](https://www.wbdg.org/dod/ufc), current publication status reviewed August 11, 2026. ## Primary reference - Name: DoD UFC 3-530-01: Interior and Exterior Lighting Systems and Controls, Change 1 - Authority: www.wbdg.org - URL: https://www.wbdg.org/dod/ufc/ufc-3-530-01 - Source publication date: 2023-12-15 ## Citation and use Preferred citation: “Commission exterior security lighting for the people who must use and maintain it,” DSE Security, https://update.dsesecurity.com/updates/commission-exterior-security-lighting-for-people-and-maintenance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Commission fire-detection systems through acceptance, restoration, and maintenance > Use 29 CFR 1910.164 - Fire detection systems to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/commission-fire-detection-systems-through-acceptance-restoration-and-maintenance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:19+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.164 - Fire detection systems to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.164 - Fire detection systems ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Commission fire-detection systems through acceptance, restoration, and maintenance. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.164 – Fire detection systems](https://www.ecfr.gov/current/title-29/section-1910.164) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, the rule requires that the employer assure that the servicing, maintenance and testing of fire detection systems, including cleaning and necessary sensitivity adjustments are performed by a trained person knowledgeable in the operations and functions of the system. The research record locates this support at 29 CFR 1910.164(c)(4) (eCFR anchor p-1910.164(c)(4)). - Under 29 CFR 1910, the rule requires that the employer assure that fire detection systems installed for the purpose of employee alarm and evacuation be designed and installed to provide a warning for emergency action and safe escape of employees. The research record locates this support at 29 CFR 1910.164(e)(2) (eCFR anchor p-1910.164(e)(2)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths and the conditions the source actually describes. ## What the source does not establish Federal workplace rule; fire code, listing, design standards, monitoring arrangements, and authority-having-jurisdiction requirements also apply. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.164(c)(4) (eCFR anchor p-1910.164(c)(4)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.164(e)(2) (eCFR anchor p-1910.164(e)(2)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from 29 CFR 1910.164(c)(4) (eCFR anchor p-1910.164(c)(4)); 29 CFR 1910.164(e)(2) (eCFR anchor p-1910.164(e)(2)) to the observed environment. Useful domain evidence includes facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [29 CFR 1910.164 – Fire detection systems](https://www.ecfr.gov/current/title-29/section-1910.164) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.164 - Fire detection systems - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.164 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Commission fire-detection systems through acceptance, restoration, and maintenance,” DSE Security, https://update.dsesecurity.com/updates/commission-fire-detection-systems-through-acceptance-restoration-and-maintenance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Commission illumination as part of the camera system > Light quantity alone does not determine video performance. Distribution, spectrum, beam angle, distance, surfaces, exposure, and the required task must be tested together. - Canonical URL: https://update.dsesecurity.com/updates/commission-illumination-as-part-of-the-camera-system/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:58+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Video Surveillance - Reading time: 2 minutes ## What you need to know Light quantity alone does not determine video performance. Distribution, spectrum, beam angle, distance, surfaces, exposure, and the required task must be tested together. ## Potentially affected Camera projects adding or relying on visible or infrared illumination for nighttime, indoor, perimeter, parking, or identification tasks. ## DSE recommendation Specify lighting at the target plane and accept it with recorded video across the whole task zone, including the darkest and most reflective conditions. ## Article Bottom line: a lux value at one convenient point cannot accept a camera scene. Useful illumination must reach the subject with the right distribution and spectrum while avoiding glare, deep shadow, overexposure, and motion blur. ## Source fact: quantity, quality, and distribution all affect video Axis’s [Lighting for network video](https://whitepapers.axis.com/en-us/lighting-for-network-video) explains that camera performance depends on the quantity, quality, and distribution of light. It says an illuminator beam should match the camera field of view, discusses the rapid reduction in illumination with distance, and distinguishes visible and infrared illumination. It also notes that surfaces reflect light differently and that accurate color requires suitable visible light. The camera and lighting design therefore share one acceptance task. A bright foreground can force exposure down while the required face or vehicle remains dark farther away. ## Source boundary and applicability The paper provides Axis guidance, not a universal lux threshold or photometric design for a site. Camera sensitivity claims, lux measurements, spectral response, lens, exposure, weather, dirt, subject reflectivity, ambient competition, and mounting geometry affect results. Lighting work must also follow applicable electrical, glare, accessibility, environmental, and neighborhood requirements. ## Applicability questions - What subject and detail must be captured at each position in the task zone? - Is usable color required, or is monochrome infrared acceptable? - Do the camera field of view and illuminator beam remain aligned at all required distances? - Which signs, plates, clothing, walls, moisture, snow, or vegetation can create reflection or shadow? - What happens when adjacent lights fail, dim, cycle, or are controlled by another system? ## DSE recommendation: accept light and recorded image together The following steps are DSE recommendations based on the cited source. Create a plan showing camera views, target planes, illuminator locations, beam coverage, ambient sources, and required image task. Take documented measurements at representative target planes using appropriate instruments, but make the retrieved recorded video the final operational test. Walk realistic subjects through near, middle, far, edge, shadow, and reflective areas under the darkest expected condition. Inspect exposure time and motion detail, not only brightness. Adjust beam, placement, output, camera exposure, or supplemental light through coordinated change control. Confirm the design after a light failure and after the site switches between operating modes. Record who owns lamp replacement, cleaning, aiming, seasonal inspection, and notification when an external lighting system changes state. ## Verification and evidence Retain the lighting and camera plan, equipment models, measurement method and readings, weather and ambient conditions, camera settings, native clips from every test position, motion-detail assessment, failure-mode result, and acceptance sign-off. Re-test after landscaping, signage, surface, lamp, camera, lens, or exposure changes. ## Official references - [Lighting for network video](https://whitepapers.axis.com/en-us/lighting-for-network-video) – Axis Communications ## Primary reference - Name: Lighting for network video - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/lighting-for-network-video - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Commission illumination as part of the camera system,” DSE Security, https://update.dsesecurity.com/updates/commission-illumination-as-part-of-the-camera-system/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Commission intercoms as audio, identity, network, and escalation systems > A call button that rings once is not a commissioned entry workflow. Verify intelligible two-way audio, visual and identity context, correct release, network and power loss, unanswered-call escalation, accessibility, privacy, and operator action. - Canonical URL: https://update.dsesecurity.com/updates/commission-intercoms-as-audio-identity-network-escalation-systems/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:07:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Business Continuity, Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know A call button that rings once is not a commissioned entry workflow. Verify intelligible two-way audio, visual and identity context, correct release, network and power loss, unanswered-call escalation, accessibility, privacy, and operator action. ## Potentially affected Door and gate intercoms, call stations, master stations, mobile clients, cameras, door releases, PACS and VMS integrations, SIP and networks, power, hearing-assistance and accessibility features, reception and monitoring teams, recordings, and escalation procedures. ## DSE recommendation Define each station’s approved entry workflow, test communication and release from the caller and operator positions under representative conditions, exercise failure and no-answer paths, confirm security and privacy controls, train every answering group, and retain witnessed results. ## Article ## Source facts: remote entry combines communication with an access decision A General Services Administration [Solicitation for Offers template](https://www.gsa.gov/system/files/SFO_09_09.pdf) includes entry-security provisions for intercoms and for systems that allow employees to view and communicate remotely with visitors before permitting access. It also places visitor control and screening in the context of a building security assessment. This is a dated federal leasing template, not a current universal design standard; its value here is the explicit connection between communication, visual context, and release. CISA’s [Facility Access Control: An Interagency Security Committee Best Practice](https://www.cisa.gov/sites/default/files/2025-02/Facility%20Access%20Control%20-%20An%20Interagency%20Security%20Committee%20Best%20Practice-02-20.pdf) treats visitor entry as a risk-based process involving identification, screening, authorization, escort, and the PACS. An intercom can support that process, but it does not establish identity merely because someone answers a question. Applicable accessibility, privacy, recording, telecommunications, building, fire, and licensing rules vary. The approved design and authority having jurisdiction govern door release and egress. Manufacturer and platform documentation govern supported audio, video, SIP, mobile, encryption, failover, and integration features. Commissioning must not create a claim that an intercom alone authenticates a person. ## DSE recommendation: test the decision from both sides of the opening Write the approved workflow for every call station: who may call, who answers by time of day, what visual or business context appears, what questions or sponsor verification are allowed, which opening can be released, how long it releases, what is recorded, and what happens when nobody answers. Include delivery entrances, vehicle gates, accessible routes, after-hours calls, and emergency requests. - Verify caller experience. From normal approach positions, test labels, lighting, reach, tactile or visual indications where required, call progress, microphone and speaker, wind and traffic noise, feedback, rain protection, and instructions. Use qualified accessibility review rather than assuming mounting height or a video screen is sufficient. - Verify operator context. Confirm the correct station name, camera, door, site, call priority, directory, and procedure appear on every authorized desktop, master station, or mobile client. Similar labels such as “front door” across sites invite the wrong release. - Test intelligibility and delay. Speak naturally in both directions with doors closed, ordinary background noise, headsets, remote networks, and representative mobile coverage. Record packet loss, clipping, echo, delay, or one-way audio. A tone and moving level meter do not prove conversation. - Exercise the release safely. Under approved life-safety conditions, verify the operator releases only the intended opening, receives position feedback, observes held or forced conditions, and cannot accidentally activate another site. Confirm the door relatches and the event is logged. - Test no-answer and failure paths. Leave calls unanswered; fail one answering client, network path, server, and normal power through approved methods; and observe overflow, local indication, alarms, degraded release, and recovery. Protect egress and provide compensating control throughout. - Verify security and privacy. Review accounts, least privilege, default credentials, firmware, certificates or encryption where supported, exposed services, call and video retention, notices, exports, and remote access. Limit who can listen, view, release, administer, or retrieve recordings. Run scenario tests: an expected visitor, an unknown delivery, a caller who cannot be understood, tailgating after release, a sponsor who does not answer, an operator handling two calls, and a false call intended to distract. Grade the procedure and the technology separately so training does not hide an integration defect. Retain station and client versions, network and power conditions, call recordings only when authorized, results, exceptions, witnesses, and restoration evidence. Retest after routing, directory, staffing, network, firmware, door hardware, or client changes. Commission the full human decision path—not simply the button. ## Official references - U.S. General Services Administration, [Solicitation for Offers template, entry-security provisions](https://www.gsa.gov/system/files/SFO_09_09.pdf). - Cybersecurity and Infrastructure Security Agency, Interagency Security Committee, [Facility Access Control: An ISC Best Practice](https://www.cisa.gov/sites/default/files/2025-02/Facility%20Access%20Control%20-%20An%20Interagency%20Security%20Committee%20Best%20Practice-02-20.pdf). ## Primary reference - Name: GSA Solicitation for Offers: Entry security intercom and remote entry control provisions - Authority: www.gsa.gov - URL: https://www.gsa.gov/system/files/SFO_09_09.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Commission intercoms as audio, identity, network, and escalation systems,” DSE Security, https://update.dsesecurity.com/updates/commission-intercoms-as-audio-identity-network-escalation-systems/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Commission license-plate capture for the lane, speed, and night > License-plate recognition starts with a readable captured plate. Prove the camera at the real lane angle, vehicle speed, capture distance, day/night lighting, and recording settings before trusting the recognition result or gate action. - Canonical URL: https://update.dsesecurity.com/updates/commission-license-plate-capture-real-lane-speed-night/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:41:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Video Surveillance - Reading time: 4 minutes ## What you need to know License-plate recognition starts with a readable captured plate. Prove the camera at the real lane angle, vehicle speed, capture distance, day/night lighting, and recording settings before trusting the recognition result or gate action. ## Potentially affected License-plate capture and recognition cameras, vehicle gates, parking systems, VMS platforms, infrared illuminators, edge analytics, allowlists, and event integrations. ## DSE recommendation Define a lane-specific capture envelope, test authorized vehicles across representative speeds and lighting, reconcile reads to recorded images, and fail safely when a plate is absent, ambiguous, or misread. ## Article ## Source facts: recognition quality begins before the algorithm Axis Communications’ [License plate capture](https://whitepapers.axis.com/en-us/license-plate-capture) white paper distinguishes license-plate capture—the production of a readable plate image—from license-plate recognition, where software locates and reads the characters. It states that recognition rate and accuracy depend strongly on the captured image and that a sophisticated algorithm cannot read a plate that is not clearly visible. The source explains that license-plate work uses different installation and exposure choices than general surveillance. Camera-to-vehicle angle, lane width, capture distance, vehicle speed, field of view, shutter time, gain, infrared illumination, focus, and the plate’s size in pixels all affect the result. Axis recommends minimizing the total viewing angle, accounting for the time a vehicle remains in the capture zone, and limiting exposure time to reduce motion blur. At night, reflective plates and infrared light create a different exposure problem from the surrounding scene; excessive gain or poor illuminator placement can wash out the characters. More image data is not automatically better for edge recognition. The source notes that enough pixels are required to resolve characters, but excessive resolution can increase analysis time and contribute to missed plates in dense traffic. Product and analytics instructions for the specific deployment remain controlling. The published values and examples are design guidance, not proof for every plate format, jurisdiction, lane, camera, or recognition engine. ## DSE recommendation: define and test a capture envelope For each lane, draw the region in which a valid read is expected. Record its near and far boundaries, lane width, permitted direction, expected speed range, vehicle types, camera angle, mounting height, lighting, and the action a recognized plate can request. A camera that reads a parked test car does not prove performance for a moving vehicle at night. - Separate capture from decision. First confirm that recorded frames contain a sharp, properly exposed plate. Then measure whether the recognition engine extracts the correct characters. Finally test any lookup, alert, or gate workflow. This makes it possible to locate a failure instead of blaming “the LPR.” - Use an authorized, varied test set. Include representative passenger vehicles, trucks where relevant, front and rear plates as applicable, clean and moderately weathered plates, and normal mounting variation. Record expected values securely and avoid collecting unnecessary plate data. - Drive the real approach. Test the low, normal, and highest approved speeds; expected lateral positions; vehicle following distance; stops and rolling approaches; and both travel directions if supported. Confirm that a vehicle cannot bypass the intended capture zone through an adjacent path. - Test day and night separately. Exercise direct sun, shade, headlights, wet pavement or other material reflections, artificial lighting, and infrared operation. Review glare, overexposure, motion blur, focus, and day/night switching at the plate—not only the overall scene. - Measure outcomes. Track total passes, plates captured readably, correct full reads, partial reads, wrong reads, duplicates, missed events, and time from capture to action. Preserve examples of each failure category so tuning remains evidence-based. - Exercise the safe exception path. An unreadable, ambiguous, expired, duplicated, or unlisted plate should not silently become authorized. Verify the approved manual review, alternate credential, intercom, denial, alert, and audit behavior. Where a plate triggers a gate, test the complete sequence with the gate safety system and access policy: approach detection, read, authorization, open command, vehicle passage, close behavior, tailgating or second-vehicle scenario, loss of network, loss of analytics, and stale allowlist. Recognition is one input to the opening workflow; it does not replace the operator’s safety devices or the applicable gate requirements. Save the accepted camera image settings, analytics version, region of interest, lane map, test evidence, exception rules, and change owner. Revalidate after camera movement, focus or firmware changes, pavement or lighting work, analytics updates, lane reconfiguration, or repeated error patterns. Protect plate records, allowlists, and exported test data according to the organization’s approved access, retention, and privacy practices. A dependable system proves the plate image, the read, and the action as three connected but separately testable stages. ## Official reference - Axis Communications, [License plate capture](https://whitepapers.axis.com/en-us/license-plate-capture), December 2024. ## Primary reference - Name: Axis Communications: License plate capture - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/license-plate-capture - Source publication date: 2024-12-01 ## Citation and use Preferred citation: “Commission license-plate capture for the lane, speed, and night,” DSE Security, https://update.dsesecurity.com/updates/commission-license-plate-capture-real-lane-speed-night/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Commission radar as a perimeter sensor, not a magic field > Radar can add reliable movement, position, and speed data where light, fog, shadows, or privacy limit video. Its blind spots, reflections, classification limits, zones, and response integrations still need real-scene acceptance testing. - Canonical URL: https://update.dsesecurity.com/updates/commission-radar-perimeter-detection-real-scene/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:37:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know Radar can add reliable movement, position, and speed data where light, fog, shadows, or privacy limit video. Its blind spots, reflections, classification limits, zones, and response integrations still need real-scene acceptance testing. ## Potentially affected Outdoor perimeter radar, radar-video fusion devices, PTZ tracking, thermal cameras, VMS event rules, horn speakers, lighting relays, guard workflows, maps, and network integrations. ## DSE recommendation Define the radar detection task and response boundary, test representative targets and nuisance conditions across the full scene, and prove every linked camera, audio, lighting, and operator action before production. ## Article ## Source facts: radar complements visual detection Axis Communications’ July 2026 [Radar in surveillance](https://whitepapers.axis.com/en-us/radar-in-surveillance) white paper explains that security radar uses reflected radio waves to estimate properties such as an object’s location, speed, direction, and size. Unlike a visual camera, radar is not dependent on visible light and is less affected by conditions such as darkness, backlight, moving shadows, and fog. It can also support non-visual detection where identifying imagery is not desired. The source describes combinations with visual or thermal cameras, PTZ autotracking, speakers, lighting, recording, maps, and alerts. These integrations can let one sensor detect and locate movement while another supplies identification detail or an operator-facing view. Radar therefore provides a different layer; it does not make every other sensor unnecessary. Axis also documents practical limitations. Reflective materials and complex environments can create unwanted detections. Swaying objects, very slow movement, closely spaced people or vehicles, mounting geometry, terrain, profile selection, neighboring radar interference, and device speed limits can affect tracking or classification. Include and exclude zones can reduce nuisance events, but an exclusion also creates an area where movement is intentionally ignored. ## DSE recommendation: prove the detection-to-response chain Give each radar a written job. Identify the protected boundary or area, target classes, direction and speed of concern, schedule, expected response, and conditions in which the sensor must work. Put those requirements on a site map. “Cover the yard” is not testable; “detect a walking person crossing this line after hours and present the correct camera to the guard” is. - Survey the radio scene. Record fences, walls, metal structures, parked vehicles, vegetation, slopes, roofs, adjacent roads, moving machinery, water, neighboring radars, and paths that targets can use. Compare the installation to the exact device manual and supported profile. - Validate geometry. Confirm mounting height, tilt, bearing, geolocation, detection zones, crossing lines, and exclusions. Walk the near and far boundaries and the seams between sensors. Test paths that approach, cross, and move parallel to the boundary. - Use representative targets. Exercise authorized people and vehicles at expected sizes, speeds, spacing, and directions. Include slow movement, short appearances, groups, stopped-and-started motion, and partial obstruction where those conditions matter. - Challenge nuisance conditions. Observe wind-driven foliage, gates, flags, rain or snow where practical, traffic outside the perimeter, maintenance activity, moving equipment, and changes in parked vehicles. Tune supported filters deliberately and record every exclusion. - Test sensor coexistence. Where several radars share an area, follow manufacturer limits and coexistence instructions. Prove the final arrangement with all devices operating, not one at a time on an otherwise quiet site. - Verify every response. Confirm the correct event, target classification, map location, camera preset or track, recording bookmark, speaker or light rule, notification, and operator instruction. Measure time from crossing to a usable operator view. Review misses and unwanted alarms separately. A lower event count is not an improvement if a broad exclude zone hides a valid approach. Likewise, a classification label should assist a response, not serve as unquestioned proof of identity or intent. Where a decision has serious consequences, require the approved corroboration and human review. Preserve the accepted map, device and firmware, profile, zones, filters, target matrix, weather and scene notes, test results, integration versions, and known limitations. Revalidate after construction, fence or vegetation changes, radar movement, firmware or analytics changes, a new neighboring sensor, or repeated unexplained events. Radar is valuable precisely because it observes different physical properties from video; it earns trust when those properties are tested in the actual perimeter rather than inferred from a demonstration. After handoff, trend verified detections, misses, and nuisance causes by zone. That history helps the team distinguish seasonal scene changes from configuration drift before repeated alarms weaken operator confidence. ## Official reference - Axis Communications, [Radar in surveillance](https://whitepapers.axis.com/en-us/radar-in-surveillance), July 2026. ## Primary reference - Name: Axis Communications: Radar in surveillance - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/radar-in-surveillance - Source publication date: 2026-07-01 ## Citation and use Preferred citation: “Commission radar as a perimeter sensor, not a magic field,” DSE Security, https://update.dsesecurity.com/updates/commission-radar-perimeter-detection-real-scene/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Compare an iSCSI Target design with supported and enforced limits > How should an iSCSI Target Server capacity review distinguish support limits from enforcement? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-023-compare-an-iscsi-target-design-with-supported-and-enforced-limits/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:48+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should an iSCSI Target Server capacity review distinguish support limits from enforcement? ## Potentially affected Use this review before expanding an iSCSI Target Server or changing its deployment model. ## DSE recommendation Build a capacity worksheet using the source's individual categories and the actual planned topology. ## Article ## Source facts Microsoft’s iSCSI Target Server reference separates tested support limits from limits enforced by the implementation. Its tables distinguish target instances, logical units, sessions, and snapshots rather than presenting one overall capacity figure. Microsoft marks converting between standalone and clustered iSCSI Target Server configurations as unsupported and warns that target, virtual-disk, and snapshot configuration metadata is lost during conversion. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/iscsi/iscsi-target-server-limits). ## Applicability Use this review before expanding an iSCSI Target Server or changing its deployment model. Match the operating-system version to the relevant table entries and identify which resource each proposed increase consumes. ## DSE recommendation Build a capacity worksheet using the source’s individual categories and the actual planned topology. Record current counts, proposed additions, and the applicable limit for each category. Have the storage owner review architectural changes separately from ordinary growth. Do not interpret a configuration being accepted by a tool as evidence that it remains within Microsoft’s tested support boundaries. ## Verification Compare the approved worksheet with the completed target, virtual-disk, and initiator inventory. Check the planned connection paths through a representative workload test. Retain any count discrepancy or unsupported conversion proposal as an unresolved design issue. Revisit the worksheet before the next expansion, using the then-current vendor reference. ## Official references [Microsoft Learn: iSCSI Target Server Scalability Limits](https://learn.microsoft.com/en-us/windows-server/storage/iscsi/iscsi-target-server-limits). Source reviewed September 8, 2026. ## Primary reference - Name: iSCSI Target Server Scalability Limits - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/iscsi/iscsi-target-server-limits - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Compare an iSCSI Target design with supported and enforced limits,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-023-compare-an-iscsi-target-design-with-supported-and-enforced-limits/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Compare DNS labels case-insensitively while preserving original case > Use RFC 4343 — Domain Name System (DNS) Case Insensitivity Clarification to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/compare-dns-labels-case-insensitively-while-preserving-original-case/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:44+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4343 — Domain Name System (DNS) Case Insensitivity Clarification to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4343 — Domain Name System (DNS) Case Insensitivity Clarification ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Compare DNS labels case-insensitively while preserving original case. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4343 — Domain Name System (DNS) Case Insensitivity Clarification](https://www.rfc-editor.org/rfc/rfc4343.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - ASCII letters in DNS names are compared case-insensitively throughout the DNS protocol. The research record locates this support at Section 2 (Case Insensitivity of DNS Labels). - DNS implementations should preserve the original case of names when possible even though protocol comparisons ignore ASCII case. The research record locates this support at Section 4 (Case Preservation). - Case preservation may retain the first spelling, replace it with later input, or store multiple variants without changing case-insensitive matching. The research record locates this support at Section 4.2 (Case Preservation in DNS Servers). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2 (Case Insensitivity of DNS Labels), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4 (Case Preservation), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4.2 (Case Preservation in DNS Servers), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to Section 2 (Case Insensitivity of DNS Labels); Section 4 (Case Preservation); Section 4.2 (Case Preservation in DNS Servers) and to observable material such as zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 4343 — Domain Name System (DNS) Case Insensitivity Clarification](https://www.rfc-editor.org/rfc/rfc4343.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4343 — Domain Name System (DNS) Case Insensitivity Clarification - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4343.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Compare DNS labels case-insensitively while preserving original case,” DSE Security, https://update.dsesecurity.com/updates/compare-dns-labels-case-insensitively-while-preserving-original-case/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Compare intended and operational network state after automation > Use intended-versus-operational datastore evidence to find configuration that was rejected, modified, or not realized. - Canonical URL: https://update.dsesecurity.com/updates/compare-intended-and-operational-network-state/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:35+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Explainer - DSE priority: Important - Topics: Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use intended-versus-operational datastore evidence to find configuration that was rejected, modified, or not realized. ## Potentially affected Networks managed through YANG-based NETCONF or RESTCONF automation and controllers ## DSE recommendation Verify that intended configuration is present and effective in operational state after every automated change. ## Article An automation job reporting success proves that a transaction completed according to the tool’s view. It does not prove that every intended resource exists, that the device accepted it as expected, or that the resulting operational state matches the service design. ## Source fact: [IETF RFC 8342](https://datatracker.ietf.org/doc/rfc8342/) defines the Network Management Datastore Architecture for YANG-modeled configuration and state. The architecture distinguishes conventional, intended, and operational datastores. Intended configuration represents the configuration the system is meant to use after processing configuration sources, while operational state represents the system’s actual state, including applied configuration and system-generated or learned information. The RFC accounts for cases in which intended configuration is absent from operational state, operational resources are generated by the system, or values differ because of system behavior. It also defines how the architecture binds to NETCONF and RESTCONF. This separation gives management systems a way to reason about what was requested and what exists; it does not assert that all platforms expose every origin or state detail uniformly. ## Boundary YANG model coverage, datastore support, origin metadata, default handling, validation timing, and controller abstractions vary by implementation. Operational configuration being present does not prove packet forwarding or application health. Conversely, some legitimate dynamic state will never appear in intended configuration. A raw tree comparison without model awareness can generate noise from defaults, ephemeral state, ordering, or values controlled by the system. ## Applicability questions - Which devices and controllers implement the relevant NMDA datastores and origin metadata? - Which service assertions can be compared semantically rather than as raw serialized text? - How are defaults, generated identifiers, learned state, and system-controlled resources normalized? - What delay is expected between a committed change and stable operational state? - Which mismatches require rollback, investigation, or an approved exception? ## DSE recommendation: For each automated service, define a small set of postconditions tied to the YANG model: required resources, key values, relationships, administrative state, and relevant operational status. Query the intended and operational datastores through supported interfaces after the transaction and after an appropriate stabilization period. Interpret differences using origin and model semantics rather than a textual diff. Classify mismatches such as rejected configuration, remnant resources, missing dependencies, system-selected values, and delayed convergence. Fail the deployment or open an exception when a required postcondition is not met. Follow datastore verification with route, neighbor, forwarding, reachability, and application checks proportionate to the change. Preserve a rollback path that uses a known state, not merely the automation job’s prior input. ## Verification and evidence Keep device and model revisions, capability discovery, transaction identifiers, intended and operational queries, normalization rules, postcondition results, convergence timestamps, exceptions, and end-to-end probes. Evidence should allow a reviewer to trace one approved intent through device commit to observed state. Requalify comparisons after model, controller, or device upgrades because schema and origin behavior can change. ## Official references - [IETF RFC 8342](https://datatracker.ietf.org/doc/rfc8342/) ## Primary reference - Name: RFC 8342: Network Management Datastore Architecture - Authority: datatracker.ietf.org - URL: https://datatracker.ietf.org/doc/rfc8342/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Compare intended and operational network state after automation,” DSE Security, https://update.dsesecurity.com/updates/compare-intended-and-operational-network-state/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Compare modeled and actual Group Policy results > Use Group Policy Modeling and Results in Windows to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/compare-modeled-and-actual-group-policy-results/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:47+00:00 - Modified: 2026-08-27T12:56:26+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Group Policy Modeling and Results in Windows to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Group Policy Modeling and Results in Windows ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Compare modeled and actual Group Policy results. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Group Policy Modeling and Results in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-modeling-results) from Microsoft supports the following bounded statements: - Group Policy Modeling simulates GPO deployment to a destination computer. The research record locates this support at Opening overview. - Group Policy Results is the primary GPMC view for the policies actually applied. The research record locates this support at Opening overview. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles and the conditions the source actually describes. ## What the source does not establish Treat modeling as prediction and results as observed state; retain both when approving policy changes. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Opening overview. Favor directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Group Policy Modeling and Results in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-modeling-results) — Microsoft ## Primary reference - Name: Group Policy Modeling and Results in Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-modeling-results - Source publication date: 2024-04-16 ## Citation and use Preferred citation: “Compare modeled and actual Group Policy results,” DSE Security, https://update.dsesecurity.com/updates/compare-modeled-and-actual-group-policy-results/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Compare virtual NUMA topology with the host before changing memory placement > Which host and VM NUMA information should be compared before a topology change? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-196-compare-virtual-numa-topology-with-the-host-before-changing-memory-placement/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:55+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which host and VM NUMA information should be compared before a topology change? ## Potentially affected Administrators configuring NUMA topology for Hyper-V workloads. ## DSE recommendation Create a host-to-VM topology comparison and record the problem the proposed change is intended to address. ## Article ## Source facts Microsoft exposes host NUMA-node information through Get-VMHostNumaNode, including logical cores and memory available per node. A VM’s virtual NUMA configuration controls node count, processors per node, and memory per node. By default, the VM uses the host’s topology. The host NUMA-spanning setting applies only where the host has multiple NUMA nodes. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/configure-non-uniform-memory-access). ## Applicability Identify the physical topology, guest workload, current virtual topology, memory configuration, and intended migration hosts. Review the source’s platform requirements and the application’s NUMA guidance before changing placement settings. ## DSE recommendation Create a host-to-VM topology comparison and record the problem the proposed change is intended to address. Ask the application and virtualization owners to review node size and memory assumptions. Preserve the original configuration and define a representative workload measurement before making an adjustment. ## Verification Inspect the VM’s exposed topology and compare its placement with the approved design. Use the documented performance counters and application measurements during a controlled workload run. Record the physical host used for each test and revisit the result if the VM moves to a materially different topology. ## Official references [Microsoft Learn: Configure NUMA to Optimize Hyper-V Memory](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/configure-non-uniform-memory-access). Source reviewed September 8, 2026. ## Primary reference - Name: Configure NUMA to Optimize Hyper-V Memory - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/configure-non-uniform-memory-access - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Compare virtual NUMA topology with the host before changing memory placement,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-196-compare-virtual-numa-topology-with-the-host-before-changing-memory-placement/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Compile Program 3 process safety information before hazard analysis > Use 40 CFR 68.65 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/compile-program-3-process-safety-information-before-hazard-analysis/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:01+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.65 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.65 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Compile Program 3 process safety information before hazard analysis. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.65 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.65) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the owner or operator must complete a compilation of written process safety information before conducting any process hazard analysis required by this part and must keep process safety information up to date. The research record locates this support at 40 CFR 68.65(a) (eCFR anchor p-68.65(a)). - Under 40 CFR 68, where the original technical information no longer exists, such information may be developed in conjunction with the process hazard analysis in sufficient detail to support the analysis. The research record locates this support at 40 CFR 68.65(c)(2) (eCFR anchor p-68.65(c)(2)). Only the traced statements above are asserted as source facts. Apply the review to critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths after confirming that the source and deployed context match. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.65(a) (eCFR anchor p-68.65(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.65(c)(2) (eCFR anchor p-68.65(c)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to 40 CFR 68.65(a) (eCFR anchor p-68.65(a)); 40 CFR 68.65(c)(2) (eCFR anchor p-68.65(c)(2)) and to observable material such as facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [40 CFR 68.65 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.65) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.65 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.65 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Compile Program 3 process safety information before hazard analysis,” DSE Security, https://update.dsesecurity.com/updates/compile-program-3-process-safety-information-before-hazard-analysis/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Complete a pre-startup safety review before introducing regulated substances > Use 40 CFR 68.77 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/complete-a-pre-startup-safety-review-before-introducing-regulated-substances/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:55+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.77 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.77 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Complete a pre-startup safety review before introducing regulated substances. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.77 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.77) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the pre-startup safety review confirm that prior to the introduction of regulated substances to a process: construction and equipment is in accordance with design specifications. The research record locates this support at 40 CFR 68.77(b)(1), read with 40 CFR 68.77(b) (eCFR anchor p-68.77(b)(1)). - Under 40 CFR 68, the rule requires that the pre-startup safety review confirm that prior to the introduction of regulated substances to a process: safety, operating, maintenance, and emergency procedures are in place and are adequate. The research record locates this support at 40 CFR 68.77(b)(2), read with 40 CFR 68.77(b) (eCFR anchor p-68.77(b)(2)). The source support ends with the statements listed above. Use them to examine critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.77(b)(1), read with 40 CFR 68.77(b) (eCFR anchor p-68.77(b)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.77(b)(2), read with 40 CFR 68.77(b) (eCFR anchor p-68.77(b)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from 40 CFR 68.77(b)(1), read with 40 CFR 68.77(b) (eCFR anchor p-68.77(b)(1)); 40 CFR 68.77(b)(2), read with 40 CFR 68.77(b) (eCFR anchor p-68.77(b)(2)) to the observed environment. Useful domain evidence includes facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [40 CFR 68.77 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.77) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.77 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.77 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Complete a pre-startup safety review before introducing regulated substances,” DSE Security, https://update.dsesecurity.com/updates/complete-a-pre-startup-safety-review-before-introducing-regulated-substances/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Complete fingerprint-based history checks before granting required unescorted airport access > Use 49 CFR 1542.209 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/complete-fingerprint-based-history-checks-before-granting-required-unescorted-airport-access/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:30+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.209 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.209 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Complete fingerprint-based history checks before granting required unescorted airport access. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.209 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.209) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, the rule requires that except as provided in paragraph (m) of this section, each airport operator ensure that no individual is granted unescorted access authority unless the individual has undergone a fingerprint-based CHRC that does not disclose that he or she has a disqualifying criminal offense, as described in paragraph (d) of this section. The research record locates this support at 49 CFR 1542.209(b) (eCFR anchor p-1542.209(b)). - Under 49 CFR 1542, notwithstanding the requirements of this section, an airport operator may authorize the following individuals to have unescorted access authority: an individual who has been continuously employed by an aircraft operator or aircraft operator contractor, in a position with authority to perform screening functions, provided the grant for his or her authority to perform screening functions was based upon a fingerprint-based CHRC through TSA or FAA. The research record locates this support at 49 CFR 1542.209(m)(2)(ii), read with 49 CFR 1542.209(m)(2) (eCFR anchor p-1542.209(m)(2)(ii)). Only the traced statements above are asserted as source facts. Apply the review to credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces after confirming that the source and deployed context match. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 49 CFR 1542.209(b) (eCFR anchor p-1542.209(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.209(m)(2)(ii), read with 49 CFR 1542.209(m)(2) (eCFR anchor p-1542.209(m)(2)(ii)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to 49 CFR 1542.209(b) (eCFR anchor p-1542.209(b)); 49 CFR 1542.209(m)(2)(ii), read with 49 CFR 1542.209(m)(2) (eCFR anchor p-1542.209(m)(2)(ii)) and to observable material such as approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [49 CFR 1542.209 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.209) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.209 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.209 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Complete fingerprint-based history checks before granting required unescorted airport access,” DSE Security, https://update.dsesecurity.com/updates/complete-fingerprint-based-history-checks-before-granting-required-unescorted-airport-access/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Complete the WebSocket opening handshake before processing data frames > Use RFC 6455 — The WebSocket Protocol to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/complete-the-websocket-opening-handshake-before-processing-data-frames/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:57+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6455 — The WebSocket Protocol to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6455 — The WebSocket Protocol ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Complete the WebSocket opening handshake before processing data frames. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6455 — The WebSocket Protocol](https://www.rfc-editor.org/rfc/rfc6455.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A server rejects a WebSocket opening request that lacks the required GET, Host, Upgrade, Connection, 16-byte encoded key, or version-13 fields. The research record locates this support at Section 4.2.1 (Reading the Client’s Opening Handshake). - Accepting the connection requires status 101, Upgrade and Connection fields, and Sec-WebSocket-Accept computed from the client’s key and the protocol GUID. The research record locates this support at Section 4.2.2 (Sending the Server’s Opening Handshake), step 5. - Either endpoint may send data frames only after the opening handshake completes and before that endpoint sends a Close frame; client frames are masked and server frames are not. The research record locates this support at Section 5.1 (Overview). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 4.2.1 (Reading the Client’s Opening Handshake), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4.2.2 (Sending the Server’s Opening Handshake), step 5, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5.1 (Overview), which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate DNS, certificates, identity providers, time, content delivery, network paths, and application ownership before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from Section 4.2.1 (Reading the Client’s Opening Handshake); Section 4.2.2 (Sending the Server’s Opening Handshake), step 5; Section 5.1 (Overview) to the observed environment. Useful domain evidence includes request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 6455 — The WebSocket Protocol](https://www.rfc-editor.org/rfc/rfc6455.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6455 — The WebSocket Protocol - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6455.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Complete the WebSocket opening handshake before processing data frames,” DSE Security, https://update.dsesecurity.com/updates/complete-the-websocket-opening-handshake-before-processing-data-frames/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Complete the Work Folders relying-party configuration beyond the AD FS wizard > What remains to be reviewed after the Work Folders relying-party trust is created? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-072-complete-the-work-folders-relying-party-configuration-beyond-the-ad-fs-wizard/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:59+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What remains to be reviewed after the Work Folders relying-party trust is created? ## Potentially affected Use this review for the documented Work Folders federation workflow. ## DSE recommendation Prepare an object-level checklist separating the displayed trust name, service identifier, claim rules, and additional PowerShell settings. ## Article ## Source facts Microsoft requires a Work Folders relying-party trust for AD FS integration and permits creating it before Work Folders itself is configured. The documented Work Folders relying-party identifier is fixed by the service rather than being an arbitrary display name. The procedure also requires options configured through PowerShell that the wizard interface does not expose. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/work-folders/deploy-work-folders-adfs-step2). ## Applicability Use this review for the documented Work Folders federation workflow. Identify the actual relying-party object and the applicable server release. Review the complete source procedure before choosing its access and claim settings. ## DSE recommendation Prepare an object-level checklist separating the displayed trust name, service identifier, claim rules, and additional PowerShell settings. Have the federation owner review the intended access policy instead of copying lab permissions without a decision. Record which administrator completed each portion and preserve the previous trust configuration through the approved change process. ## Verification Inspect the resulting trust properties and compare them with the chosen procedure. Test an approved Work Folders authentication flow and retain the relevant failure or success context. Investigate a wizard-completion result that lacks the required additional settings. Close the configuration only after the federation and file-service owners accept the same tested object. ## Official references [Microsoft Learn: Deploy Work Folders with AD FS and Web Application Proxy – Step 2, AD FS Post-Configuration Work](https://learn.microsoft.com/en-us/windows-server/storage/work-folders/deploy-work-folders-adfs-step2). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy Work Folders with AD FS and Web Application Proxy - Step 2, AD FS Post-Configuration Work - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/work-folders/deploy-work-folders-adfs-step2 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Complete the Work Folders relying-party configuration beyond the AD FS wizard,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-072-complete-the-work-folders-relying-party-configuration-beyond-the-ad-fs-wizard/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Complete written NRC cyber-event follow-up after telephonic notification > Use 10 CFR 73.77 - Cyber security event notifications to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/complete-written-nrc-cyber-event-follow-up-after-telephonic-notification/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:36+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.77 - Cyber security event notifications to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.77 - Cyber security event notifications ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Complete written NRC cyber-event follow-up after telephonic notification. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.77 – Cyber security event notifications](https://www.ecfr.gov/current/title-10/section-73.77) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, if the licensee subsequently retracts a telephonic notification made under this section as not meeting the threshold of a reportable event after it has submitted a written security follow-up report required by this paragraph, then the licensee must submit a revised written security follow-up report in accordance with this paragraph. The research record locates this support at 10 CFR 73.77(d)(10) (eCFR anchor p-73.77(d)(10)). - Under 10 CFR 73, each licensee making an initial telephonic notification of security events to the NRC according to the provisions of paragraphs (a)(1), (a)(2)(i), and (a)(2)(ii) of this section must also submit a written security follow-up report to the NRC within 60 days of the telephonic notification in accordance with section 73.4. The research record locates this support at 10 CFR 73.77(d) (eCFR anchor p-73.77(d)). Keep the evidence boundary at these traced claims. They support a review of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish NRC regulation for covered licensees and event categories; classification, timing, protected details, parallel reporting, records, and current NRC guidance require qualified review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.77(d)(10) (eCFR anchor p-73.77(d)(10)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.77(d) (eCFR anchor p-73.77(d)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 10 CFR 73.77(d)(10) (eCFR anchor p-73.77(d)(10)); 10 CFR 73.77(d) (eCFR anchor p-73.77(d)). Favor asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [10 CFR 73.77 – Cyber security event notifications](https://www.ecfr.gov/current/title-10/section-73.77) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.77 - Cyber security event notifications - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.77 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Complete written NRC cyber-event follow-up after telephonic notification,” DSE Security, https://update.dsesecurity.com/updates/complete-written-nrc-cyber-event-follow-up-after-telephonic-notification/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Compute the TCP retransmission timeout from measured round-trip time > Use RFC 6298 — Computing TCP's Retransmission Timer to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/compute-the-tcp-retransmission-timeout-from-measured-round-trip-time/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:33+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6298 — Computing TCP's Retransmission Timer to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6298 — Computing TCP's Retransmission Timer ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Compute the TCP retransmission timeout from measured round-trip time. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6298 — Computing TCP’s Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Before measuring RTT, a TCP sender should use a one-second RTO; its first sample sets SRTT to the sample, RTTVAR to half the sample, and RTO to SRTT plus the larger of clock granularity or four times RTTVAR. The research record locates this support at Section 2 (The Basic Algorithm), rules 2.1 and 2.2. - Karn’s algorithm forbids RTT samples from retransmitted segments unless timestamps remove the ambiguity, and TCP must obtain at least one RTT sample per round trip when possible. The research record locates this support at Section 3 (Taking RTT Samples). - When the retransmission timer expires, TCP retransmits the earliest unacknowledged segment, doubles the RTO, and restarts the timer with that backed-off value. The research record locates this support at Section 5 (Managing the RTO Timer), rules 5.4-5.6. The source support ends with the statements listed above. Use them to examine address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 2 (The Basic Algorithm), rules 2.1 and 2.2, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Taking RTT Samples), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5 (Managing the RTO Timer), rules 5.4-5.6, which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Section 2 (The Basic Algorithm), rules 2.1 and 2.2; Section 3 (Taking RTT Samples); Section 5 (Managing the RTO Timer), rules 5.4-5.6 through configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 6298 — Computing TCP’s Retransmission Timer](https://www.rfc-editor.org/rfc/rfc6298.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6298 — Computing TCP's Retransmission Timer - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6298.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Compute the TCP retransmission timeout from measured round-trip time,” DSE Security, https://update.dsesecurity.com/updates/compute-the-tcp-retransmission-timeout-from-measured-round-trip-time/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Configure advanced Windows auditing before expecting identity detections > Use Configure Windows event auditing to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/configure-advanced-windows-auditing-before-identity-detections/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:23+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Configure Windows event auditing to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Configure Windows event auditing ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Configure advanced Windows auditing before expecting identity detections. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Configure Windows event auditing](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-windows-event-collection) from Microsoft supports the following bounded statements: - Defender for Identity sensors parse specific Windows event logs from domain controllers, AD FS, AD CS, and Microsoft Entra Connect servers, which must have the correct advanced audit policy settings. The research record locates this support at Opening overview. - Defender for Identity raises health alerts when it detects incorrect Windows event auditing configurations. The research record locates this support at Auditing configuration guidance. Only the traced statements above are asserted as source facts. Apply the review to Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health after confirming that the source and deployed context match. ## What the source does not establish Apply audit policy through controlled Group Policy testing; a configured setting does not prove events are generated, transported, or retained. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Auditing configuration guidance, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Auditing configuration guidance through sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Configure Windows event auditing](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-windows-event-collection) — Microsoft ## Primary reference - Name: Configure Windows event auditing - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-windows-event-collection - Source publication date: 2026-08-10 ## Citation and use Preferred citation: “Configure advanced Windows auditing before expecting identity detections,” DSE Security, https://update.dsesecurity.com/updates/configure-advanced-windows-auditing-before-identity-detections/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Configure gMSA Kerberos delegation without relying on the missing tab > Use Configuring Kerberos Delegation for Group Managed Service Accounts to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/configure-gmsa-kerberos-delegation-without-delegation-tab/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:37+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Configuring Kerberos Delegation for Group Managed Service Accounts to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Configuring Kerberos Delegation for Group Managed Service Accounts ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Configure gMSA Kerberos delegation without relying on the missing tab. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Configuring Kerberos Delegation for Group Managed Service Accounts](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/configure-kerberos-delegation-group-managed-service-accounts) from Microsoft supports the following bounded statements: - The ADUC Delegation tab does not appear for standalone or group managed service accounts. The research record locates this support at Opening overview. - Microsoft documents PowerShell and direct userAccountControl approaches for configuring the required delegation state. The research record locates this support at Sections: Use PowerShell commands; Manually update the userAccountControl value. Only the traced statements above are asserted as source facts. Apply the review to forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles after confirming that the source and deployed context match. ## What the source does not establish Use constrained delegation designs and verify SPNs before changing delegation attributes. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: Use PowerShell commands; Manually update the userAccountControl value, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and sanitize protected material before retention. ## Verification and evidence Keep the source locations Opening overview; Sections: Use PowerShell commands; Manually update the userAccountControl value adjacent to the sanitized artifacts used for comparison. Prefer directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Configuring Kerberos Delegation for Group Managed Service Accounts](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/configure-kerberos-delegation-group-managed-service-accounts) — Microsoft ## Primary reference - Name: Configuring Kerberos Delegation for Group Managed Service Accounts - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/configure-kerberos-delegation-group-managed-service-accounts - Source publication date: 2025-07-09 ## Citation and use Preferred citation: “Configure gMSA Kerberos delegation without relying on the missing tab,” DSE Security, https://update.dsesecurity.com/updates/configure-gmsa-kerberos-delegation-without-delegation-tab/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Confirm drive and vendor compatibility before a Windows firmware update > What should be established before using Windows to update drive firmware? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-030-confirm-drive-and-vendor-compatibility-before-a-windows-firmware-update/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:41+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What should be established before using Windows to update drive firmware? ## Potentially affected Use this review when preparing a drive firmware change. ## DSE recommendation Create a drive-specific plan naming the current firmware, proposed image, hardware identity, and vendor support reference. ## Article ## Source facts Windows-native firmware updating requires drives that implement the relevant supported commands; Microsoft describes hardware testing requirements for SAS, SATA, and NVMe devices. Microsoft recommends applying the firmware recommended by the hardware vendor or OEM before a server enters production. The documented ability to update a production drive without downtime is conditional on support for the Windows firmware-update mechanism. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/update-firmware). ## Applicability Use this review when preparing a drive firmware change. Identify the complete supported storage solution, not just a drive model. Review the vendor instructions and the source’s production-update precautions for the actual deployment. ## DSE recommendation Create a drive-specific plan naming the current firmware, proposed image, hardware identity, and vendor support reference. Have the storage owner approve the update sequence and workload acceptance test. Confirm the available recovery arrangements and monitoring coverage before execution. Pilot the approved image on an appropriate representative device and retain the original inventory for comparison. ## Verification After the approved update, query the actual firmware revision and compare it with the intended image. Examine storage and application health through the agreed workload test. Record any interruption observed instead of assuming none occurred. Preserve the result for each drive and pause the remaining sequence if the image or health evidence differs from the plan. ## Official references [Microsoft Learn: Updating drive firmware](https://learn.microsoft.com/en-us/windows-server/storage/update-firmware). Source reviewed September 8, 2026. ## Primary reference - Name: Updating drive firmware - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/update-firmware - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Confirm drive and vendor compatibility before a Windows firmware update,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-030-confirm-drive-and-vendor-compatibility-before-a-windows-firmware-update/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Confirm RDMA use before crediting a file transfer to SMB Direct > Which capability and SMB setting should be checked before testing SMB Direct performance? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-143-confirm-rdma-use-before-crediting-a-file-transfer-to-smb-direct/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:48+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which capability and SMB setting should be checked before testing SMB Direct performance? ## Potentially affected Administrators validating SMB Direct on RDMA-capable network paths. ## DSE recommendation Have the storage and network owners agree on the intended RDMA path and representative test file. ## Article ## Source facts SMB Direct uses network adapters with RDMA capabilities. SMB Multichannel discovers those capabilities and enables the Direct path. Without Multichannel, SMB uses the adapter’s ordinary TCP/IP path even if the hardware supports RDMA. Microsoft’s performance test begins by verifying RDMA support in PowerShell before measuring a large file transfer. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-direct). ## Applicability Identify both endpoints, their supported releases, adapter capabilities, drivers, network configuration, and SMB settings. Review the source requirements and any encryption-specific platform conditions before interpreting a throughput result. ## DSE recommendation Have the storage and network owners agree on the intended RDMA path and representative test file. Record the current Multichannel and adapter state before testing. Define which measurements will distinguish the intended transport from a successful transfer over a different path. ## Verification Inspect the active connection and adapter evidence during the controlled copy, then measure throughput and application behavior. Compare those observations with the approved RDMA design. Preserve a TCP-only result as a path-selection finding rather than reporting it as proof that SMB Direct is functioning. ## Official references [Microsoft Learn: Improve performance of a file server with SMB Direct](https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-direct). Source reviewed September 8, 2026. ## Primary reference - Name: Improve performance of a file server with SMB Direct - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-direct - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Confirm RDMA use before crediting a file transfer to SMB Direct,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-143-confirm-rdma-use-before-crediting-a-file-transfer-to-smb-direct/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Connect CyberArk Identity only with the required API roles and permissions > Use Connect CyberArk Identity to Microsoft Defender for Identity (Preview) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/connect-cyberark-identity-with-required-api-roles/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:19+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Connect CyberArk Identity to Microsoft Defender for Identity (Preview) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Connect CyberArk Identity to Microsoft Defender for Identity (Preview) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Connect CyberArk Identity only with the required API roles and permissions. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Connect CyberArk Identity to Microsoft Defender for Identity (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/connect-cyber-ark) from Microsoft supports the following bounded statements: - The connection uses connector APIs to provide Defender for Identity visibility into and control over CyberArk identities. The research record locates this support at Opening overview. - Microsoft requires the documented CyberArk role plus Microsoft Entra or Defender role-based access permissions before connection. The research record locates this support at Prerequisites section. Keep the evidence boundary at these traced claims. They support a review of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The connector is marked Preview; use least privilege, protect secrets, and validate API scope before production enablement. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Prerequisites section, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to Opening overview; Prerequisites section and to observable material such as integration configuration, connectivity tests, event timestamps, alert correlation, role assignments, and case records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Connect CyberArk Identity to Microsoft Defender for Identity (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/connect-cyber-ark) — Microsoft ## Primary reference - Name: Connect CyberArk Identity to Microsoft Defender for Identity (Preview) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/connect-cyber-ark - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Connect CyberArk Identity only with the required API roles and permissions,” DSE Security, https://update.dsesecurity.com/updates/connect-cyberark-identity-with-required-api-roles/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Connect each identity provider before relying on cloud-identity posture assessments > Use Microsoft Defender for Identity security assessments for cloud identities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/connect-each-provider-before-cloud-identity-posture-assessments/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:02+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Microsoft Defender for Identity security assessments for cloud identities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft Defender for Identity security assessments for cloud identities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Connect each identity provider before relying on cloud-identity posture assessments. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft Defender for Identity security assessments for cloud identities](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/cloud-identities) from Microsoft supports the following bounded statements: - Defender for Identity provides cloud-identity assessments for Okta, CyberArk Identity, and SailPoint Identity Security Cloud. The research record locates this support at Opening overview. - Microsoft requires the relevant provider instance to be connected in the Defender portal before its assessments are used. The research record locates this support at Opening prerequisite. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking only where the source and recorded environment align. ## What the source does not establish Provider connection does not establish complete account coverage, correct correlation, or safe remediation of every recommendation. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening prerequisite, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations Opening overview; Opening prerequisite adjacent to the sanitized artifacts used for comparison. Prefer affected-entity lists, directory attributes, relationship paths, assessment timestamps, remediation tests, and accepted exceptions, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Microsoft Defender for Identity security assessments for cloud identities](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/cloud-identities) — Microsoft ## Primary reference - Name: Microsoft Defender for Identity security assessments for cloud identities - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/cloud-identities - Source publication date: 2026-07-30 ## Citation and use Preferred citation: “Connect each identity provider before relying on cloud-identity posture assessments,” DSE Security, https://update.dsesecurity.com/updates/connect-each-provider-before-cloud-identity-posture-assessments/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Connect SailPoint with a dedicated API principal and least-required roles > Use Connect SailPoint Identity Security Cloud to Microsoft Defender for Identity (Preview) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/connect-sailpoint-with-dedicated-api-principal-and-least-roles/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:15+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Connect SailPoint Identity Security Cloud to Microsoft Defender for Identity (Preview) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Connect SailPoint Identity Security Cloud to Microsoft Defender for Identity (Preview) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Connect SailPoint with a dedicated API principal and least-required roles. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Connect SailPoint Identity Security Cloud to Microsoft Defender for Identity (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/connect-sail-point) from Microsoft supports the following bounded statements: - The Defender portal API connector gives security administrators visibility into SailPoint-managed identities, identity-related threats, and account activity. The research record locates this support at Opening overview. - The prerequisites require a SailPoint IdentityNow Admin role for application creation and documented Microsoft Entra or Defender permissions for setup. The research record locates this support at Prerequisites section. The source support ends with the statements listed above. Use them to examine identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The connector is marked Preview; store client secrets securely and review every granted API scope before production use. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Prerequisites section, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Prerequisites section. Favor integration configuration, connectivity tests, event timestamps, alert correlation, role assignments, and case records, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Connect SailPoint Identity Security Cloud to Microsoft Defender for Identity (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/connect-sail-point) — Microsoft ## Primary reference - Name: Connect SailPoint Identity Security Cloud to Microsoft Defender for Identity (Preview) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/connect-sail-point - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Connect SailPoint with a dedicated API principal and least-required roles,” DSE Security, https://update.dsesecurity.com/updates/connect-sailpoint-with-dedicated-api-principal-and-least-roles/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Connect standard state mitigation plans to funding and risk-reduction decisions > Use 44 CFR 201.4 - Standard State Mitigation Plans to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/connect-standard-state-mitigation-plans-to-funding-and-risk-reduction-decisions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:26+00:00 - Modified: 2026-08-27T13:07:00+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 44 CFR 201.4 - Standard State Mitigation Plans to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 44 CFR 201.4 - Standard State Mitigation Plans ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Connect standard state mitigation plans to funding and risk-reduction decisions. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [44 CFR 201.4 – Standard State Mitigation Plans](https://www.ecfr.gov/current/title-44/section-201.4) from Federal Emergency Management Agency via eCFR supports the following bounded statements: - Under 44 CFR 201, the rule requires that states have an approved Standard State Mitigation Plans meeting the requirements of this section as a condition of receiving non-emergency Stafford Act assistance and FEMA mitigation grants. The research record locates this support at 44 CFR 201.4(a) (eCFR anchor p-201.4(a)). - Under 44 CFR 201, a section on the Coordination of Local Mitigation Planning that includes the following: a description of the State process to support, through funding and technical assistance, the development of local mitigation plans. The research record locates this support at 44 CFR 201.4(c)(4)(i), read with 44 CFR 201.4(c)(4) (eCFR anchor p-201.4(c)(4)(i)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives and the conditions the source actually describes. ## What the source does not establish Federal hazard-mitigation regulation for states and specified assistance; current program rules, FEMA guidance, plan status, hazards, approvals, and grant conditions require authoritative review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 44 CFR 201.4(a) (eCFR anchor p-201.4(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 44 CFR 201.4(c)(4)(i), read with 44 CFR 201.4(c)(4) (eCFR anchor p-201.4(c)(4)(i)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations 44 CFR 201.4(a) (eCFR anchor p-201.4(a)); 44 CFR 201.4(c)(4)(i), read with 44 CFR 201.4(c)(4) (eCFR anchor p-201.4(c)(4)(i)) adjacent to the sanitized artifacts used for comparison. Prefer business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [44 CFR 201.4 – Standard State Mitigation Plans](https://www.ecfr.gov/current/title-44/section-201.4) — Federal Emergency Management Agency via eCFR ## Primary reference - Name: 44 CFR 201.4 - Standard State Mitigation Plans - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-44/section-201.4 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Connect standard state mitigation plans to funding and risk-reduction decisions,” DSE Security, https://update.dsesecurity.com/updates/connect-standard-state-mitigation-plans-to-funding-and-risk-reduction-decisions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Connect workplace alarm technology to the emergency action plan > An alarm device is useful only when people can perceive it, distinguish its meaning, report the emergency, take the planned action, and account for others. Test the technology and the workplace plan as one operating sequence. - Canonical URL: https://update.dsesecurity.com/updates/connect-workplace-alarms-to-emergency-action-plan/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:31:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Access Control, Business Continuity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know An alarm device is useful only when people can perceive it, distinguish its meaning, report the emergency, take the planned action, and account for others. Test the technology and the workplace plan as one operating sequence. ## Potentially affected Employee alarm and mass-notification systems, public address, strobes and tactile devices, radios, phones, access control, visitor systems, emergency messaging, network and standby power, and evacuation procedures. ## DSE recommendation Map every planned emergency action to its signal, audience, reporting path, accessible notification, fallback, owner, training, test evidence, and restoration step, then exercise the sequence with authorized safety personnel. ## Article ## Source facts: the signal must support the planned action OSHA’s [29 CFR 1910.38](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.38) applies when another OSHA standard requires an emergency action plan. For a covered workplace, the rule identifies minimum elements including procedures for reporting a fire or other emergency, evacuation and exit-route assignments, critical operations before evacuation, accounting for employees, rescue or medical duties, and a contact for more information. It also addresses employee alarms, designated and trained evacuation assistance, and review of the plan when it is developed, responsibilities change, or the plan changes. The related [29 CFR 1910.165](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.165) says employee alarms covered by the rule must provide warning for the necessary emergency action, be perceivable above ambient noise or light in affected areas, and be distinctive and recognizable for evacuation or another action in the plan. It addresses emergency reporting, restoration, maintenance, testing, power, supervision, trained service personnel, and accessible manual actuation. Tactile devices may be used for employees who would not otherwise recognize an audible or visual alarm. Applicability and required details depend on the workplace and governing requirements. Safety, human-resources, facilities, accessibility, fire/life-safety, and legal personnel should confirm the current obligations and approved plan. This article is operational guidance, not a legal determination or substitute for an emergency professional. ## DSE recommendation: build a signal-to-action matrix List the emergencies addressed by the approved plan. For each one, record who may initiate a signal, the signal’s meaning, areas and people to be reached, action expected, reporting method, responsible coordinator, accounting method, responder handoff, alternate method during impairment, and return-to-normal authority. Keep fire/life-safety signals and functions under the direction of qualified personnel and the applicable authority. - Survey perception, not device presence. Test occupied workstations, production floors, restrooms, mechanical spaces, outdoor work areas, vehicles, noisy rooms, bright areas, remote buildings, and other relevant locations. Include employees who may not perceive the primary audible or visual method and use approved accommodations. - Make meanings unambiguous. Document every tone, voice message, strobe pattern, display, text, or other signal and the action it represents. Check for conflicts with fire alarm, intrusion, machinery, process, severe-weather, security, and routine paging signals. - Test reporting and escalation. Exercise the approved method for a worker to report an emergency and verify the destination, location information, priority handling, acknowledgement, and fallback. Do not expose personal contact details or sensitive response instructions more broadly than necessary. - Include people who are not in the employee directory. Define how visitors, contractors, temporary staff, guards, delivery personnel, and after-hours occupants receive instructions and are accounted for without assuming an access-control occupancy report is perfectly current. - Exercise technology dependencies. Test approved loss of normal power, network, cloud messaging, telephony, a paging zone, or a primary workstation. Verify the backup communication method and the people authorized to use it. - Prove restoration. After a drill, test, alarm, or maintenance period, reconcile devices and supervisory conditions, remove test modes, restore integrations, notify stakeholders, and document who confirmed normal operation. Coordinate every live test to avoid panic, injury, process disruption, or unintended responder dispatch. Announce drills and impairments according to the approved plan, establish stop conditions, and provide alternate protection where required. Technology personnel should not independently simulate fire or life-safety inputs without the authorized parties. Measure useful outcomes: areas reached, perception exceptions, message delivery time, reporting accuracy, participation, accounting gaps, failed devices or paths, restoration time, and corrective-action closure. Revisit the matrix after construction, staffing or shift changes, a plan revision, new alarm or collaboration technology, network redesign, an accessibility need, or an actual event. The goal is not merely that a horn sounded or a text was sent; it is that every affected person can recognize the warning and perform the safe, approved action. ## Official references - Occupational Safety and Health Administration, [29 CFR 1910.38, Emergency action plans](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.38); current text reviewed August 11, 2026. - Occupational Safety and Health Administration, [29 CFR 1910.165, Employee alarm systems](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.165); current text reviewed August 11, 2026. ## Primary reference - Name: Occupational Safety and Health Administration: 29 CFR 1910.38—Emergency action plans - Authority: Occupational Safety and Health Administration - URL: https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.38 - Source publication date: 2002-11-07 ## Citation and use Preferred citation: “Connect workplace alarm technology to the emergency action plan,” DSE Security, https://update.dsesecurity.com/updates/connect-workplace-alarms-to-emergency-action-plan/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Constrain ADUC user administration to the assigned operator role > Use Manage User Accounts with Active Directory Users and Computers in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/constrain-aduc-user-administration-to-operator-role/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:53+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Manage User Accounts with Active Directory Users and Computers in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Manage User Accounts with Active Directory Users and Computers in Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Constrain ADUC user administration to the assigned operator role. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Manage User Accounts with Active Directory Users and Computers in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage-user-accounts-in-windows-server) from Microsoft supports the following bounded statements: - ADUC can create, delete, and manage user accounts when its AD DS or AD LDS administration components are installed. The research record locates this support at Opening overview. - Account Operators can manage user accounts but do not receive the same group and permission authority as Domain Admins or Enterprise Admins. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Use delegated OU permissions where possible instead of relying on broad built-in administrative groups. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Manage User Accounts with Active Directory Users and Computers in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage-user-accounts-in-windows-server) — Microsoft ## Primary reference - Name: Manage User Accounts with Active Directory Users and Computers in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage-user-accounts-in-windows-server - Source publication date: 2025-06-30 ## Citation and use Preferred citation: “Constrain ADUC user administration to the assigned operator role,” DSE Security, https://update.dsesecurity.com/updates/constrain-aduc-user-administration-to-operator-role/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Constrain NDES certificate enrollment to approved network devices > Use What is Network Device Enrollment Service for Active Directory Certificate Services? to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/constrain-ndes-enrollment-to-approved-network-devices/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:11+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use What is Network Device Enrollment Service for Active Directory Certificate Services? to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of What is Network Device Enrollment Service for Active Directory Certificate Services? ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Constrain NDES certificate enrollment to approved network devices. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [What is Network Device Enrollment Service for Active Directory Certificate Services?](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/network-device-enrollment-service-overview) from Microsoft supports the following bounded statements: - NDES acts as an AD CS registration authority for devices that lack domain credentials. The research record locates this support at Opening overview. - It uses SCEP to support scalable certificate issuance to network devices in trusted closed networks. The research record locates this support at Opening overview. Only the traced statements above are asserted as source facts. Apply the review to certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles after confirming that the source and deployed context match. ## What the source does not establish SCEP/NDES authorization, challenge handling, templates, and device trust require separate threat modeling. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles are in and out of scope? - Which condition in Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations Opening overview; Opening overview adjacent to the sanitized artifacts used for comparison. Prefer CA and template exports, enrollment tests, certificate chains, access-control entries, event logs, and revocation-path checks, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [What is Network Device Enrollment Service for Active Directory Certificate Services?](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/network-device-enrollment-service-overview) — Microsoft ## Primary reference - Name: What is Network Device Enrollment Service for Active Directory Certificate Services? - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/network-device-enrollment-service-overview - Source publication date: 2025-01-03 ## Citation and use Preferred citation: “Constrain NDES certificate enrollment to approved network devices,” DSE Security, https://update.dsesecurity.com/updates/constrain-ndes-enrollment-to-approved-network-devices/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Constrain Sieve filters to explicit tests, bounded actions, and implicit keep > Use RFC 5228 — Sieve: An Email Filtering Language to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/constrain-sieve-filters-to-explicit-tests-bounded-actions-and-implicit-keep/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:06+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 5228 — Sieve: An Email Filtering Language to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 5228 — Sieve: An Email Filtering Language ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Constrain Sieve filters to explicit tests, bounded actions, and implicit keep. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 5228 — Sieve: An Email Filtering Language](https://www.rfc-editor.org/rfc/rfc5228.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Sieve tests are arguments to conditional commands and select which action block executes for a message. The research record locates this support at Section 2.5 (Tests). - The base language supports keep, fileinto, redirect, and discard, while implementations may bound action counts and restrict incompatible combinations. The research record locates this support at Sections 4 (Action Commands) and 2.10.4 (Limits on Numbers of Actions). - If no delivery action cancels it, Sieve performs an implicit keep; after a script error, processing stops and an implicit keep is also performed. The research record locates this support at Sections 2.10.2 (Implicit Keep) and 2.10.6 (Errors). Only the traced statements above are asserted as source facts. Apply the review to sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 2.5 (Tests), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 4 (Action Commands) and 2.10.4 (Limits on Numbers of Actions), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 2.10.2 (Implicit Keep) and 2.10.6 (Errors), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Section 2.5 (Tests); Sections 4 (Action Commands) and 2.10.4 (Limits on Numbers of Actions); Sections 2.10.2 (Implicit Keep) and 2.10.6 (Errors) to the observed environment. Useful domain evidence includes sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 5228 — Sieve: An Email Filtering Language](https://www.rfc-editor.org/rfc/rfc5228.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 5228 — Sieve: An Email Filtering Language - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5228.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Constrain Sieve filters to explicit tests, bounded actions, and implicit keep,” DSE Security, https://update.dsesecurity.com/updates/constrain-sieve-filters-to-explicit-tests-bounded-actions-and-implicit-keep/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Consult employees and provide access to Program 2 prevention information > Use 40 CFR 68.62 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/consult-employees-and-provide-access-to-program-2-prevention-information/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:02+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.62 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.62 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Consult employees and provide access to Program 2 prevention information. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.62 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.62) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the owner or operator provide to employees and their representatives access to hazard reviews and to all other information required to be developed under this subpart. The research record locates this support at 40 CFR 68.62(c) (eCFR anchor p-68.62(c)). - Under 40 CFR 68, the rule requires that an annual written or electronic notice be distributed to employees and their representatives indicating that the plan is readily available to view, and how to access the information. The research record locates this support at 40 CFR 68.62(a)(1) (eCFR anchor p-68.62(a)(1)). Only the traced statements above are asserted as source facts. Apply the review to critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths after confirming that the source and deployed context match. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.62(c) (eCFR anchor p-68.62(c)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.62(a)(1) (eCFR anchor p-68.62(a)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to 40 CFR 68.62(c) (eCFR anchor p-68.62(c)); 40 CFR 68.62(a)(1) (eCFR anchor p-68.62(a)(1)) and to observable material such as facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [40 CFR 68.62 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.62) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.62 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.62 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Consult employees and provide access to Program 2 prevention information,” DSE Security, https://update.dsesecurity.com/updates/consult-employees-and-provide-access-to-program-2-prevention-information/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Contain malformed BGP UPDATE attributes with the specified recovery action > Use RFC 7606 — Revised Error Handling for BGP UPDATE Messages to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/contain-malformed-bgp-update-attributes-with-the-specified-recovery-action/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:32+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 7606 — Revised Error Handling for BGP UPDATE Messages to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 7606 — Revised Error Handling for BGP UPDATE Messages ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Contain malformed BGP UPDATE attributes with the specified recovery action. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 7606 — Revised Error Handling for BGP UPDATE Messages](https://www.rfc-editor.org/rfc/rfc7606.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - The four ordered BGP UPDATE recovery actions are session reset, AFI/SAFI disable, treat-as-withdraw, and attribute discard; discard is restricted to attributes that cannot affect route selection or installation. The research record locates this support at Section 2 (Error-Handling Approaches). - Conflicting Optional or Transitive flags and missing well-known mandatory attributes use treat-as-withdraw, while malformed ATOMIC_AGGREGATE or AGGREGATOR cases specified here use attribute discard. The research record locates this support at Section 3 (Revision to BGP UPDATE Message Error Handling), items c, d, and f. - When one UPDATE has multiple attribute errors that prescribe different recoveries, the speaker must apply the strongest specified action. The research record locates this support at Section 3 (Revision to BGP UPDATE Message Error Handling), item h. The source support ends with the statements listed above. Use them to examine address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 2 (Error-Handling Approaches), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Revision to BGP UPDATE Message Error Handling), items c, d, and f, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 3 (Revision to BGP UPDATE Message Error Handling), item h, which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from Section 2 (Error-Handling Approaches); Section 3 (Revision to BGP UPDATE Message Error Handling), items c, d, and f; Section 3 (Revision to BGP UPDATE Message Error Handling), item h through configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 7606 — Revised Error Handling for BGP UPDATE Messages](https://www.rfc-editor.org/rfc/rfc7606.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 7606 — Revised Error Handling for BGP UPDATE Messages - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc7606.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Contain malformed BGP UPDATE attributes with the specified recovery action,” DSE Security, https://update.dsesecurity.com/updates/contain-malformed-bgp-update-attributes-with-the-specified-recovery-action/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control access to Safeguards Information through need-to-know and authorization > Use 10 CFR 73.21 - Protection of Safeguards Information: Performance requirements to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/control-access-to-safeguards-information-through-need-to-know-and-authorization/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:54+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.21 - Protection of Safeguards Information: Performance requirements to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.21 - Protection of Safeguards Information: Performance requirements ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Control access to Safeguards Information through need-to-know and authorization. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.21 – Protection of Safeguards Information: Performance requirements](https://www.ecfr.gov/current/title-10/section-73.21) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, covered persons must maintain an information-protection system incorporating section 73.23 safeguards for specified non-power reactors holding special nuclear material. The research record locates this support at 10 CFR 73.21(a)(1)(ii), read with 10 CFR 73.21(a)(1) (eCFR anchor p-73.21(a)(1)(ii)). - Under 10 CFR 73, Safeguards Information outside paragraphs (a)(1)(i) and (ii) must be protected under section 73.22. The research record locates this support at 10 CFR 73.21(a)(1)(iii), read with 10 CFR 73.21(a)(1) (eCFR anchor p-73.21(a)(1)(iii)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces and the conditions the source actually describes. ## What the source does not establish NRC regulation with defined information categories and covered persons; do not publish protected details, and obtain qualified review before operational use. A correct source interpretation can still be inapplicable to a particular design. Confirm identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 10 CFR 73.21(a)(1)(ii), read with 10 CFR 73.21(a)(1) (eCFR anchor p-73.21(a)(1)(ii)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.21(a)(1)(iii), read with 10 CFR 73.21(a)(1) (eCFR anchor p-73.21(a)(1)(iii)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from 10 CFR 73.21(a)(1)(ii), read with 10 CFR 73.21(a)(1) (eCFR anchor p-73.21(a)(1)(ii)); 10 CFR 73.21(a)(1)(iii), read with 10 CFR 73.21(a)(1) (eCFR anchor p-73.21(a)(1)(iii)) to the observed environment. Useful domain evidence includes approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [10 CFR 73.21 – Protection of Safeguards Information: Performance requirements](https://www.ecfr.gov/current/title-10/section-73.21) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.21 - Protection of Safeguards Information: Performance requirements - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.21 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Control access to Safeguards Information through need-to-know and authorization,” DSE Security, https://update.dsesecurity.com/updates/control-access-to-safeguards-information-through-need-to-know-and-authorization/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control and monitor entry into the airport air operations area > Use 49 CFR 1542.203 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/control-and-monitor-entry-into-the-airport-air-operations-area/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:33+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.203 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.203 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Control and monitor entry into the airport air operations area. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.203 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.203) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, the rule requires that each airport operator required to establish an AOA prevent and detect the unauthorized entry, presence, and movement of individuals and ground vehicles into or within the AOA by doing the following: provide security information as described in section 1542.213(c) to each individual with unescorted access to the AOA. The research record locates this support at 49 CFR 1542.203(b)(3), read with 49 CFR 1542.203(b) (eCFR anchor p-1542.203(b)(3)). - Under 49 CFR 1542, the rule requires that each airport operator required to establish an AOA prevent and detect the unauthorized entry, presence, and movement of individuals and ground vehicles into or within the AOA by doing the following: provide for detection of, and response to, each unauthorized presence or movement in, or attempted entry to, the AOA by an individual whose access is not authorized in accordance with its security program. The research record locates this support at 49 CFR 1542.203(b)(2), read with 49 CFR 1542.203(b) (eCFR anchor p-1542.203(b)(2)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces only where the source and recorded environment align. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 49 CFR 1542.203(b)(3), read with 49 CFR 1542.203(b) (eCFR anchor p-1542.203(b)(3)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.203(b)(2), read with 49 CFR 1542.203(b) (eCFR anchor p-1542.203(b)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from 49 CFR 1542.203(b)(3), read with 49 CFR 1542.203(b) (eCFR anchor p-1542.203(b)(3)); 49 CFR 1542.203(b)(2), read with 49 CFR 1542.203(b) (eCFR anchor p-1542.203(b)(2)) through approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [49 CFR 1542.203 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.203) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.203 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.203 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Control and monitor entry into the airport air operations area,” DSE Security, https://update.dsesecurity.com/updates/control-and-monitor-entry-into-the-airport-air-operations-area/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control compressed-gas acceptance, storage, and handling as one process > Use 29 CFR 1910.101 - Compressed gases to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/control-compressed-gas-acceptance-storage-and-handling-as-one-process/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:31+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.101 - Compressed gases to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.101 - Compressed gases ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Control compressed-gas acceptance, storage, and handling as one process. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.101 – Compressed gases](https://www.ecfr.gov/current/title-29/section-1910.101) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, the in-plant handling, storage, and utilization of all compressed gases in cylinders, portable tanks, rail tankcars, or motor vehicle cargo tanks must be in accordance with Compressed Gas Association Pamphlet P-1-1965, which is incorporated by reference as specified in section 1910.6. The research record locates this support at 29 CFR 1910.101(b) (eCFR anchor p-1910.101(b)). - Under 29 CFR 1910, the rule requires that each employer determine that compressed gas cylinders under his control are in a safe condition to the extent that this can be determined by visual inspection. The research record locates this support at 29 CFR 1910.101(a) (eCFR anchor p-1910.101(a)). Only the traced statements above are asserted as source facts. Apply the review to critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths after confirming that the source and deployed context match. ## What the source does not establish Federal workplace rule; gas-specific standards, fire code, cylinder supplier instructions, and current incorporated editions may add requirements. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.101(b) (eCFR anchor p-1910.101(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.101(a) (eCFR anchor p-1910.101(a)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from 29 CFR 1910.101(b) (eCFR anchor p-1910.101(b)); 29 CFR 1910.101(a) (eCFR anchor p-1910.101(a)) through facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [29 CFR 1910.101 – Compressed gases](https://www.ecfr.gov/current/title-29/section-1910.101) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.101 - Compressed gases - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.101 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Control compressed-gas acceptance, storage, and handling as one process,” DSE Security, https://update.dsesecurity.com/updates/control-compressed-gas-acceptance-storage-and-handling-as-one-process/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control controllers and servers through receiving and removal > NIST PE-16 addresses authorization and records for system components entering and leaving a facility. Extend PACS custody to delivery, staging, repair, return, and disposal. - Canonical URL: https://update.dsesecurity.com/updates/control-controllers-and-servers-through-receiving-and-removal/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:41+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Access Control, Cybersecurity - Reading time: 2 minutes ## What you need to know NIST PE-16 addresses authorization and records for system components entering and leaving a facility. Extend PACS custody to delivery, staging, repair, return, and disposal. ## Potentially affected Organizations receiving, staging, moving, repairing, returning, or disposing of PACS controllers, servers, enrollment devices, storage, and related components. ## DSE recommendation Require component identity, authorization, custody, inspection, configuration state, data handling, and destination records from receiving through final removal. ## Article Bottom line: a panel or server can bypass normal change control while it is on a loading dock, installer cart, repair bench, or outbound pallet. Physical custody should connect procurement and receiving to configuration, media protection, and final disposition. ## Source fact: NIST addresses authorization and records for component movement PE-16 in [NIST SP 800-53 Release 5.2.0](https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home?element=PE-16) calls for authorizing and controlling organization-defined types of system components entering and exiting the facility and maintaining records of those components. Its discussion says enforcing those authorizations may require restricting access to delivery areas and isolating those areas from the system and media libraries. For PACS, the component may contain configuration, credentials, certificates, logs, personal data, or an address that reveals architecture. A replacement can also introduce an unapproved firmware or supply-chain state before anyone enrolls it as an asset. ## Source boundary and applicability NIST SP 800-53 is a security and privacy control catalog. PE-16 becomes mandatory only through an applicable authorization, policy, contract, regulation, or tailored control baseline. It does not prescribe one receiving process, inspect a specific product, or replace media-sanitization, procurement, hazardous-material, shipping, or evidence rules. ## Applicability questions - Which PACS components contain configuration, keys, logs, identity data, or storage? - Who may authorize receipt, internal movement, repair shipment, return, and disposal? - Can deliveries reach operational networks or secure areas before inspection? - How are serial number, tamper state, firmware, accessories, and purchase source verified? - What sanitization, evidence hold, license release, or vendor attestation is required before exit? ## DSE recommendation: create an inbound and outbound custody gate The following steps are DSE recommendations based on the cited source. At receipt, match purchase order, supplier, model, serial number, packaging or tamper indicators, and destination. Hold components in a controlled staging area until inspection, asset registration, approved firmware and configuration, and network onboarding are complete. Record every person or service that takes custody. Before removal, identify the asset and owner, preserve required logs or evidence, revoke credentials and certificates, release licenses, sanitize storage by approved method, and record destination and carrier. For repair returns, define whether the vendor may access stored data or keys. Reconcile receiving, inventory, PACS configuration, and financial disposition so no item remains simultaneously active and recorded as removed. ## Verification and evidence Retain authorization, purchase and shipping records, serial-number and asset matches, inspection checklist, staging access log, baseline configuration, custody transfers, removal approval, sanitization evidence, certificate or credential revocation, carrier receipt, and inventory reconciliation. Protect detailed architecture and secret information from the general shipping record. ## Official references - [NIST SP 800-53 Release 5.2.0, PE-16 — Delivery and Removal](https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home?element=PE-16) – National Institute of Standards and Technology; released August 27, 2025 ## Primary reference - Name: NIST SP 800-53 Release 5.2.0, PE-16 — Delivery and Removal - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home?element=PE-16 - Source publication date: 2025-08-27 ## Citation and use Preferred citation: “Control controllers and servers through receiving and removal,” DSE Security, https://update.dsesecurity.com/updates/control-controllers-and-servers-through-receiving-and-removal/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control entry to regulated maritime facilities at every MARSEC level > Use 33 CFR 105.255 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/control-entry-to-regulated-maritime-facilities-at-every-marsec-level/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:10+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.255 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.255 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Control entry to regulated maritime facilities at every MARSEC level. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.255 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.255) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, a facility owner or operator must implement access-control measures that deter the unauthorized introduction of dangerous substances and devices, including devices intended to harm people, vessels, facilities, or ports. The research record locates this support at 33 CFR 105.255(a)(1), read with 33 CFR 105.255(a) (eCFR anchor p-105.255(a)(1)). - Under 33 CFR 105, MARSEC Level 1 measures must specify where access restrictions or prohibitions apply, including the points where TWIC access-control provisions will be used. The research record locates this support at 33 CFR 105.255(b)(1), read with 33 CFR 105.255(b) (eCFR anchor p-105.255(b)(1)). The source support ends with the statements listed above. Use them to examine credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.255(a)(1), read with 33 CFR 105.255(a) (eCFR anchor p-105.255(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.255(b)(1), read with 33 CFR 105.255(b) (eCFR anchor p-105.255(b)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from 33 CFR 105.255(a)(1), read with 33 CFR 105.255(a) (eCFR anchor p-105.255(a)(1)); 33 CFR 105.255(b)(1), read with 33 CFR 105.255(b) (eCFR anchor p-105.255(b)(1)) to the observed environment. Useful domain evidence includes approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [33 CFR 105.255 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.255) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.255 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.255 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Control entry to regulated maritime facilities at every MARSEC level,” DSE Security, https://update.dsesecurity.com/updates/control-entry-to-regulated-maritime-facilities-at-every-marsec-level/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control hot work from authorization through the final fire watch > Welding, cutting, brazing, grinding, and other spark- or heat-producing work need one controlled lifecycle: choose a safe location, remove or shield hazards, authorize the work, protect openings, watch for fire, and close the permit only after the area remains safe. - Canonical URL: https://update.dsesecurity.com/updates/control-hot-work-authorization-through-final-fire-watch/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:29:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know Welding, cutting, brazing, grinding, and other spark- or heat-producing work need one controlled lifecycle: choose a safe location, remove or shield hazards, authorize the work, protect openings, watch for fire, and close the permit only after the area remains safe. ## Potentially affected Maintenance shops, construction and renovation areas, roofs, concealed spaces, combustible construction, fire protection systems, contractors, permit issuers, fire watches, security patrols, alarms, extinguishers, ventilation, and shift handoffs. ## DSE recommendation Define hot work broadly, use designated areas when possible, require a qualified pre-work inspection and written authorization elsewhere, isolate combustibles and openings, provide fire protection and trained watch personnel, and document post-work release. ## Article ## Source facts: hot work requires area preparation and continuing fire prevention [OSHA 29 CFR 1910.252](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.252) establishes general fire-prevention requirements for welding, cutting, and brazing. Where practicable, objects to be worked on should be moved to a designated safe location. If they cannot be moved, movable fire hazards in the vicinity are to be taken to a safe place. When neither the work nor all hazards can be moved, guards must confine heat, sparks, and slag and protect immovable hazards. The standard addresses combustible floors, wall and floor openings, ducts and conveyor systems that could carry sparks, suitable fire-extinguishing equipment, and fire watchers. Fire watchers are required in specified circumstances, including where more than a minor fire might develop, and must have extinguishing equipment, know how to sound an alarm, watch all exposed areas, attempt extinguishment within equipment capacity, and otherwise sound the alarm. Authorization is required before cutting or welding outside a designated area. This federal general-industry rule is not the complete requirement for every workplace or process. Construction and shipyard rules, state plans, adopted fire code, NFPA 51B, permits, insurer conditions, hazardous-location requirements, ventilation and exposure controls, and the authority having jurisdiction may apply. Qualified safety and fire-protection personnel should define site procedures. ## DSE recommendation: manage the permit as a beginning-to-end control Define hot work by the hazard produced, not the contractor’s label. Include welding, torch cutting, brazing, soldering, grinding, thawing, heat guns, roofing torches, and other work capable of producing flame, heat, sparks, or hot slag. Publish which locations are permanent designated hot-work areas and what conditions keep that designation valid. - Screen the job early. Ask whether the work can be eliminated, performed cold, moved to a designated area, or completed offsite. Identify combustible construction, contents, residues, dust, flammable atmospheres, confined spaces, oxygen-enriched conditions, and surfaces that conduct heat to the opposite side. - Inspect before authorization. A trained permit authorizer should walk both sides and every level of the exposure. Check cracks, penetrations, drains, shafts, ceiling and floor voids, ducts, conveyors, wall cavities, roofs, and exterior drop zones. Confirm combustibles are removed or protected with approved methods and openings cannot transmit sparks. - Coordinate protection systems. Keep sprinklers, alarms, extinguishers, hose, and other required protection in service unless an approved impairment process establishes safeguards. Protect detection from contamination without disabling more coverage or time than authorized. Notify the monitoring point and restore every bypass promptly. - Assign a capable fire watch. State the watch area, duration, adjacent and concealed exposures, equipment, alarm method, stop-work authority, and handoff. The watch should not perform another task that prevents continuous observation and must understand the limits of incipient-fire response. - Control the active work. Display or retain the authorization at the job, keep leads and cylinders protected, maintain housekeeping, prevent public access, and stop when conditions change. A permit does not remain valid after a crew, location, process, atmosphere, or protective condition changes. - Close only after post-work surveillance. Begin the required watch period when hot work ends, not when setup begins. Recheck concealed and opposite-side spaces for heat, odor, smoke, discoloration, or smoldering. Record restoration of alarms, removal of shielding, final inspection, and release to the area owner. Contract language should identify who authorizes the work and who supplies the watch; it should never leave both parties assuming the other is responsible. Security and control-room personnel need the permit location, alarm status, watch contact, and escalation path, but should not approve technical conditions outside their competence. Audit permits against actual jobs, impairment records, alarm activations, and patrol observations. Investigate work found without authorization, repeated extensions, weak opposite-side checks, missing closeout, or a watch diverted to other duties. The goal is not a signed form—it is evidence that ignition paths were controlled until the area was demonstrably safe. ## Official references - Occupational Safety and Health Administration, [29 CFR 1910.252, General requirements for welding, cutting, and brazing](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.252). - OSHA, [Welding, Cutting, and Brazing Safety and Health Topics](https://www.osha.gov/welding-cutting-brazing). ## Primary reference - Name: OSHA 29 CFR 1910.252: General requirements for welding, cutting, and brazing - Authority: Occupational Safety and Health Administration - URL: https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.252 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Control hot work from authorization through the final fire watch,” DSE Security, https://update.dsesecurity.com/updates/control-hot-work-authorization-through-final-fire-watch/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control mechanical override keys as privileged credentials > A mechanical key can bypass identity, schedules, revocation, alarms, and audit trails. Govern high-impact keys with named ownership, least privilege, controlled issue, inventory, return, loss response, and periodic proof of custody. - Canonical URL: https://update.dsesecurity.com/updates/control-mechanical-override-keys-as-privileged-credentials/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:08:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 4 minutes ## What you need to know A mechanical key can bypass identity, schedules, revocation, alarms, and audit trails. Govern high-impact keys with named ownership, least privilege, controlled issue, inventory, return, loss response, and periodic proof of custody. ## Potentially affected Master, grand-master, control, emergency, override, elevator, gate, cabinet, equipment, and restricted keys; key cabinets and lockers; cylinders and cores; locksmith records; contractors; responders; PACS exceptions; and incident procedures. ## DSE recommendation Map each key to the openings and consequences it controls, tier it by impact, minimize copies and master scope, issue to accountable people for defined need and duration, verify custody, integrate loss and offboarding response, and rekey when residual risk is unacceptable. ## Article ## Source facts: physical access controls require assessable authorization and enforcement CISA’s [Catalog of Recommendations](https://www.cisa.gov/sites/default/files/documents/CatalogofRecommendationsVer7.pdf) includes physical-access control recommendations to secure keys, combinations, and other physical access devices; inventory those devices periodically; and change keys when they are lost or when holders transfer or terminate. It identifies keys, locks, combinations, and card readers as physical access devices. [NIST SP 800-53 Revision 5.1](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), control PE-3, independently addresses securing physical access devices, inventorying selected devices at an organization-defined frequency, and changing combinations or keys when they are lost, compromised, or held by people who transfer or terminate. The General Services Administration’s [Physical Access Control Systems in GSA-Controlled Space directive](https://www.gsa.gov/directives-library/physical-access-control-systems-in-us-general-services-administration-controlled-space) establishes governance for PACS in its scope, including coordinated responsibility and an agency approach. Electronic access policy does not make a building’s mechanical locks, override cylinders, cabinets, or emergency keys disappear. The CISA control-system catalog is used here as a reference model, not as a universal private-sector requirement, and the GSA directive governs only its stated federal scope. These sources do not set a private company’s legal key-control requirements or prescribe its key hierarchy. Treating a high-impact key as a privileged credential is a DSE governance analogy: both confer authority, require a lifecycle, and can create serious residual access when copied, lost, or not returned. Fire service and emergency keys may be subject to code or authority requirements that take precedence. ## DSE recommendation: govern reach, custody, and residual access Build a controlled key register from locksmith and field verification, not from an inherited spreadsheet alone. For every serialized key or controlled set, identify keyway and mark, openings or key levels reached, cylinder or core population, owner, custodian, approved holders, authorized purpose, issue and return dates, copy restrictions, storage, last verification, and response plan if missing. - Tier by consequence. Distinguish a single office key from a master that opens perimeter, server, monitoring, medication, evidence, cash, roof, elevator, or life-safety spaces. Apply stronger approval, storage, two-person handling, and verification to broader or more sensitive reach. - Reduce master scope. Issue the narrowest key that supports the work. Use time-limited checkout for infrequent tasks and avoid permanent contractor masters when supervised or site-specific access works. Do not stamp a key with an address or meaningful room name that helps a finder. - Control production. Limit ordering, cutting, pinning, duplication, and record access to authorized roles and qualified providers. Reconcile blank stock and issued keys. A “do not duplicate” marking is an instruction, not proof that copying is technically impossible. - Prove custody. Store reserves and returned keys in an appropriately controlled cabinet or safe. Review high-impact keys more often, require the holder to present the item, and investigate missing signatures, unexplained transfers, damaged seals, or a key that cannot be produced. - Join the lifecycle. Make key return part of transfer, leave, contract end, and emergency-access review. Human resources or vendor closure should not be considered complete until both electronic and mechanical access are resolved. Preserve lawful responder access. - Plan for loss. Define immediate reporting, affected-opening analysis, compensating patrol or guard, electronic-event review, stakeholder notice, cylinder or core replacement decision, and documentation. Recovering a key later does not prove it was never copied. Reconcile mechanical exceptions with PACS designs. If a door is electronically monitored but routinely opened by an untracked key, the operator may receive only a forced-door alarm—or no useful identity at all. Decide whether a monitored key switch, credentialed process, cabinet checkout, or procedural control is appropriate without obstructing required emergency use. Audit the system by sampling from both directions: select keys and verify every opening they reach; select high-risk openings and identify every key level that reaches them. Protect the resulting map as sensitive security information. Completion means unsupported keys were returned or risk-treated and the organization understands the access that remains—not merely that holders signed a form. ## Official references - Cybersecurity and Infrastructure Security Agency, [Catalog of Recommendations](https://www.cisa.gov/sites/default/files/documents/CatalogofRecommendationsVer7.pdf), Physical Access Control. - National Institute of Standards and Technology, [SP 800-53 Revision 5.1: Security and Privacy Controls for Information Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final), PE-3. - U.S. General Services Administration, [Physical Access Control Systems in GSA-Controlled Space](https://www.gsa.gov/directives-library/physical-access-control-systems-in-us-general-services-administration-controlled-space). ## Primary reference - Name: CISA Catalog of Recommendations: Physical Access Control - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/documents/CatalogofRecommendationsVer7.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Control mechanical override keys as privileged credentials,” DSE Security, https://update.dsesecurity.com/updates/control-mechanical-override-keys-as-privileged-credentials/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control physical access credentials from issue through revocation > A physical credential remains trustworthy only when identity verification, approval, issuance, access changes, loss response, periodic review, and revocation operate as one controlled lifecycle. - Canonical URL: https://update.dsesecurity.com/updates/physical-access-credential-lifecycle-badges-cards-mobile/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-28T14:22:00+00:00 - Modified: 2026-07-28T14:22:00+00:00 - Last reviewed by DSE: 2026-07-28 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control - Reading time: 3 minutes ## What you need to know A physical credential remains trustworthy only when identity verification, approval, issuance, access changes, loss response, periodic review, and revocation operate as one controlled lifecycle. ## Potentially affected Organizations that issue employee, contractor, visitor, temporary, card, fob, smart-card, emergency, test, or mobile credentials through a physical access control system. ## DSE recommendation Map the credential lifecycle to named owners and measurable time limits, then reconcile people, credentials, access levels, lifecycle events, and physical inventory with defensible evidence. ## Article ## Source fact: authorization and credentials require continuing control NIST [SP 800-53 Rev. 5 Update 1](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) provides a catalog of security and privacy controls that organizations tailor to their risks. Physical and Environmental Protection control PE-2 addresses authorizing physical access, maintaining an authorized-access list, issuing credentials, reviewing access, and removing people from the list when access is no longer required. PE-3 addresses enforcing physical access and maintaining relevant access records. The publication is mandatory in specified federal contexts, but it is not automatically a compliance requirement for every private organization. The underlying principle applies broadly: a card’s technology cannot compensate for stale authorization. One person may hold several legitimate credentials, including a mobile instance, but each credential must remain traceable to a verified identity, sponsor, status, access approval, issue event, and expiration or review rule. ## Separate lifecycle responsibilities The authoritative personnel or contractor owner confirms relationship status. A manager sponsors business need. The protected-area owner approves sensitive-space access. The credential administrator encodes, issues, suspends, replaces, and revokes credentials. Physical security defines policy, reconciles records, monitors exceptions, and tests performance. Avoid requester self-approval and shared badge-holder records. Before issue, authenticate the request and recipient, check for duplicate or active credentials, approve the least access needed, and document special doors, schedules, anti-passback exceptions, and expiration. Record the unique credential identifier, technology, issuer, recipient, activation, sponsor, and acknowledgement. Test an intended door and a representative denial without recording reusable credential secrets in the ticket. ## DSE recommendation: make changes event-driven - Connect joiner, mover, leave, contract-end, and termination events to the credential process with defined completion targets and acknowledgements. - On a role or location change, remove access tied only to the prior assignment. Require fresh approval for restricted areas instead of copying the old profile wholesale. - On reported loss, authenticate the reporter, disable the affected credential promptly, review relevant activity, issue a different identifier, and document investigation or notification decisions. - At departure, coordinate timing with the authorized personnel process, revoke every card, fob, mobile instance, and associated permission, recover property, and verify completion. Property return does not replace electronic revocation. - Review active credentials against authoritative people, sponsor, access-level, expiration, inventory, and activity records. Include contractors, visitors, emergency badges, guard credentials, test cards, and dormant mobile instances. - Control blank stock, returned cards, printers, keys, mobile licenses, and destruction. Prevent a returned or replaced identifier from silently remaining active. Measure median and maximum revocation time, credentials without current sponsors, overdue temporary access, dormant active credentials, lost-credential replacements, inventory differences, and unresolved privileged access. Set review frequency by risk: a data center, cash room, laboratory, executive area, or round-the-clock entrance may justify more frequent review than a public lobby. Every exception should have a reason, accountable owner, expiration, and closure evidence. ## Primary reference - Name: NIST SP 800-53 Rev. 5 Update 1: Security and Privacy Controls - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final - Source publication date: 2020-09-23 ## Citation and use Preferred citation: “Control physical access credentials from issue through revocation,” DSE Security, https://update.dsesecurity.com/updates/physical-access-credential-lifecycle-badges-cards-mobile/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control the extension feed used by Windows Admin Center > How should Windows Admin Center extensions be distributed to connected and isolated gateways? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-193-control-the-extension-feed-used-by-windows-admin-center/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:58+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know How should Windows Admin Center extensions be distributed to connected and isolated gateways? ## Potentially affected Administrators installing or updating Windows Admin Center extensions. ## DSE recommendation Maintain an approved package list with version, publisher, purpose, and operational owner. ## Article ## Source facts Windows Admin Center tools and connection types are extensions that can be installed, removed, and updated individually. The platform can use multiple NuGet V2 feeds or file shares, while its default feed contains packages from Microsoft and other developers. For a computer without feed access, Microsoft documents downloading extension packages and supplying them through a local drive or file share. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/configure/using-extensions). ## Applicability Identify the gateway, its internet or proxy access, the required extension, and the package publisher. Review the configured feeds before assuming every available package is supplied by Microsoft. Keep extension lifecycle decisions separate from upgrading the gateway installation. ## DSE recommendation Maintain an approved package list with version, publisher, purpose, and operational owner. Choose a controlled feed or distribution share appropriate to the gateway connectivity. Have a reviewer verify the package source before promotion to an isolated environment. Record the installed version and an agreed way to remove or replace the extension if it fails the pilot. ## Verification Install the selected extension on a representative gateway and open the intended tool against a test connection. Compare the installed version with the approved package and verify that the gateway can retrieve updates through the intended feed. Record unexpected publishers, duplicate sources, or unavailable dependencies before wider distribution. ## Official references [Microsoft Learn: Install and Manage Extensions](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/configure/using-extensions). Source reviewed September 8, 2026. ## Primary reference - Name: Install and Manage Extensions - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/configure/using-extensions - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Control the extension feed used by Windows Admin Center,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-193-control-the-extension-feed-used-by-windows-admin-center/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control vessel stores and bunkers from arrival through delivery > Use 33 CFR 105.270 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/control-vessel-stores-and-bunkers-from-arrival-through-delivery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:06+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.270 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.270 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Control vessel stores and bunkers from arrival through delivery. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.270 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.270) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, MARSEC Level 1 measures must require advance notice of vessel-stores or bunker deliveries, including a stores list, driver information, and vehicle-registration information. The research record locates this support at 33 CFR 105.270(b)(2), read with 33 CFR 105.270(b) (eCFR anchor p-105.270(b)(2)). - Under 33 CFR 105, facilities serving vessels routinely must establish standing arrangements with the vessel and its suppliers for delivery notice, timing, and documentation. The research record locates this support at 33 CFR 105.270(a)(4), read with 33 CFR 105.270(a) (eCFR anchor p-105.270(a)(4)). The source support ends with the statements listed above. Use them to examine access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.270(b)(2), read with 33 CFR 105.270(b) (eCFR anchor p-105.270(b)(2)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.270(a)(4), read with 33 CFR 105.270(a) (eCFR anchor p-105.270(a)(4)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from 33 CFR 105.270(b)(2), read with 33 CFR 105.270(b) (eCFR anchor p-105.270(b)(2)); 33 CFR 105.270(a)(4), read with 33 CFR 105.270(a) (eCFR anchor p-105.270(a)(4)) to the observed environment. Useful domain evidence includes asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [33 CFR 105.270 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.270) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.270 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.270 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Control vessel stores and bunkers from arrival through delivery,” DSE Security, https://update.dsesecurity.com/updates/control-vessel-stores-and-bunkers-from-arrival-through-delivery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control when a System Insights capability runs > How should capability enablement and prediction scheduling be changed in System Insights? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-033-control-when-a-system-insights-capability-runs/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:38+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should capability enablement and prediction scheduling be changed in System Insights? ## Potentially affected Use this review when configuring an existing System Insights capability. ## DSE recommendation Have the server owner choose the desired run window and explain any decision to disable the capability. ## Article ## Source facts Disabling a System Insights capability prevents invocation; for nondefault capabilities it also stops their data collection. Invoking a capability runs it immediately, and Microsoft suggests scheduling predictions outside business hours to avoid conflict with critical operations. The documented PowerShell interface supports a separate custom schedule for each capability. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/manage/system-insights/managing-capabilities). ## Applicability Use this review when configuring an existing System Insights capability. Identify whether it is a default or added capability, its present state, its schedule, and the business operation that should not be disturbed. ## DSE recommendation Have the server owner choose the desired run window and explain any decision to disable the capability. Record the difference between an immediate test run and an ongoing schedule change. Consider the data-collection consequence for a nondefault capability before disabling it. Preserve the original state and schedule so the agreed configuration can be restored if needed. ## Verification Inspect the capability state and schedule after the approved change. Observe a scheduled execution at the intended time and record its completion result. Check that an immediate invocation was not mistaken for proof of the recurring schedule. Retain the configuration with the owner’s review date and investigate unexpected runs before changing additional capabilities. ## Official references [Microsoft Learn: Manage System Insights capabilities in Windows Admin Center](https://learn.microsoft.com/en-us/windows-server/manage/system-insights/managing-capabilities). Source reviewed September 8, 2026. ## Primary reference - Name: Manage System Insights capabilities in Windows Admin Center - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/system-insights/managing-capabilities - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Control when a System Insights capability runs,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-033-control-when-a-system-insights-capability-runs/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Control Windows dynamic DNS registration, ownership, and name-conflict handling > Use Dynamic DNS Update in Windows and Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/control-windows-dynamic-dns-registration-ownership-and-name-conflict-handling/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:34+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Dynamic DNS Update in Windows and Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Dynamic DNS Update in Windows and Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Control Windows dynamic DNS registration, ownership, and name-conflict handling. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Dynamic DNS Update in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic-update) from Microsoft supports the following bounded statements: - Windows clients and servers can dynamically register and update their DNS names. The research record locates this support at Article introduction. - The Windows implementation includes secure dynamic update behavior and name-conflict handling. The research record locates this support at Resolving name conflicts; Secure dynamic update; How secure dynamic update works. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish The page describes Windows behavior; it does not authorize insecure updates or define the correct update ownership model for every DHCP and Active Directory design. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Article introduction, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Resolving name conflicts; Secure dynamic update; How secure dynamic update works, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from Article introduction; Resolving name conflicts; Secure dynamic update; How secure dynamic update works to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Dynamic DNS Update in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic-update) — Microsoft ## Primary reference - Name: Dynamic DNS Update in Windows and Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/dynamic-update - Source publication date: 2025-03-24 ## Citation and use Preferred citation: “Control Windows dynamic DNS registration, ownership, and name-conflict handling,” DSE Security, https://update.dsesecurity.com/updates/control-windows-dynamic-dns-registration-ownership-and-name-conflict-handling/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # ConvertTo-DnsServerSecondaryZone: convertto dns server secondary zone with before-and-after evidence > Use ConvertTo-DnsServerSecondaryZone to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/convertto-dnsserversecondaryzone-convertto-dns-server-secondary-zone-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:07+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use ConvertTo-DnsServerSecondaryZone to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of ConvertTo-DnsServerSecondaryZone ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: ConvertTo-DnsServerSecondaryZone: convertto dns server secondary zone with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [ConvertTo-DnsServerSecondaryZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/convertto-dnsserversecondaryzone?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Converts a primary zone or stub zone to a secondary zone.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The ConvertTo-DnsServerSecondaryZone cmdlet converts primary zone or a stub zone on a Domain Name System (DNS) server to a secondary zone.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from SYNOPSIS; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-259 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [ConvertTo-DnsServerSecondaryZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/convertto-dnsserversecondaryzone?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: ConvertTo-DnsServerSecondaryZone - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/convertto-dnsserversecondaryzone?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “ConvertTo-DnsServerSecondaryZone: convertto dns server secondary zone with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/convertto-dnsserversecondaryzone-convertto-dns-server-secondary-zone-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Coordinate airport incident management with TSA and affected operators > Use 49 CFR 1542.307 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/coordinate-airport-incident-management-with-tsa-and-affected-operators/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:22+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.307 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.307 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Coordinate airport incident management with TSA and affected operators. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.307 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.307) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, the rule requires that airport operators required to have a security program under section 1542.103(c) but not subject to 14 CFR part 139, develop emergency response procedures to incidents of threats identified in paragraph (a) of this section. The research record locates this support at 49 CFR 1542.307(c) (eCFR anchor p-1542.307(c)). - Under 49 CFR 1542, immediately upon direct or referred receipt of a threat of any of the incidents described in paragraph (a) of this section, each airport operator must immediately notify TSA of acts, or suspected acts, of unlawful interference to civil aviation operations, including specific bomb threats to aircraft and airport facilities. The research record locates this support at 49 CFR 1542.307(b)(3), read with 49 CFR 1542.307(b) (eCFR anchor p-1542.307(b)(3)). Keep the evidence boundary at these traced claims. They support a review of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 49 CFR 1542.307(c) (eCFR anchor p-1542.307(c)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.307(b)(3), read with 49 CFR 1542.307(b) (eCFR anchor p-1542.307(b)(3)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 49 CFR 1542.307(c) (eCFR anchor p-1542.307(c)); 49 CFR 1542.307(b)(3), read with 49 CFR 1542.307(b) (eCFR anchor p-1542.307(b)(3)). Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [49 CFR 1542.307 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.307) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.307 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.307 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Coordinate airport incident management with TSA and affected operators,” DSE Security, https://update.dsesecurity.com/updates/coordinate-airport-incident-management-with-tsa-and-affected-operators/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Coordinate emergency-response capabilities annually with local responders > Use 40 CFR 68.93 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/coordinate-emergency-response-capabilities-annually-with-local-responders/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:48+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.93 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.93 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Coordinate emergency-response capabilities annually with local responders. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.93 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.93) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that coordination occur at least annually, and more frequently if necessary, to address changes: At the stationary source; in the stationary source’s emergency response and/or emergency action plan; and/or in the community emergency response plan. The research record locates this support at 40 CFR 68.93(a) (eCFR anchor p-68.93(a)). - Under 40 CFR 68, the rule requires that coordination include providing to the local emergency planning and response organizations: The stationary source’s emergency response plan if one exists; emergency action plan; updated emergency contact information; and other information necessary for developing and implementing the local emergency response plan. The research record locates this support at 40 CFR 68.93(b) (eCFR anchor p-68.93(b)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives and the conditions the source actually describes. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.93(a) (eCFR anchor p-68.93(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.93(b) (eCFR anchor p-68.93(b)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence Keep the source locations 40 CFR 68.93(a) (eCFR anchor p-68.93(a)); 40 CFR 68.93(b) (eCFR anchor p-68.93(b)) adjacent to the sanitized artifacts used for comparison. Prefer business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [40 CFR 68.93 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.93) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.93 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.93 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Coordinate emergency-response capabilities annually with local responders,” DSE Security, https://update.dsesecurity.com/updates/coordinate-emergency-response-capabilities-annually-with-local-responders/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Coordinate hospice emergency plans across home and inpatient care > Use 42 CFR 418.113 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/coordinate-hospice-emergency-plans-across-home-and-inpatient-care/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:08+00:00 - Modified: 2026-08-27T13:06:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 418.113 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 418.113 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Coordinate hospice emergency plans across home and inpatient care. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 418.113 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-418.113) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 418, the rule requires that the plan do the following: address patient population, including, but not limited to, the type of services the hospice has the ability to provide in an emergency; and continuity of operations, including delegations of authority and succession plans. The research record locates this support at 42 CFR 418.113(a)(3), read with 42 CFR 418.113(a) (eCFR anchor p-418.113(a)(3)). - Under 42 CFR 418, the rule requires that the hospice develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 418.113(d) (eCFR anchor p-418.113(d)). Only the traced statements above are asserted as source facts. Apply the review to essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives after confirming that the source and deployed context match. ## What the source does not establish Hospice-specific federal condition of participation; home, inpatient, contracted, patient, caregiver, state, and survey requirements must be reconciled. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 418.113(a)(3), read with 42 CFR 418.113(a) (eCFR anchor p-418.113(a)(3)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 418.113(d) (eCFR anchor p-418.113(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from 42 CFR 418.113(a)(3), read with 42 CFR 418.113(a) (eCFR anchor p-418.113(a)(3)); 42 CFR 418.113(d) (eCFR anchor p-418.113(d)) through business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [42 CFR 418.113 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-418.113) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 418.113 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-418.113 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Coordinate hospice emergency plans across home and inpatient care,” DSE Security, https://update.dsesecurity.com/updates/coordinate-hospice-emergency-plans-across-home-and-inpatient-care/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Coordinate MARSEC level changes and implement the approved measures on time > Use 33 CFR 105.230 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/coordinate-marsec-level-changes-and-implement-the-approved-measures-on-time/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:16+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.230 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.230 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Coordinate MARSEC level changes and implement the approved measures on time. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.230 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.230) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, at MARSEC Level 3, in addition to the requirements in this part, a facility owner or operator may be required to implement additional measures, pursuant to 33 CFR part 6, 160, or 165, as appropriate, which may include but are not limited to use of armed security personnel to control access to the facility and to deter, to the maximum extent practical, a transportation security incident. The research record locates this support at 33 CFR 105.230(e)(2), read with 33 CFR 105.230(e) (eCFR anchor p-105.230(e)(2)). - Under 33 CFR 105, at MARSEC Level 3, in addition to the requirements in this part, a facility owner or operator may be required to implement additional measures, pursuant to 33 CFR part 6, 160, or 165, as appropriate, which may include but are not limited to use of waterborne security patrol. The research record locates this support at 33 CFR 105.230(e)(1), read with 33 CFR 105.230(e) (eCFR anchor p-105.230(e)(1)). Only the traced statements above are asserted as source facts. Apply the review to essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives after confirming that the source and deployed context match. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.230(e)(2), read with 33 CFR 105.230(e) (eCFR anchor p-105.230(e)(2)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.230(e)(1), read with 33 CFR 105.230(e) (eCFR anchor p-105.230(e)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to 33 CFR 105.230(e)(2), read with 33 CFR 105.230(e) (eCFR anchor p-105.230(e)(2)); 33 CFR 105.230(e)(1), read with 33 CFR 105.230(e) (eCFR anchor p-105.230(e)(1)) and to observable material such as business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [33 CFR 105.230 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.230) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.230 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.230 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Coordinate MARSEC level changes and implement the approved measures on time,” DSE Security, https://update.dsesecurity.com/updates/coordinate-marsec-level-changes-and-implement-the-approved-measures-on-time/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Coordinate physical protection for irradiated reactor fuel in transit > Use 10 CFR 73.37 - Irradiated reactor fuel in transit to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/coordinate-physical-protection-for-irradiated-reactor-fuel-in-transit/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:50+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.37 - Irradiated reactor fuel in transit to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.37 - Irradiated reactor fuel in transit ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Coordinate physical protection for irradiated reactor fuel in transit. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.37 – Irradiated reactor fuel in transit](https://www.ecfr.gov/current/title-10/section-73.37) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, a licensee must protect spent-fuel transit Safeguards Information under sections 73.21 and 73.22, including information about defensive tactics and capabilities. The research record locates this support at 10 CFR 73.37(b)(1)(viii)(H), read with 10 CFR 73.37(b)(1)(viii)|73.37(b)(1) (eCFR anchor p-73.37(b)(1)(viii)(H)). - Under 10 CFR 73, a movement control center must be continuously staffed by someone authorized to monitor the shipment and coordinate physical-protection activities. The research record locates this support at 10 CFR 73.37(b)(3)(ii) (eCFR anchor p-73.37(b)(3)(ii)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths only where the source and recorded environment align. ## What the source does not establish NRC regulation for covered shipments; security plans, routes, schedules, escorts, communications, and response details can be sensitive and require authorized review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.37(b)(1)(viii)(H), read with 10 CFR 73.37(b)(1)(viii)|73.37(b)(1) (eCFR anchor p-73.37(b)(1)(viii)(H)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.37(b)(3)(ii) (eCFR anchor p-73.37(b)(3)(ii)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from 10 CFR 73.37(b)(1)(viii)(H), read with 10 CFR 73.37(b)(1)(viii)|73.37(b)(1) (eCFR anchor p-73.37(b)(1)(viii)(H)); 10 CFR 73.37(b)(3)(ii) (eCFR anchor p-73.37(b)(3)(ii)) through asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [10 CFR 73.37 – Irradiated reactor fuel in transit](https://www.ecfr.gov/current/title-10/section-73.37) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.37 - Irradiated reactor fuel in transit - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.37 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Coordinate physical protection for irradiated reactor fuel in transit,” DSE Security, https://update.dsesecurity.com/updates/coordinate-physical-protection-for-irradiated-reactor-fuel-in-transit/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Correct RMP accident and emergency-contact data on the rule's clocks > Use 40 CFR 68.195 - Required corrections to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/correct-rmp-accident-and-emergency-contact-data-on-the-rule-s-clocks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:52+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.195 - Required corrections to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.195 - Required corrections ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Correct RMP accident and emergency-contact data on the rule’s clocks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.195 – Required corrections](https://www.ecfr.gov/current/title-40/section-68.195) from Environmental Protection Agency via eCFR supports the following bounded statements: - After a qualifying accidental release, an owner or operator must submit the specified new accident-history data within six months or by the next required RMP update, whichever comes first. The research record locates this support at 40 CFR 68.195(a) (eCFR anchor p-68.195(a)). - An owner or operator must correct required emergency-contact information within one month after it changes. The research record locates this support at 40 CFR 68.195(b) (eCFR anchor p-68.195(b)). The source support ends with the statements listed above. Use them to examine essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This applies only after an RMP has been submitted and only to corrections required by 40 CFR 68.195. It does not replace the full RMP update schedule or incident-investigation duties. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.195(a) (eCFR anchor p-68.195(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.195(b) (eCFR anchor p-68.195(b)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from 40 CFR 68.195(a) (eCFR anchor p-68.195(a)); 40 CFR 68.195(b) (eCFR anchor p-68.195(b)) to the observed environment. Useful domain evidence includes business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [40 CFR 68.195 – Required corrections](https://www.ecfr.gov/current/title-40/section-68.195) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.195 - Required corrections - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.195 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Correct RMP accident and emergency-contact data on the rule's clocks,” DSE Security, https://update.dsesecurity.com/updates/correct-rmp-accident-and-emergency-contact-data-on-the-rule-s-clocks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Correlate CyberArk-managed accounts with AD and Entra identities > Use How Microsoft Defender for Identity protects your CyberArk identity accounts (Preview) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/correlate-cyberark-managed-accounts-with-ad-and-entra-identities/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:20+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use How Microsoft Defender for Identity protects your CyberArk identity accounts (Preview) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of How Microsoft Defender for Identity protects your CyberArk identity accounts (Preview) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Correlate CyberArk-managed accounts with AD and Entra identities. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [How Microsoft Defender for Identity protects your CyberArk identity accounts (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/defender-for-identity-cyber-ark-overview) from Microsoft supports the following bounded statements: - After connection, CyberArk identity data is added to the identity inventory and correlated with on-premises Active Directory and Microsoft Entra identities. The research record locates this support at Opening integration overview. - Active Directory accounts managed as CyberArk PAM accounts are tagged in the inventory, subject to the documented Windows Domain Account platform condition. The research record locates this support at Capabilities table. Keep the evidence boundary at these traced claims. They support a review of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The integration is marked Preview and does not prove every privileged account is discovered, correctly correlated, or safely remediated. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening integration overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Capabilities table, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to Opening integration overview; Capabilities table and to observable material such as integration configuration, connectivity tests, event timestamps, alert correlation, role assignments, and case records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [How Microsoft Defender for Identity protects your CyberArk identity accounts (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/defender-for-identity-cyber-ark-overview) — Microsoft ## Primary reference - Name: How Microsoft Defender for Identity protects your CyberArk identity accounts (Preview) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/defender-for-identity-cyber-ark-overview - Source publication date: 2026-02-15 ## Citation and use Preferred citation: “Correlate CyberArk-managed accounts with AD and Entra identities,” DSE Security, https://update.dsesecurity.com/updates/correlate-cyberark-managed-accounts-with-ad-and-entra-identities/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Correlate Okta activity with Active Directory and Entra identity context > Use How Microsoft Defender for Identity protects your Okta accounts to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/correlate-okta-activity-with-ad-and-entra-context/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:18+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use How Microsoft Defender for Identity protects your Okta accounts to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of How Microsoft Defender for Identity protects your Okta accounts ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Correlate Okta activity with Active Directory and Entra identity context. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [How Microsoft Defender for Identity protects your Okta accounts](https://learn.microsoft.com/en-us/defender-for-identity/okta-defender-for-identity-overview) from Microsoft supports the following bounded statements: - Defender for Identity ingests Okta user and activity data and correlates it with identity data from Active Directory and Microsoft Entra ID. The research record locates this support at Opening integration overview. - The integration provides a centralized view of user activity, posture risks, and suspicious behavior and supports remediation actions. The research record locates this support at Opening integration overview. Keep the evidence boundary at these traced claims. They support a review of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Correlation quality depends on identifiers and connector state; a unified view does not establish causation or complete Okta logging. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening integration overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening integration overview, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to Opening integration overview; Opening integration overview and to observable material such as integration configuration, connectivity tests, event timestamps, alert correlation, role assignments, and case records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [How Microsoft Defender for Identity protects your Okta accounts](https://learn.microsoft.com/en-us/defender-for-identity/okta-defender-for-identity-overview) — Microsoft ## Primary reference - Name: How Microsoft Defender for Identity protects your Okta accounts - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/okta-defender-for-identity-overview - Source publication date: 2025-08-07 ## Citation and use Preferred citation: “Correlate Okta activity with Active Directory and Entra identity context,” DSE Security, https://update.dsesecurity.com/updates/correlate-okta-activity-with-ad-and-entra-context/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Create a cluster volume from an approved specification > Which provisioning inputs should be checked when creating a new cluster volume in Windows Admin Center? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-028-create-a-cluster-volume-from-an-approved-specification/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:43+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know Which provisioning inputs should be checked when creating a new cluster volume in Windows Admin Center? ## Potentially affected Use this Windows Admin Center review for an eligible multi-node cluster after its new volume design is approved. ## DSE recommendation Have a second administrator compare the proposed creation inputs with the design record before execution. ## Article ## Source facts Microsoft documents cluster-volume creation through Windows Admin Center and PowerShell. A single-node cluster requires the PowerShell creation path. For a mirrored volume in Windows Admin Center, the administrator supplies a name, chooses two-way or three-way resiliency according to server count, and sets the capacity. Optional selections include deduplication, integrity checksums, and encryption. The resulting volume can be opened from the cluster’s volume inventory. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/create-volumes). ## Applicability Use this Windows Admin Center review for an eligible multi-node cluster after its new volume design is approved. Identify the cluster, name, usable size, selected resiliency, and optional features. Keep those approved values separate from examples in the interface walkthrough. ## DSE recommendation Have a second administrator compare the proposed creation inputs with the design record before execution. Assign an owner to each optional feature and confirm that its prerequisites have been reviewed. Record the intended workload and access path. Avoid selecting extra options simply because they appear in the creation pane, and preserve the completed provisioning record for later capacity work. ## Verification Inspect the new volume in inventory and compare its name, size, resiliency, and feature state with the approved specification. Perform a controlled file-access test through the intended path. Record any difference before placing application data on it. Keep future resizing and geometry changes in separate approved records tied to this original volume identity. ## Official references [Microsoft Learn: Create volumes on Azure Local and Windows Server clusters](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/create-volumes). Source reviewed September 8, 2026. ## Primary reference - Name: Create volumes on Azure Local and Windows Server clusters - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/create-volumes - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Create a cluster volume from an approved specification,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-028-create-a-cluster-volume-from-an-approved-specification/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Create a vulnerability-disclosure channel that researchers can actually use > A vulnerability-disclosure program needs clear scope, monitored intake, acknowledgement, secure tracking, technical ownership, coordinated remediation, communication, and measurable closure. - Canonical URL: https://update.dsesecurity.com/updates/vulnerability-disclosure-report-handling/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:10+00:00 - Modified: 2026-07-19T21:27:10+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 2 minutes ## What you need to know A vulnerability-disclosure program needs clear scope, monitored intake, acknowledgement, secure tracking, technical ownership, coordinated remediation, communication, and measurable closure. ## Potentially affected Organizations that develop, operate, host, or control public-facing software, hardware, connected products, websites, APIs, mobile applications, or digital services; purchasers only when contracts assign them disclosure handling. ## DSE recommendation Publish a reviewable reporting path, route submissions to trained owners, protect evidence and reporters, coordinate validation and remediation, and measure the handling lifecycle. ## Article Publishing a security email address is not enough if reports enter an ordinary support queue, lose attachments, expose a researcher, or close without reaching someone who owns the affected technology. Vulnerability disclosure requires an end-to-end handling process. ## What NIST recommends Source fact: NIST SP 800-216 explains that receiving reports about suspected security vulnerabilities is an important way for developers and service providers to learn about issues. Formal processes to accept, assess, and manage those reports can help reduce known vulnerabilities. Source fact: The publication provides recommendations for a federal vulnerability-disclosure framework, handling vulnerability reports, and communicating mitigation or remediation. It calls for a framework that supports local resolution with federal oversight and applies to software, hardware, and digital services under federal control. ## Design the reporting and handling path together DSE recommendation: obtain qualified legal review and define the systems in scope, accepted testing, prohibited activity, information requested, secure submission options, expected acknowledgement, communication approach, and public reporting channel. Do not promise authorization, safe harbor, payment, confidentiality, or a remediation deadline unless the organization has approved the exact language and can support it. - Route submissions to a monitored queue with primary and backup owners; test that spam filtering, attachment controls, and staff absence do not discard reports. - Acknowledge receipt and assign a tracking record without confirming a vulnerability before technical review. - Protect reporter identity, system details, exploit evidence, credentials, personal information, and communications according to need and obligation. - Triage scope, reproducibility, affected products and versions, exposure, impact, existing exploitation evidence, dependencies, and required coordination. - Assign technical and business owners for mitigation, remediation, validation, release, customer support, and communication. - Coordinate status updates, disclosure timing, closure, and retained evidence with the reporter and relevant stakeholders. ## Make the program observable DSE recommendation: measure acknowledgement time, time to technical ownership, validated and rejected reports, remediation status, reopened findings, overdue communication, and recurring root causes. Review whether product design, development, testing, deployment, update, or support processes should change. A fast closure count is not success if valid reports are dismissed or reporters stop communicating. ## Applicability and limits SP 800-216 is explicitly federal guidance. A private organization may adapt the lifecycle, but needs current legal advice for authorization boundaries, computer-access laws, safe-harbor language, privacy, records, export or sanctions issues, disclosure timing, and bounty terms. A vulnerability-disclosure policy is not automatically a paid bug-bounty program, and a report is not proof until it is evaluated. ## Official reference [NIST SP 800-216](https://csrc.nist.gov/pubs/sp/800/216/final) — federal vulnerability-disclosure framework and report-handling recommendations. ## Primary reference - Name: NIST SP 800-216: Recommendations for Federal Vulnerability Disclosure Guidelines - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/216/final - Source publication date: 2023-05-24 ## Citation and use Preferred citation: “Create a vulnerability-disclosure channel that researchers can actually use,” DSE Security, https://update.dsesecurity.com/updates/vulnerability-disclosure-report-handling/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Create an enterprise log-management policy before choosing a SIEM > NIST’s durable log-management structure starts with policy, organization-wide responsibility, infrastructure, operating processes, and supported staff—not a particular analytics product. - Canonical URL: https://update.dsesecurity.com/updates/enterprise-log-management-policy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:26:27+00:00 - Modified: 2026-07-19T21:26:27+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Information - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know NIST’s durable log-management structure starts with policy, organization-wide responsibility, infrastructure, operating processes, and supported staff—not a particular analytics product. ## Potentially affected Security, IT, application, records, privacy, compliance, and business teams responsible for creating, transporting, storing, reviewing, retaining, or disposing of log data. ## DSE recommendation Assign responsibilities, define requirements by system class, establish secure lifecycle processes, prioritize review, support operators, and audit whether logs remain complete and usable. ## Article A security information and event management platform cannot decide which records the organization needs, who is permitted to access them, how long they remain useful, or what happens when collection fails. Those are governance and operating decisions. ## NIST’s program-level foundation Source fact: NIST SP 800-92 provides high-level guidance for developing, implementing, and maintaining effective log-management practices across an enterprise. It addresses policy and procedures, log-management infrastructure, organization-wide processes, and support for personnel with log responsibilities. Source fact: The publication discusses the lifecycle of generating, transmitting, storing, accessing, analyzing, and disposing of log data. NIST notes that logs support security-incident identification and investigation, operational problem solving, and retention needs. It explicitly does not provide step-by-step instructions for a particular logging technology. ## Write requirements that systems can implement DSE recommendation: define requirements by system and data class. A policy should state: - the security, operational, legal, contractual, and records purposes for collection; - minimum event types and context, time synchronization, and expected source reliability; - approved collection paths, protection in transit and storage, and recovery expectations; - roles allowed to configure, access, analyze, export, preserve, and dispose of records; - retention and disposal authority, including preservation when an incident or legal hold applies; - monitoring for collection failure, capacity exhaustion, time drift, and unauthorized change. DSE recommendation: assign executive, security, operations, application, privacy, and records responsibilities without assuming one team can own every decision. Standardize common requirements, but document justified differences for specialized, cloud, mobile, legacy, or operational systems. ## Operate and audit the lifecycle Prioritize sources and review frequency according to risk and available capacity. Give responsible staff procedures, training, tools, escalation paths, and protected time to perform the work. Periodically test whether required events are generated, transported, searchable, time-aligned, access-controlled, retained, recoverable, and disposed of as approved. Measure missing sources and unusable events, not only storage volume. ## Applicability and limits SP 800-92 was published in 2006, and its technology examples and legal references are old. As of this review, NIST SP 800-92 Rev. 1 remains an initial public draft, not a final controlling publication. Use the 2006 final for durable program structure and current CISA event-logging guidance for modern operational emphasis. Current law, contracts, privacy obligations, and platform documentation must determine implementation and retention. ## Official reference [NIST SP 800-92](https://csrc.nist.gov/pubs/sp/800/92/final) — final NIST guidance on enterprise computer-security log management. ## Primary reference - Name: NIST SP 800-92: Guide to Computer Security Log Management - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/92/final - Source publication date: 2006-09-13 ## Citation and use Preferred citation: “Create an enterprise log-management policy before choosing a SIEM,” DSE Security, https://update.dsesecurity.com/updates/enterprise-log-management-policy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Create custom account-correlation rules only when strong identifiers are unavailable > Use Manage account correlation rules in Microsoft Defender for Identity (Preview) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/create-account-correlation-rules-only-without-strong-identifiers/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:42+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Manage account correlation rules in Microsoft Defender for Identity (Preview) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Manage account correlation rules in Microsoft Defender for Identity (Preview) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Create custom account-correlation rules only when strong identifiers are unavailable. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Manage account correlation rules in Microsoft Defender for Identity (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/custom-account-correlation-rules) from Microsoft supports the following bounded statements: - Custom correlation rules target accounts that do not share strong identifiers such as account ID, SID, object ID, or UPN. The research record locates this support at Opening overview. - Microsoft describes the rules as especially useful for privileged accounts with unique naming conventions and documents creating, editing, and removing them in the Defender portal. The research record locates this support at Opening overview and scope. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions and the conditions the source actually describes. ## What the source does not establish The feature is marked Preview; a naming rule is an inference and must not override contradictory authoritative identity evidence. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview and scope, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Opening overview; Opening overview and scope to the observed environment. Useful domain evidence includes sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Manage account correlation rules in Microsoft Defender for Identity (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/custom-account-correlation-rules) — Microsoft ## Primary reference - Name: Manage account correlation rules in Microsoft Defender for Identity (Preview) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/custom-account-correlation-rules - Source publication date: 2026-07-23 ## Citation and use Preferred citation: “Create custom account-correlation rules only when strong identifiers are unavailable,” DSE Security, https://update.dsesecurity.com/updates/create-account-correlation-rules-only-without-strong-identifiers/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # CVE-2026-68820 Is Actively Exploited: Verify the August Windows Fix > Microsoft reports active exploitation of CVE-2026-68820, a Windows privilege-escalation flaw that can grant SYSTEM access. Inventory affected systems, deploy the applicable August update, and verify the result with evidence. - Canonical URL: https://update.dsesecurity.com/updates/cve-2026-68820-actively-exploited-windows-fix-verification/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-12T12:59:39+00:00 - Modified: 2026-08-12T12:59:39+00:00 - Last reviewed by DSE: 2026-08-12 - Resource type: Briefing - DSE priority: Important - Topics: Cybersecurity, IT - Reading time: 5 minutes ## What you need to know Microsoft reports active exploitation of CVE-2026-68820, a Windows privilege-escalation flaw that can grant SYSTEM access. Inventory affected systems, deploy the applicable August update, and verify the result with evidence. ## Potentially affected Supported Windows 10 and Windows 11 endpoints and Windows Server 2012 through 2025 systems listed in Microsoft’s affected-product matrix, especially administrative workstations, shared servers, high-value systems, and devices missing from normal management or compliance reporting. ## DSE recommendation Review Microsoft’s live affected-product matrix, map each owned Windows system to the applicable August 2026 update, prioritize high-value assets, test and deploy through controlled rings, account for required restarts, verify installation and post-update health, and assign an owner and expiration date to every exception. ## Article Bottom line: Microsoft says CVE-2026-68820 is being exploited. The flaw is not a remote, unauthenticated entry point, but it can allow an attacker who already has low-privilege local access to gain SYSTEM privileges. Organizations should identify affected Windows systems, deploy the applicable August 2026 security update, and verify that remediation reached the full asset population. ## Source fact: what Microsoft confirmed On August 11, 2026, Microsoft published its [August 2026 security release](https://msrc.microsoft.com/update-guide/releaseNote/2026-Aug). Microsoft identifies [CVE-2026-68820](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-68820) as an Important elevation-of-privilege vulnerability in the Windows Ancillary Function Driver for WinSock, commonly called AFD. The weakness is a use-after-free condition, classified as CWE-416. Microsoft’s advisory says an attacker must already be locally authenticated, run a specially crafted application, and win a race condition. No user interaction is required. Successful exploitation can grant SYSTEM privileges. Microsoft marked the vulnerability as not publicly disclosed at publication and as actively exploited, with “Exploitation Detected” for the latest software release. This distinction matters. CVE-2026-68820 should not be described as a one-click remote takeover. It is a post-compromise privilege-escalation path: after obtaining a foothold, an attacker could use it to strengthen control of a Windows system and potentially defeat protections that depend on lower privilege. ## CISA raised the priority CISA added CVE-2026-68820 to its [Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-68820) on August 11, 2026. The catalog lists August 25, 2026 as the remediation due date for in-scope federal civilian agencies and instructs organizations to apply vendor guidance. That federal deadline is not a universal private-sector legal mandate, but the exploitation evidence is useful prioritization input for every organization operating affected Windows systems. CISA currently lists known ransomware-campaign use as unknown. Microsoft and CISA do not identify an attacker, industry, campaign size, or remote exploitation path in the cited notices, so response plans should stay grounded in confirmed facts rather than speculation. ## Affected Windows environments Microsoft’s live product matrix includes supported editions of Windows 10 and Windows 11 and Windows Server releases from 2012 through 2025, including listed Server Core and applicable hotpatch configurations. The correct package depends on the exact operating-system edition, version, architecture, and servicing channel. Administrators should use Microsoft’s current matrix to select the applicable cumulative update or monthly rollup. Microsoft’s August records indicate that the listed remediations require a restart. Avoid relying on a copied build-number list after publication because Microsoft can revise servicing guidance and support pages. ## DSE recommendation: move from alert to verified closure The following is DSE guidance for operating the response; it is not a Microsoft-mandated private-sector schedule. - Establish the denominator. Export the owned Windows client and server population from authoritative inventory and management systems. Include offline, stale, unmanaged, and non-reporting devices instead of treating missing telemetry as proof of safety. - Confirm applicability. Match each system’s edition, version, architecture, and servicing state to Microsoft’s live affected-product and update information. Separate unsupported systems and machines that cannot accept the current cumulative update. - Prioritize business exposure. Move administrative workstations, shared servers, identity-adjacent systems, high-value applications, and assets that could support broader movement to the front of the queue. Active exploitation and SYSTEM impact deserve more weight than the Important label alone. - Test representative workflows. Pilot the correct package on systems that represent line-of-business applications, networking, security agents, authentication, backup, and physical-security integrations. Confirm that the system restarts cleanly and critical services return to a healthy state. - Deploy in controlled waves. Use defined rings and maintenance windows. Communicate expected restarts, preserve rollback and recovery options, and investigate failed or stalled deployments before expanding further. - Verify independently. Do not close the issue because a deployment job was launched or reported “complete.” Confirm the applicable update is installed, the device is online and healthy, required services are functioning, and compliance covers the original asset denominator. - Govern exceptions. Every deferred system needs a reason, accountable owner, compensating control, review date, and expiration. Unsupported Windows systems need an isolation, upgrade, replacement, or retirement plan. ## Evidence to retain Keep the inventory snapshot used for scoping, applicable-product decision, deployment timestamps, installed-update evidence, restart state, post-update health checks, failures, exception approvals, and the final coverage report. Preserve the Microsoft and CISA source URLs and the date they were reviewed because vendor guidance can change. For endpoint and security teams, review telemetry for suspicious local privilege-escalation behavior on affected systems, especially where patching was delayed or the device was previously outside management. Patching reduces the vulnerability; it does not determine whether exploitation occurred before remediation. ## Five questions leaders should ask - Can we identify every affected Windows system, including the ones not currently reporting? - Which high-value systems remain unverified, and who owns them? - What evidence distinguishes “deployment attempted” from “risk closed”? - How old is the longest exception, and when does it expire? - Did we test the business service after the restart, not only the device? ## The larger lesson After years working across endpoints, servers, networks, cloud platforms, and security operations, I have learned that installing an update is usually the easy part. Knowing what is affected, deciding what moves first, and proving the fix reached every system is where mature organizations separate themselves. CVE-2026-68820 is one Windows vulnerability, but the operating lesson is broader: inventory, ownership, testing, verification, and exception control turn patching from a monthly task into a dependable business capability. If your organization cannot prove which high-priority systems remain exposed, DSE can help assess asset coverage, deployment controls, verification evidence, and exception governance, then build a practical remediation plan around the business. ## Official sources - [Microsoft Security Response Center: CVE-2026-68820](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-68820) - [Microsoft Security Response Center: August 2026 Security Updates](https://msrc.microsoft.com/update-guide/releaseNote/2026-Aug) - [Microsoft Security Response Center: August 2026 CVRF data](https://api.msrc.microsoft.com/cvrf/v3.0/cvrf/2026-Aug) - [CISA: Known Exploited Vulnerabilities Catalog entry](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-68820) - [CISA: BOD 26-04, Prioritizing Security Updates Based on Risk](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk) ## Related DSE guidance - [Treat enterprise patching as preventive maintenance, not an emergency ritual](https://update.dsesecurity.com/updates/enterprise-patch-management-preventive-maintenance/) - [Why CISA Known Exploited Vulnerabilities should change patch priority](https://update.dsesecurity.com/updates/cisa-known-exploited-vulnerabilities-patch-priority/) - [Windows deployment rings: move updates from pilot to broad release with evidence](https://update.dsesecurity.com/updates/windows-update-deployment-rings-evidence-based-rollout/) ## Primary reference - Name: Microsoft Security Response Center: CVE-2026-68820 - Authority: msrc.microsoft.com - URL: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-68820 - Source publication date: 2026-08-11 ## Citation and use Preferred citation: “CVE-2026-68820 Is Actively Exploited: Verify the August Windows Fix,” DSE Security, https://update.dsesecurity.com/updates/cve-2026-68820-actively-exploited-windows-fix-verification/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # CVE-2026-70329 in Outlook: What the 8.8 RCE Means and How to Respond > Microsoft has fixed CVE-2026-70329, an Outlook integer-overflow vulnerability rated CVSS 8.8. Exploitation requires a user to open a malicious Office file. Review the exact affected editions, deploy the August 11 security release, and verify the installed build by servicing channel. - Canonical URL: https://update.dsesecurity.com/updates/cve-2026-70329-microsoft-outlook-rce-patch-guidance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-12T15:47:15+00:00 - Modified: 2026-08-12T15:47:15+00:00 - Last reviewed by DSE: 2026-08-12 - Resource type: Briefing - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 5 minutes ## What you need to know Microsoft has fixed CVE-2026-70329, an Outlook integer-overflow vulnerability rated CVSS 8.8. Exploitation requires a user to open a malicious Office file. Review the exact affected editions, deploy the August 11 security release, and verify the installed build by servicing channel. ## Potentially affected Microsoft 365 Apps for Enterprise, Office 2019, Office LTSC 2021, Office LTSC 2024, and Outlook 2016 on Windows, in the 32-bit and 64-bit editions listed by Microsoft. ## DSE recommendation Inventory Office product, architecture, channel, and build; deploy the August 11, 2026 security update or later; install KB5002755 on MSI-based Outlook 2016; and verify the resulting build on every managed endpoint. ## Article ## The bottom line Microsoft released security updates on August 11, 2026 for CVE-2026-70329, a remote code execution vulnerability in Microsoft Office Outlook caused by an integer overflow or wraparound. Microsoft rates the issue Important and assigns it a CVSS v3.1 base score of 8.8 (High). This is not a zero-click vulnerability based on the information Microsoft has published. An attacker must send a malicious Office file and convince the recipient to open it. That required interaction lowers the likelihood of automatic exploitation, but the potential consequences remain serious: the published CVSS assessment assigns high confidentiality, integrity, and availability impact. DSE recommendation: identify affected Windows Office installations, deploy the appropriate August 11 Office security release or later, and verify the resulting build on each managed update channel. Do not treat email filtering or user awareness as a replacement for the security update. ## What Microsoft has confirmed - Vulnerability: CVE-2026-70329, Microsoft Outlook Remote Code Execution Vulnerability. - Weakness: CWE-190, Integer Overflow or Wraparound. - Severity: Important under Microsoft’s rating system; CVSS v3.1 8.8 (High). - Published vector: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. - Required user action: the recipient must open a malicious Office file supplied by the attacker. - Customer action: required. Microsoft has released fixes and does not list a separate workaround. The CVSS vector indicates no attacker privileges are required, attack complexity is low, and user interaction is required. Microsoft has not publicly identified the exact file format or parser involved, the code-execution context, or preview-pane exploitation. Claims beyond the published attack path would therefore be speculation. ## Affected products Microsoft’s affected-product data names the following Windows products in both 32-bit and 64-bit editions: - Microsoft 365 Apps for Enterprise - Microsoft Office 2019 - Microsoft Office LTSC 2021 - Microsoft Office LTSC 2024 - Microsoft Outlook 2016 The advisory does not list new Outlook, Outlook on the web, Outlook for Mac, Outlook mobile, Microsoft 365 Apps for Business, or Office 2021/2024 retail as affected products. That omission should not be reversed into a broader claim: scope decisions should follow Microsoft’s current affected-product table and the actual product installed. ## Fixed builds published for August 11 For Click-to-Run and volume-licensed Office deployments, administrators should use Microsoft’s Office security-release table to match the installed servicing channel to the correct secured build. The fixed builds published on August 11, 2026 include: Office channel or productSecurity build Microsoft 365 Current ChannelVersion 2607, build 20228.20190 Monthly Enterprise Channel2607 / 20228.20188; 2606 / 20131.20206; 2605 / 20026.20266 Semi-Annual Enterprise Channel receiving Monthly Enterprise builds2607 / 20228.20186 Semi-Annual Enterprise Channel2508 / 19127.20730 Office LTSC 2024 Volume Licensed2408 / 17932.20910 Office LTSC 2021 Volume Licensed2108 / 14334.20848 Office 2019 Volume Licensed1808 / 10417.20197 Outlook 2016 MSIKB5002755; fixed build 16.0.5565.1000 Microsoft says the Click-to-Run security updates do not require a restart. The Outlook 2016 MSI update may require one. [KB5002755](https://support.microsoft.com/kb/5002755) applies to the MSI-based edition of Outlook 2016, not the Click-to-Run edition. Office 2019 and Outlook 2016 reached end of support on October 14, 2025. Microsoft nevertheless published the relevant August 2026 fixes. Organizations still operating these versions should install the released security update and maintain a supported-version migration plan; the availability of this update does not restore full product support. ## How the attack path changes the response The confirmed attack path begins with a malicious Office file delivered to a user and succeeds only if the user opens it. That makes email, collaboration platforms, downloads, and other file-delivery paths relevant control points, but it does not make patching optional. Until every affected installation is updated, DSE recommends treating unexpected Office attachments and links to Office documents as untrusted, maintaining attachment scanning and endpoint detection controls, and prioritizing users who routinely process external documents. These are DSE operational precautions derived from the published attack path; Microsoft has not published them as a formal workaround. ## A practical patch-and-verify plan - Inventory the actual Office estate. Record product, architecture, update technology, servicing channel, and current build. Do not rely only on a generic “Office installed” result. - Prioritize exposed workflows. Start with users and teams that frequently open documents from customers, vendors, public mailboxes, file-transfer portals, or other external sources. - Deploy the correct release. Use the August 11 Office security update for the installed servicing channel. For MSI-based Outlook 2016, deploy KB5002755. - Verify the installed build. Confirm the resulting version against Microsoft’s channel-specific security table. A deployment job marked successful is not proof that the intended Office build is active. - Monitor exceptions. Track endpoints that are offline, held by update rings, failing health checks, or running end-of-support Office versions. Give every exception an owner and due date. - Investigate suspicious opens. If a user opened an unexpected Office file before the update, preserve the message and file metadata and review endpoint and email-security telemetry using the organization’s incident-response process. ## Exploitation status as of August 12, 2026 At publication, Microsoft reported the vulnerability as not publicly disclosed, not exploited, and assessed exploitation as unlikely. CISA’s CVE enrichment records exploitation as “none,” and CVE-2026-70329 was not listed in CISA’s Known Exploited Vulnerabilities catalog when DSE checked on August 12. Those are dated status statements, not guarantees about future activity. The presence of an official fix, the 8.8 score, and the potential for high impact support prompt remediation even without confirmed exploitation. ## A note about Microsoft’s attack-vector wording Microsoft’s published CVSS vector and the CVE Program record list the attack vector as Network (AV:N), and the CNA description says code execution is possible “over a network.” One sentence in Microsoft’s FAQ, however, refers to Local (AV:L). The same FAQ clearly states that the attacker sends a malicious file and the recipient must open it. The most defensible description from the available source material is therefore: the malicious file can be delivered over a network, but exploitation requires the recipient to open it locally. DSE is not using the inconsistent FAQ sentence to infer a different exploit path and recommends monitoring the MSRC page for revisions. ## Primary sources - [Microsoft Security Response Center: CVE-2026-70329](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-70329) — severity, CVSS, affected products, attack requirements, and vendor exploitation assessment. - [CVE Program record for CVE-2026-70329](https://www.cve.org/CVERecord?id=CVE-2026-70329) — published CNA record and CISA ADP enrichment. - [Microsoft Office security releases](https://learn.microsoft.com/en-us/officeupdates/microsoft365-apps-security-updates) — August 11, 2026 fixed builds by Office servicing channel. - [Microsoft KB5002755 for Outlook 2016](https://support.microsoft.com/kb/5002755) — MSI package applicability and update details. - [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) — checked August 12, 2026 for current KEV status. - [Microsoft lifecycle notice for products ending support October 14, 2025](https://learn.microsoft.com/en-us/lifecycle/announcements/october-14-2025-products-end-of-support) — Office 2019 and Office 2016 lifecycle context. Reviewed August 12, 2026. Vendor guidance and exploitation status can change; use the linked Microsoft advisory as the controlling source for later revisions. ## Primary reference - Name: Microsoft Security Response Center (MSRC) - Authority: msrc.microsoft.com - URL: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-70329 - Source publication date: 2026-08-11 ## Citation and use Preferred citation: “CVE-2026-70329 in Outlook: What the 8.8 RCE Means and How to Respond,” DSE Security, https://update.dsesecurity.com/updates/cve-2026-70329-microsoft-outlook-rce-patch-guidance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Data breach response: coordinate containment, investigation, communication, and notification > FTC guidance connects immediate operational security, forensic preservation, scope determination, corrective action, accurate communication, and fact-specific legal notification decisions. - Canonical URL: https://update.dsesecurity.com/updates/business-data-breach-response-sequence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:10+00:00 - Modified: 2026-07-19T21:27:10+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know FTC guidance connects immediate operational security, forensic preservation, scope determination, corrective action, accurate communication, and fact-specific legal notification decisions. ## Potentially affected U.S. organizations that store or process employee, customer, patient, financial, identity, authentication, or other sensitive personal information. ## DSE recommendation Activate qualified response resources, stop additional loss without destroying evidence, determine scope, remediate safely, document facts, and have counsel evaluate notification duties. ## Article A suspected data breach creates pressure to shut systems down, reassure customers, and announce an answer. Acting without forensic, legal, technical, and communications coordination can destroy evidence, leave the cause active, or produce statements that are incomplete or misleading. ## What the FTC guide establishes Source fact: The Federal Trade Commission organizes its business guidance around securing operations and notifying appropriate parties. It recommends mobilizing a response team that can include forensics, legal, information security, IT, operations, human resources, communications, management, and other functions appropriate to the organization. Source fact: The FTC advises moving quickly to stop additional loss, determine the source and scope, identify affected information and people, preserve evidence, correct vulnerabilities, document the investigation, and communicate accurately. It warns organizations not to turn affected machines off before forensic experts advise because powering down can affect evidence. Source fact: Notification duties vary. The FTC notes state and federal requirements and additional rules that may apply based on the information and organization. It advises consultation with counsel and coordination with law enforcement where appropriate. ## Coordinate overlapping response workstreams DSE recommendation: use the organization’s approved plan and activate qualified internal and external resources. Engage counsel and any insurer promptly when required by law, policy, or contract while qualified responders preserve evidence and contain harm. There is no universal sequence: legal, forensic, operational, safety, law-enforcement, insurer, vendor, and notification work can overlap, and their order depends on the facts and applicable obligations. - Protect people and essential operations, stop additional data loss, and preserve volatile and forensic evidence under qualified direction. - Determine the entry path, duration, systems, identities, persistence, data types, affected individuals or organizations, and remaining exposure. - Secure physical and digital access, compromised credentials, exposed information, affected integrations, and vulnerable systems without assuming the first containment action removed the actor. - Implement and validate corrective actions, clean restoration, monitoring, and the intended business transaction. - Document known facts, uncertainty, evidence, decisions, timestamps, scope, communications, and unresolved risk. - Have counsel determine required notices and timing; coordinate clear communications and practical affected-person guidance. ## Communicate facts without creating more harm DSE recommendation: designate an approved spokesperson and maintain one reviewed fact record. Explain what is known, what information was involved, what the organization has done, what affected people can do, and where updates will appear when counsel determines communication is appropriate. Do not speculate, minimize confirmed impact, disclose details that increase risk, or promise a result the investigation cannot support. ## Applicability and limits The FTC publication is general U.S. business guidance, not legal advice or a complete notification-law matrix. Requirements change and depend on jurisdiction, sector, data, contracts, insurer terms, and facts. This article intentionally provides no universal deadline or fixed response sequence. Organizations outside the United States need guidance for their applicable jurisdictions. ## Official reference [Data Breach Response: A Guide for Business](https://www.ftc.gov/business-guidance/resources/data-breach-response-guide-business) — FTC operational and notification considerations. ## Primary reference - Name: Federal Trade Commission: Data Breach Response — A Guide for Business - Authority: Federal Trade Commission - URL: https://www.ftc.gov/business-guidance/resources/data-breach-response-guide-business - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Data breach response: coordinate containment, investigation, communication, and notification,” DSE Security, https://update.dsesecurity.com/updates/business-data-breach-response-sequence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Decide how to use Arc best-practice assessments without treating findings as change approval > How should an Arc best-practice assessment be scheduled and its findings assigned? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-002-decide-how-to-use-arc-best-practice-assessments-without-treating-findings-as/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:17:09+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should an Arc best-practice assessment be scheduled and its findings assigned? ## Potentially affected Use this review when considering the assessment on an Arc-enabled Windows Server. ## DSE recommendation Choose a review cadence and name the person who will examine each report. ## Article ## Source facts Microsoft describes an assessment that compares Windows Server configuration with its best practices and supports scheduled or manually initiated runs. Its review covers areas including security, Hyper-V, clustering, and IIS, producing findings with remediation guidance. The documented Azure resource workflow labels Best Practices Assessment as a preview. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/manage/azure-arc/best-practices-assessment-for-windows-server). ## Applicability Use this review when considering the assessment on an Arc-enabled Windows Server. Check the current prerequisites and preview status, and identify the specific server and workload owner before enrolling it. ## DSE recommendation Choose a review cadence and name the person who will examine each report. Assign findings to the relevant workload owner, preserve the original assessment context, and evaluate proposed fixes individually. Ask the owner to distinguish an actionable mismatch from an intentional exception. Plan a pilot assessment on a representative server before deciding how broadly to enable the service. ## Verification Record when the assessment ran, which machine it examined, and which findings were returned. Follow a selected finding through investigation and an approved test change. Rerun the relevant assessment and compare results with actual workload behavior. Retain unresolved findings with an owner and a specific next review date. ## Official references [Microsoft Learn: How to configure best practices assessment for Arc-enabled Windows servers](https://learn.microsoft.com/en-us/windows-server/manage/azure-arc/best-practices-assessment-for-windows-server). Source reviewed September 8, 2026. ## Primary reference - Name: How to configure best practices assessment for Arc-enabled Windows servers - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/azure-arc/best-practices-assessment-for-windows-server - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Decide how to use Arc best-practice assessments without treating findings as change approval,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-002-decide-how-to-use-arc-best-practice-assessments-without-treating-findings-as/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Decide whether an external Hyper-V switch should share its adapter > How should host management access be considered when creating an external virtual switch? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-245-decide-whether-an-external-hyper-v-switch-should-share-its-adapter/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:06+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should host management access be considered when creating an external virtual switch? ## Potentially affected Administrators creating an external Hyper-V virtual switch on a managed host. ## DSE recommendation Map the physical adapter to its switch port and existing host use. ## Article ## Source facts Hyper-V provides external, internal, and private virtual-switch types. An external switch connects virtual machines to the external network through the selected physical adapter. The external-switch configuration includes an option that permits the management operating system to share that adapter. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Create-a-virtual-switch-for-Hyper-V-virtual-machines). ## Applicability Name the adapter and current management route before opening the switch wizard. This decision concerns the host operating system sharing an external connection; it does not establish a complete segmentation design. Consider the actual workload and management paths together. ## DSE recommendation Map the physical adapter to its switch port and existing host use. Ask the host owner whether management traffic should share this connection or use a separately approved route. Arrange a recovery route appropriate to that decision before changing the switch configuration. Record the chosen switch type, adapter, sharing setting, and any approved VLAN requirements so another operator can reproduce the intended arrangement. ## Verification After the approved change, verify both a representative guest connection and the administrator connection to the host. Inspect which adapter the external switch uses and whether the management-sharing setting matches the design. Investigate a guest-only success or a host-only success rather than treating either as proof that both paths work. ## Official references [Microsoft Learn: Create and configure a virtual switch with Hyper-V](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Create-a-virtual-switch-for-Hyper-V-virtual-machines). Source reviewed September 8, 2026. ## Primary reference - Name: Create and configure a virtual switch with Hyper-V - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Create-a-virtual-switch-for-Hyper-V-virtual-machines - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Decide whether an external Hyper-V switch should share its adapter,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-245-decide-whether-an-external-hyper-v-switch-should-share-its-adapter/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Decide whether an FSRM classification rule may replace existing values > When should an automatic FSRM classification rule re-evaluate an already classified file? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-109-decide-whether-an-fsrm-classification-rule-may-replace-existing-values/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:22+00:00 - Modified: 2026-09-08T18:23:26+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know When should an automatic FSRM classification rule re-evaluate an already classified file? ## Potentially affected Administrators configuring automatic FSRM file classification rules. ## DSE recommendation Prepare example files representing an unset property, a matching existing value, and a conflicting value. ## Article ## Source facts An FSRM classification rule assigns one property. By default, Microsoft’s procedure leaves files that already have a property value unchanged. Enabling re-evaluation introduces a choice between replacing an existing value and aggregating the new result with it. Microsoft’s Boolean example shows that aggregation can retain Yes when a rule proposes No, while overwrite changes it to No. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/fsrm/create-automatic-classification-rule). ## Applicability Identify the property, existing values, rule scope, classifier, and downstream consumers. Ask the data owner whether an earlier classification is authoritative, provisional, or intended to be combined with later evaluation. ## DSE recommendation Prepare example files representing an unset property, a matching existing value, and a conflicting value. Agree on the desired result for each before selecting overwrite or aggregation. Record the rule’s scope and enabled state and have the owner review any planned replacement of existing labels. ## Verification Run the approved examples through classification and compare the actual property values with the decision table. Re-run the process to inspect re-evaluation behavior. Preserve before-and-after values and resolve any unexpected aggregation result before expanding the rule to additional folders or using its output for another action. ## Official references [Microsoft Learn: Create an Automatic Classification Rule](https://learn.microsoft.com/en-us/windows-server/storage/fsrm/create-automatic-classification-rule). Source reviewed September 8, 2026. ## Primary reference - Name: Create an Automatic Classification Rule - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/fsrm/create-automatic-classification-rule - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Decide whether an FSRM classification rule may replace existing values,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-109-decide-whether-an-fsrm-classification-rule-may-replace-existing-values/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Decide whether an S2D server removal also removes its drives > What distinguishes temporary node removal from permanent Storage Spaces Direct scale-in? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-207-decide-whether-an-s2d-server-removal-also-removes-its-drives/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:44+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What distinguishes temporary node removal from permanent Storage Spaces Direct scale-in? ## Potentially affected Administrators removing servers from a Storage Spaces Direct cluster. ## DSE recommendation Have the storage owner sign off the intended removal type and the post-change node and drive inventory. ## Article ## Source facts Microsoft distinguishes removing a server while retaining its drives in the pool from permanently removing both the server and its drives. When drives remain expected but missing, the procedure does not move their data away; the source describes lost-communication and incomplete-volume states. Permanent scale-in requires sufficient remaining capacity for the volume footprints. The surviving fault-domain count must also support the volume resiliency configuration. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/remove-servers). ## Applicability State whether the server will return, its drives will move to another server, or its capacity is being retired permanently. Inventory volume footprints and the surviving resiliency layout. Do not equate a quick cluster-node removal with a completed evacuation of the server’s storage. ## DSE recommendation Have the storage owner sign off the intended removal type and the post-change node and drive inventory. For permanent scale-in, calculate remaining capacity and verify the required failure-domain count before scheduling the action. Preserve the planned return or recovery procedure and agree on the acceptable workload impact. Avoid switching between temporary removal and permanent retirement without reviewing the storage consequences. ## Verification Inspect node membership, pool drive membership, and volume health after the approved operation. Compare the observed result with the declared temporary or permanent intent. For retirement, verify the intended data movement and healthy surviving layout before releasing hardware. For temporary removal, track the expected return and unresolved missing-drive state explicitly. ## Official references [Microsoft Learn: Removing servers in Storage Spaces Direct](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/remove-servers). Source reviewed September 8, 2026. ## Primary reference - Name: Removing servers in Storage Spaces Direct - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/remove-servers - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Decide whether an S2D server removal also removes its drives,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-207-decide-whether-an-s2d-server-removal-also-removes-its-drives/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Decide whether Windows Network Load Balancing fits the application > When is a Windows NLB cluster an appropriate application distribution choice? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-163-decide-whether-windows-network-load-balancing-fits-the-application/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:28+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know When is a Windows NLB cluster an appropriate application distribution choice? ## Potentially affected Administrators evaluating Windows Network Load Balancing for server applications. ## DSE recommendation Prepare a short selection record comparing the documented NLB use case with the actual workload. ## Article ## Source facts Windows NLB combines multiple application servers into one virtual cluster and distributes incoming requests among those servers. Microsoft identifies stateless applications, including IIS web servers, as a practical use case. Its guidance directs SDN deployments, non-Windows workloads, outbound NAT requirements, and certain non-TCP load-balancing requirements toward Software Load Balancer instead. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/technologies/Network-Load-Balancing). ## Applicability Record the application protocol, server platform, session behavior, and networking design before selecting NLB. Ask the application owner to describe any state that must survive a host becoming unavailable. Do not substitute a network feature overview for that application-specific assessment. ## DSE recommendation Prepare a short selection record comparing the documented NLB use case with the actual workload. Name the application instances and decide how their readiness will be evaluated. Define a maintenance exercise that removes one host while representative users continue working. Set an acceptance threshold for the application transaction, with a clear owner for investigation if the result differs. ## Verification Measure completed transactions and errors before, during, and after the approved host-removal exercise. Verify that the remaining hosts receive requests and that the returning host behaves as intended. Include a state-dependent transaction when the application has one. Retain the selected design and rejected alternatives. ## Official references [Microsoft Learn: Network Load Balancing](https://learn.microsoft.com/en-us/windows-server/networking/technologies/Network-Load-Balancing). Source reviewed September 8, 2026. ## Primary reference - Name: Network Load Balancing - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/Network-Load-Balancing - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Decide whether Windows Network Load Balancing fits the application,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-163-decide-whether-windows-network-load-balancing-fits-the-application/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Decode encoded-words only where message header syntax allows them > Use RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:05+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Decode encoded-words only where message header syntax allows them. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text](https://www.rfc-editor.org/rfc/rfc2047.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Encoded-words are allowed only in specified text fields, comments, and phrase words; they are forbidden in addr-specs, quoted strings, Received fields, and MIME parameters. The research record locates this support at Section 5 (Use of encoded-words in message headers). - A reader first parses each header according to that field’s syntax, then recognizes encoded-words only in the locations that syntax permits. The research record locates this support at Section 6.1 (Recognition of encoded-words in message headers). - Decoded display occurs after a structured field has been parsed into tokens; decoding cannot safely turn the header into new parseable syntax. The research record locates this support at Section 6.2 (Display of encoded-words). Keep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 5 (Use of encoded-words in message headers), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 6.1 (Recognition of encoded-words in message headers), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 6.2 (Display of encoded-words), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations Section 5 (Use of encoded-words in message headers); Section 6.1 (Recognition of encoded-words in message headers); Section 6.2 (Display of encoded-words) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text](https://www.rfc-editor.org/rfc/rfc2047.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2047 — MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2047.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Decode encoded-words only where message header syntax allows them,” DSE Security, https://update.dsesecurity.com/updates/decode-encoded-words-only-where-message-header-syntax-allows-them/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Decode Windows DNS query, response, and update messages before troubleshooting > Use DNS Message Formats in Windows and Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/decode-windows-dns-query-response-and-update-messages-before-troubleshooting/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:33+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use DNS Message Formats in Windows and Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of DNS Message Formats in Windows and Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Decode Windows DNS query, response, and update messages before troubleshooting. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [DNS Message Formats in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/message-formats) from Microsoft supports the following bounded statements: - Microsoft documents query, response, and update message structures for DNS in Windows environments. The research record locates this support at DNS query message format; DNS query message header; DNS query response message; Update message format. - DNS messages use a header plus question, answer, authority, and additional sections as applicable. The research record locates this support at DNS query message format; DNS query message header; DNS query response message; Update message format. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish Message-format knowledge does not identify the failing component without packet, server, and client evidence from the affected transaction. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DNS query message format; DNS query message header; DNS query response message; Update message format, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DNS query message format; DNS query message header; DNS query response message; Update message format, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from DNS query message format; DNS query message header; DNS query response message; Update message format; DNS query message format; DNS query message header; DNS query response message; Update message format to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [DNS Message Formats in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/message-formats) — Microsoft ## Primary reference - Name: DNS Message Formats in Windows and Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/message-formats - Source publication date: 2025-07-02 ## Citation and use Preferred citation: “Decode Windows DNS query, response, and update messages before troubleshooting,” DSE Security, https://update.dsesecurity.com/updates/decode-windows-dns-query-response-and-update-messages-before-troubleshooting/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Define Delivery Optimization peer boundaries before Windows content moves > Delivery Optimization can obtain Windows content from peers, Connected Cache, or the HTTP source; download mode, network identity, proxy behavior, and reporting determine where content actually moves. - Canonical URL: https://update.dsesecurity.com/updates/windows-delivery-optimization-peer-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:05+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Delivery Optimization can obtain Windows content from peers, Connected Cache, or the HTTP source; download mode, network identity, proxy behavior, and reporting determine where content actually moves. ## Potentially affected Organizations using Windows Update, Intune, Configuration Manager, Microsoft 365 Apps, Store apps, or other supported Delivery Optimization content paths. ## DSE recommendation Choose peer groups from real network boundaries, validate proxy and VPN behavior, cap bandwidth, and use Delivery Optimization reporting to confirm source and peer behavior. ## Article Bottom line: Windows Delivery Optimization can retrieve supported Microsoft content from peers or cache infrastructure and falls back to the HTTP source when content is not available there. Peer grouping and network detection decide which devices can exchange content. Configure those boundaries before assuming the feature saves bandwidth or remains within a site. ## Source fact: what Microsoft documents Microsoft’s [Delivery Optimization overview](https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization) describes Delivery Optimization as a downloader for supported Windows and Microsoft content. It can work with Windows Update, WSUS, Intune or Windows Update policies, and Configuration Manager in documented scenarios. If content is unavailable from a peer or Connected Cache, the client can obtain it from the HTTP source. Microsoft provides separate documentation for download modes, group identification, network and proxy behavior, bandwidth controls, Connected Cache, monitoring, troubleshooting, and supported content. Requirements vary by Windows version and device type. The feature is a content-distribution mechanism; it does not decide whether an update should be approved or installed, and it does not replace deployment-ring or application testing. ## What the source does not establish Enabling peer-to-peer does not guarantee internet savings, fast delivery, or confinement to a building. NAT, VPN, proxy, VLAN, boundary, group-ID, and remote-work design influence peer discovery and routing. A device may still use Microsoft or cache sources. The overview does not prove a given content type is eligible, that a proxy inspection design is compatible, or that peer traffic is allowed by local policy and network controls. ## Applicability questions - Which supported content types and management systems are actually in use? - Should devices peer by public NAT, Active Directory site, authenticated group, subnet, office, VPN state, or another boundary? - Can remote users or branch offices reach unintended peers or saturate constrained links? - Which proxies, firewalls, TLS inspection, split tunneling, and Connected Cache nodes affect the path? - What bandwidth, business-hours, battery, and metered-network limits are required? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Draw content sources, client populations, WAN links, VPN routes, NAT boundaries, proxies, and caches. - Select download mode and group behavior for the intended peer trust and network boundary. Avoid relying on a default without testing. - Pilot at a branch, campus segment, and remote-user group. Measure peer, cache, and HTTP source bytes plus delivery time and WAN utilization. - Apply bandwidth controls and test loss of peers, cache, proxy, and internet source. - Monitor Delivery Optimization reports and client diagnostics; revise groups when network topology or remote-work patterns change. ## Verification and evidence - Preserve Delivery Optimization policy, group logic, proxy and cache configuration, and approvals. - Record client version, content, source type, peer relationship, bytes, timing, and network location in pilot tests. - Confirm devices outside an intended group cannot become peers under the selected design. - Compare WAN and internet use before and after rollout without attributing unrelated traffic to the feature. ## Official references - [What is Delivery Optimization?](https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization) — Microsoft ## Primary reference - Name: What is Delivery Optimization? - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Define Delivery Optimization peer boundaries before Windows content moves,” DSE Security, https://update.dsesecurity.com/updates/windows-delivery-optimization-peer-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Define interface-counter semantics before alerting on errors > Account for counter width, discontinuity, interface identity, and device semantics before turning SNMP deltas into incidents. - Canonical URL: https://update.dsesecurity.com/updates/define-interface-counter-semantics-before-alerting/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:37+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Explainer - DSE priority: Advisory - Topics: Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Account for counter width, discontinuity, interface identity, and device semantics before turning SNMP deltas into incidents. ## Potentially affected Monitoring systems that collect standard interface MIB counters from routers, switches, firewalls, servers, or appliances ## DSE recommendation Normalize interface identity and counter behavior per platform, then validate alerts against controlled traffic and known discontinuities. ## Article An interface counter is meaningful only when the collector knows what the interface represents, whether its identity remained stable, how wide the counter is, and whether it reset. Otherwise a wrap, reboot, or re-index can look like a giant error burst or impossible traffic rate. ## Source fact: [IETF RFC 2863](https://www.rfc-editor.org/rfc/rfc2863.html) defines the Interfaces Group MIB used to describe network interfaces through management protocols. It specifies objects for interface identity, type, speed, administrative and operational state, traffic octets and packets, errors, discards, multicast and broadcast counts, and relationships among layered interfaces. It also addresses high-capacity counters and the limitations of smaller counters at higher speeds. The specification recognizes discontinuities and the operational need to determine when counters may have changed non-continuously. It distinguishes ifAdminStatus from ifOperStatus and provides interface-stack relationships rather than assuming every row represents one physical port. These semantics allow a management application to interpret data; they do not require every device to attribute every fault in the same vendor-specific way. ## Boundary Standard MIB object names do not guarantee uniform hardware accounting. Vendors may count frames before or after a pipeline stage, expose logical and physical layers differently, or omit unsupported detail. Polling intervals, missed polls, counter width, device uptime, interface-index persistence, link aggregation, and speed changes affect derived rates. An increasing discard counter does not identify whether the root cause is congestion, policy, resource pressure, or another implementation condition. ## Applicability questions - Is each monitored row mapped to a stable asset, interface name, physical location, and service purpose? - Which counters are 32-bit or 64-bit, and can they wrap inside the polling interval at expected line rates? - How does the collector detect device restart, interface discontinuity, re-indexing, and replacement? - Which logical interfaces duplicate or aggregate traffic seen elsewhere? - What platform documentation explains each error or discard counter used for alerting? ## DSE recommendation: Build a device-family counter dictionary that records source object, width, collection interval, unit, discontinuity signal, interface layer, and vendor meaning. Use stable identifiers and inventory reconciliation rather than treating ifIndex alone as permanent. Discard samples across a restart or unexplained discontinuity instead of calculating a rate through them. Generate controlled traffic and a bounded fault in a lab or maintenance window to verify octet, packet, error, and discard behavior. Set alert thresholds from service impact, interface rate, baseline, duration, and topology role rather than one universal raw count. Correlate with queue, optics, link, routing, and application signals before assigning a cause. Review monitoring logic after hardware or software changes. ## Verification and evidence Retain the counter dictionary, device/version matrix, MIB source, interface mappings, poll timestamps, discontinuity handling, raw values, calculation formula, and controlled-test results. A sample alert should be reproducible from stored raw data and should identify whether a wrap or reset was excluded. Compare collector output with local device counters during commissioning. ## Official references - [IETF RFC 2863](https://www.rfc-editor.org/rfc/rfc2863.html) ## Primary reference - Name: RFC 2863: The Interfaces Group MIB - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2863.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Define interface-counter semantics before alerting on errors,” DSE Security, https://update.dsesecurity.com/updates/define-interface-counter-semantics-before-alerting/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Define NPS proxy server groups before distributing authentication load > What group membership and server preferences should be planned for NPS proxy load balancing? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-126-define-nps-proxy-server-groups-before-distributing-authentication-load/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:05+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What group membership and server preferences should be planned for NPS proxy load balancing? ## Potentially affected Administrators distributing RADIUS requests through NPS proxies. ## DSE recommendation Write the proposed membership and preference settings in a table owned by the authentication team. ## Article ## Source facts NPS proxy load balancing requires more than one RADIUS server in a remote server group. Microsoft calls for a deployment plan covering the required groups, their members, and each server’s Priority and Weight settings. The guidance also describes sending client requests to two proxies and having those proxies distribute work among backend RADIUS servers, providing paths at both tiers. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-proxy-lb). ## Applicability Inventory the network access servers, proxy addresses, remote groups, backend capacity, and authentication requirements. Review which servers are equivalent destinations before placing them in one distribution group. ## DSE recommendation Write the proposed membership and preference settings in a table owned by the authentication team. Ask the network-access owners to confirm the proxy destinations configured on their devices. Define expected behavior when a backend or proxy is unavailable, including who will investigate an authentication surge. ## Verification Generate controlled requests from representative access devices and examine which proxy and backend handled them. Repeat with one approved unavailable component at a time. Compare the observed distribution and authentication results with the plan; resolve an unreachable group member before relying on the arrangement for continuity. ## Official references [Microsoft Learn: NPS Proxy Server Load Balancing](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-proxy-lb). Source reviewed September 8, 2026. ## Primary reference - Name: NPS Proxy Server Load Balancing - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-proxy-lb - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Define NPS proxy server groups before distributing authentication load,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-126-define-nps-proxy-server-groups-before-distributing-authentication-load/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Define quota-template notifications before a file share reaches its limit > Which threshold actions should accompany an FSRM quota template? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-080-define-quota-template-notifications-before-a-file-share-reaches-its-limit/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:51+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Which threshold actions should accompany an FSRM quota template? ## Potentially affected Use this review when creating a quota template for an identified storage policy. ## DSE recommendation Choose thresholds that leave the owner enough time to investigate the expected growth pattern. ## Article ## Source facts An FSRM quota template specifies a capacity limit, hard or soft quota type, and optional threshold notifications. Threshold actions can include email, an event, a command or script, or reports. Multiple actions and thresholds are possible, but no notifications are configured by default. Microsoft describes templates as a central way to manage quotas derived from them. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/fsrm/create-quota-template). ## Applicability Use this review when creating a quota template for an identified storage policy. Name the data owner, intended quota type, capacity limit, and people who must act on threshold information before applying the template. ## DSE recommendation Choose thresholds that leave the owner enough time to investigate the expected growth pattern. Assign a response to each notification and verify the destination or recipient. Review any command or script action as executable administration with its own approved scope. Record which quotas will derive from the template and how later template updates will be reviewed. ## Verification Use an approved test quota to reach the selected thresholds and inspect the actual actions. Confirm that the intended recipient can interpret and act on the notification. Check the quota type and limit separately from message delivery. Resolve missing or excessive notifications before applying the template to more shares or changing a shared threshold. ## Official references [Microsoft Learn: Create a Quota Template](https://learn.microsoft.com/en-us/windows-server/storage/fsrm/create-quota-template). Source reviewed September 8, 2026. ## Primary reference - Name: Create a Quota Template - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/fsrm/create-quota-template - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Define quota-template notifications before a file share reaches its limit,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-080-define-quota-template-notifications-before-a-file-share-reaches-its-limit/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Define rack fault domains before enabling campus-cluster storage > What topology evidence is required before enabling S2D in a campus cluster? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-183-define-rack-fault-domains-before-enabling-campus-cluster-storage/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:08+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What topology evidence is required before enabling S2D in a campus cluster? ## Potentially affected Administrators creating the documented Windows Server Storage Spaces Direct campus-cluster topology. ## DSE recommendation Have facilities and storage owners review a rack map that identifies every node, power source, network dependency, and the separate witness location. ## Article ## Source facts Microsoft describes a campus cluster as nodes and data distributed across two physical racks in separate rooms or buildings on one campus. Its procedure requires defining the two rack fault domains before enabling Storage Spaces Direct. After enablement, the documented verification checks that the storage pool reports StorageRack for FaultDomainAwareness. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/failover-clustering/create-storage-spaces-direct-campus-cluster). ## Applicability Check the current prerequisites in full, including the Windows build and update, supported drive configuration, balanced node placement, and witness location. Match the logical rack names to the actual physical layout. Do not adapt the example solely from the total node count. ## DSE recommendation Have facilities and storage owners review a rack map that identifies every node, power source, network dependency, and the separate witness location. Record the intended rack membership before storage enablement and obtain a second-person check of the mapping. Define an approved rack-loss acceptance exercise with the application owner. Keep the topology record with the cluster configuration rather than in an unrelated floor plan. ## Verification Verify each node belongs to the intended rack domain and inspect the pool fault-domain-awareness value. Compare the observed placement with the signed-off map. In an approved environment, exercise the chosen rack-failure scenario and validate application behavior and recovery. Resolve incorrect rack membership before treating the cluster as rack-resilient. ## Official references [Microsoft Learn: Create a Storage Spaces Direct Campus Cluster](https://learn.microsoft.com/en-us/windows-server/failover-clustering/create-storage-spaces-direct-campus-cluster). Source reviewed September 8, 2026. ## Primary reference - Name: Create a Storage Spaces Direct Campus Cluster - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/create-storage-spaces-direct-campus-cluster - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Define rack fault domains before enabling campus-cluster storage,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-183-define-rack-fault-domains-before-enabling-campus-cluster-storage/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Define secured areas, access systems, law-enforcement support, and contingencies in the airport security program > Use 49 CFR 1542.103 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/define-secured-areas-access-systems-law-enforcement-support-and-contingencies-in-the-airport-securit/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:39+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.103 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.103 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Define secured areas, access systems, law-enforcement support, and contingencies in the airport security program. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.103 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.103) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, an airport security program must describe the law-enforcement support used to comply with section 1542.215(a). The research record locates this support at 49 CFR 1542.103(a)(12), read with 49 CFR 1542.103(a) (eCFR anchor p-1542.103(a)(12)). - Under 49 CFR 1542, an airport security program must describe sterile-area access controls used to comply with section 1542.207. The research record locates this support at 49 CFR 1542.103(a)(6)(iii), read with 49 CFR 1542.103(a)(6)|1542.103(a) (eCFR anchor p-1542.103(a)(6)(iii)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths and the conditions the source actually describes. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 49 CFR 1542.103(a)(12), read with 49 CFR 1542.103(a) (eCFR anchor p-1542.103(a)(12)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.103(a)(6)(iii), read with 49 CFR 1542.103(a)(6)|1542.103(a) (eCFR anchor p-1542.103(a)(6)(iii)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations 49 CFR 1542.103(a)(12), read with 49 CFR 1542.103(a) (eCFR anchor p-1542.103(a)(12)); 49 CFR 1542.103(a)(6)(iii), read with 49 CFR 1542.103(a)(6)|1542.103(a) (eCFR anchor p-1542.103(a)(6)(iii)) adjacent to the sanitized artifacts used for comparison. Prefer asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [49 CFR 1542.103 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.103) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.103 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.103 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Define secured areas, access systems, law-enforcement support, and contingencies in the airport security program,” DSE Security, https://update.dsesecurity.com/updates/define-secured-areas-access-systems-law-enforcement-support-and-contingencies-in-the-airport-securit/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Define supported Hyper-V Replica use for domain-controller VMs > Use Support for using Hyper-V Replica for virtualized domain controllers to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/define-supported-hyper-v-replica-use-for-dc-vms/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:10+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Support for using Hyper-V Replica for virtualized domain controllers to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Support for using Hyper-V Replica for virtualized domain controllers ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Define supported Hyper-V Replica use for domain-controller VMs. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Support for using Hyper-V Replica for virtualized domain controllers](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/support-for-using-hyper-v-replica-for-virtualized-domain-controllers) from Microsoft supports the following bounded statements: - Hyper-V Replica asynchronously replicates selected VMs across LAN or WAN links. The research record locates this support at Opening overview. - The document distinguishes supported and unsupported scenarios and requires Windows Server 2012 or newer domain controllers. The research record locates this support at Sections: Windows Server 2012 or newer domain controllers required; Supported and unsupported scenarios. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles only where the source and recorded environment align. ## What the source does not establish VM replication does not replace AD-aware backup, recovery planning, or replication-health monitoring. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: Windows Server 2012 or newer domain controllers required; Supported and unsupported scenarios, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from Opening overview; Sections: Windows Server 2012 or newer domain controllers required; Supported and unsupported scenarios to the observed environment. Useful domain evidence includes directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Support for using Hyper-V Replica for virtualized domain controllers](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/support-for-using-hyper-v-replica-for-virtualized-domain-controllers) — Microsoft ## Primary reference - Name: Support for using Hyper-V Replica for virtualized domain controllers - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/support-for-using-hyper-v-replica-for-virtualized-domain-controllers - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Define supported Hyper-V Replica use for domain-controller VMs,” DSE Security, https://update.dsesecurity.com/updates/define-supported-hyper-v-replica-use-for-dc-vms/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Define the CUI system boundary before claiming NIST SP 800-171 coverage > SP 800-171 Rev. 3 applies recommended confidentiality requirements to nonfederal system components that process, store, transmit, or protect CUI. Start with authoritative scope and data flow. - Canonical URL: https://update.dsesecurity.com/updates/cui-system-boundary-sp-800-171/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:33:55+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know SP 800-171 Rev. 3 applies recommended confidentiality requirements to nonfederal system components that process, store, transmit, or protect CUI. Start with authoritative scope and data flow. ## Potentially affected Nonfederal organizations whose federal contracts or agreements require protection of Controlled Unclassified Information in their systems or services. ## DSE recommendation Confirm the governing agreement and CUI authority, map every component and service that handles or protects the information, document boundary decisions, and evaluate requirements against that verified scope. ## Article Bottom line: an organization cannot evaluate CUI safeguards accurately until it knows what information is CUI, which agreement governs it, where it flows, and which system components process, store, transmit, or protect it. Scope is an evidence problem, not a label attached to an entire company or one server. ## Source fact: what NIST SP 800-171 covers [NIST SP 800-171 Revision 3](https://csrc.nist.gov/pubs/sp/800/171/r3/final) provides federal agencies with recommended security requirements for protecting the confidentiality of Controlled Unclassified Information when it resides in nonfederal systems and organizations. NIST states that the requirements apply to nonfederal system components that process, store, or transmit CUI or that provide protection for those components. The publication is intended for use by federal agencies in contracts or other agreements with nonfederal organizations. NIST identifies SP 800-171A as the companion assessment-procedure publication. Requirements and assessment evidence are therefore related but distinct. ## What the source does not establish SP 800-171 does not determine by itself whether a particular file, email, drawing, recording, ticket, or database is CUI. It does not create a contract requirement for every private organization, certify an environment, or prove compliance through a self-applied label. This draft is not legal or contracting advice. The responsible contracting and information authorities must resolve classification, marking, clause, flow-down, version, and assessment obligations. Other rules may apply in addition to SP 800-171. ## Applicability questions - Which contract, agreement, agency instruction, or authorized source establishes that the information is CUI and identifies the applicable requirements? - Where is CUI created, received, viewed, transformed, transmitted, stored, backed up, logged, supported, and destroyed? - Which identity, network, endpoint, cloud, security, monitoring, backup, support, and recovery components provide protection to those flows? - Which suppliers or subprocessors can access or protect the information, and what obligations flow to them? - How are changes to data flow or system architecture reviewed before they alter the boundary? ## DSE recommendation: build a defensible boundary record The following steps are DSE recommendations based on the cited source. - Obtain the governing contract or agreement, applicable clauses, authorized CUI category and marking direction, and responsible customer contacts. Resolve ambiguity with the appropriate authority. - Trace representative information from receipt or creation through all processing, storage, transmission, protection, backup, support, and disposal paths. - Identify components that handle CUI and components that protect them. Document included and excluded services, trust relationships, administrative paths, and shared dependencies with rationale. - Validate the boundary against actual configuration, logs, user workflows, integrations, and supplier access rather than diagrams alone. - Map the applicable SP 800-171 revision’s requirements to responsible owners and evidence within the verified boundary. Record gaps and planned actions honestly. - Put boundary review into change, onboarding, new integration, recovery, and supplier-management processes. ## Verification and evidence Retain the authoritative scope documents, data-flow diagrams, system and service inventory, sample workflow traces, configuration and log evidence, supplier records, boundary decisions, requirement mapping, gaps, approvals, and periodic review. Ensure sensitive evidence itself is stored and shared appropriately. ## Official references - [NIST SP 800-171 Rev. 3 — Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/171/r3/final) — National Institute of Standards and Technology; published May 2024 - [NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI](https://csrc.nist.gov/pubs/sp/800/171/a/r3/final) — National Institute of Standards and Technology - [CUI Registry](https://www.archives.gov/cui/registry/category-list) — National Archives and Records Administration; authoritative program registry ## Primary reference - Name: NIST SP 800-171 Rev. 3 — Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/171/r3/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Define the CUI system boundary before claiming NIST SP 800-171 coverage,” DSE Security, https://update.dsesecurity.com/updates/cui-system-boundary-sp-800-171/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Define the regulated Facility Security Assessment before drafting the plan > Use 33 CFR 105.300 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/define-the-regulated-facility-security-assessment-before-drafting-the-plan/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:58+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.300 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.300 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Define the regulated Facility Security Assessment before drafting the plan. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.300 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.300) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the Facility Security Assessment (FSA) is a written document that is based on the collection of background information, the completion of an on-scene survey and an analysis of that information. The research record locates this support at 33 CFR 105.300(a) (eCFR anchor p-105.300(a)). - Under 33 CFR 105, the rule requires that those involved in a FSA be able to draw upon expert assistance in the following areas, as appropriate: facility security requirements. The research record locates this support at 33 CFR 105.300(d)(7), read with 33 CFR 105.300(d) (eCFR anchor p-105.300(d)(7)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths only where the source and recorded environment align. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.300(a) (eCFR anchor p-105.300(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.300(d)(7), read with 33 CFR 105.300(d) (eCFR anchor p-105.300(d)(7)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from 33 CFR 105.300(a) (eCFR anchor p-105.300(a)); 33 CFR 105.300(d)(7), read with 33 CFR 105.300(d) (eCFR anchor p-105.300(d)(7)) through asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [33 CFR 105.300 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.300) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.300 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.300 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Define the regulated Facility Security Assessment before drafting the plan,” DSE Security, https://update.dsesecurity.com/updates/define-the-regulated-facility-security-assessment-before-drafting-the-plan/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Define the supported post-quantum certificate scope in AD CS > Use Post-Quantum Cryptography in AD CS overview - Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/define-supported-pqc-certificate-scope-in-ad-cs/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:14+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Post-Quantum Cryptography in AD CS overview - Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Post-Quantum Cryptography in AD CS overview - Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Define the supported post-quantum certificate scope in AD CS. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Post-Quantum Cryptography in AD CS overview – Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/post-quantum-cryptography-overview) from Microsoft supports the following bounded statements: - AD CS can issue and manage certificates using algorithms intended to resist quantum-capable attacks. The research record locates this support at Opening overview. - The current documented AD CS post-quantum algorithm is ML-DSA, with platform and certificate-format requirements. The research record locates this support at Opening overview; sections: PQC algorithms supported; Platform requirements. Only the traced statements above are asserted as source facts. Apply the review to certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles after confirming that the source and deployed context match. ## What the source does not establish Do not infer application or protocol support from CA support; validate every relying party. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview; sections: PQC algorithms supported; Platform requirements, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles are in and out of scope? - Which condition in Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations Opening overview; Opening overview; sections: PQC algorithms supported; Platform requirements adjacent to the sanitized artifacts used for comparison. Prefer CA and template exports, enrollment tests, certificate chains, access-control entries, event logs, and revocation-path checks, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Post-Quantum Cryptography in AD CS overview – Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/post-quantum-cryptography-overview) — Microsoft ## Primary reference - Name: Post-Quantum Cryptography in AD CS overview - Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/post-quantum-cryptography-overview - Source publication date: 2026-05-12 ## Citation and use Preferred citation: “Define the supported post-quantum certificate scope in AD CS,” DSE Security, https://update.dsesecurity.com/updates/define-supported-pqc-certificate-scope-in-ad-cs/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Delegate a PowerShell task through JEA—not a broad administrator group > Just Enough Administration can expose a constrained PowerShell endpoint backed by a privileged virtual account or gMSA, but endpoint commands, parameters, run-as identity, and transcripts define the real boundary. - Canonical URL: https://update.dsesecurity.com/updates/powershell-jea-task-delegation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:07+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Just Enough Administration can expose a constrained PowerShell endpoint backed by a privileged virtual account or gMSA, but endpoint commands, parameters, run-as identity, and transcripts define the real boundary. ## Potentially affected Windows environments granting administrators or operators elevated rights for narrow PowerShell-manageable tasks. ## DSE recommendation Model one administrative job, expose only required commands and parameters, select the least-capable run-as identity, test escape paths, and review JEA logs and role membership. ## Article Bottom line: PowerShell Just Enough Administration (JEA) can let a nonadministrator perform a defined privileged task through a constrained remoting endpoint. The security boundary is created by the endpoint access list, role capabilities, allowed commands and parameters, and run-as identity. A loosely designed command can return broad administration through another route. ## Source fact: what Microsoft documents Microsoft’s [JEA overview](https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/jea/overview?view=powershell-7.6) describes JEA as delegated administration for PowerShell-managed systems. JEA can use temporary virtual accounts or group-managed service accounts to perform privileged actions for connecting users, limit which cmdlets, functions, external commands, and providers they can use, and create transcripts or logs of commands executed in the session. Microsoft organizes the implementation around role-capability files and session configurations. Role capabilities define what a role can run. Session configurations define who may use the endpoint, which roles apply, and the run-as behavior. The associated Microsoft security guidance warns that the chosen run-as identity determines what the endpoint can ultimately do and that JEA does not protect a system from users who already have administrator rights outside the endpoint. ## What the source does not establish JEA does not make an unsafe command safe. A permitted script, wildcard parameter, provider, external executable, or command that accepts arbitrary input can become an escape path. Transcription is not guaranteed to capture secrets safely or replace protected event logging. A JEA endpoint does not remove existing direct local, domain, RDP, API, or application privileges unless those are separately revoked. ## Applicability questions - What exact administrative outcome must the operator achieve? - Which cmdlets, functions, parameter values, providers, files, registry keys, services, and remote systems are truly required? - Should the run-as identity be a virtual account or gMSA, and what effective privileges does it have locally and remotely? - Who can connect to the endpoint, edit its files, or register a new endpoint? - Where are transcripts and events stored, and can operators alter or read sensitive records? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Start with one observable job and write its required commands, parameters, targets, expected outputs, and prohibited actions. - Create the least-capable role and run-as identity. Avoid wildcards, arbitrary script blocks, unrestricted paths, and general shells. - Test as the delegated user for intended success and escape attempts through parameters, aliases, functions, executables, providers, and remoting. - Remove the broader administrator membership that JEA is meant to replace only after the endpoint and recovery path are proven. - Review endpoint ACLs, role mappings, files, transcripts, and use on a fixed cadence. ## Verification and evidence - Preserve session configuration, role-capability files, hashes, ACLs, run-as identity, and change approval. - Record allowed and denied command tests from an actual delegated account. - Verify transcripts and events reach a protected location and do not routinely expose secrets. - Reconcile JEA users with local, domain, application, and remote-administration privileges. ## Official references - [Just Enough Administration](https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/jea/overview?view=powershell-7.6) — Microsoft ## Primary reference - Name: Just Enough Administration - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/jea/overview?view=powershell-7.6 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Delegate a PowerShell task through JEA—not a broad administrator group,” DSE Security, https://update.dsesecurity.com/updates/powershell-jea-task-delegation/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Delegate AD administration at the narrowest OU boundary > Use Delegation of Control in AD DS on Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/delegate-ad-administration-at-narrowest-ou-boundary/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:36+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Delegation of Control in AD DS on Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Delegation of Control in AD DS on Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Delegate AD administration at the narrowest OU boundary. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Delegation of Control in AD DS on Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegation-control-wizard) from Microsoft supports the following bounded statements: - Delegation assigns selected administrative tasks without making every operator a domain-wide or forest-wide administrator. The research record locates this support at Opening overview. - Administrative control can be delegated at specific organizational-unit levels in the domain tree. The research record locates this support at Opening overview. Only the traced statements above are asserted as source facts. Apply the review to forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles after confirming that the source and deployed context match. ## What the source does not establish Document task, object type, OU scope, and revocation owner for every delegation. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations Opening overview; Opening overview adjacent to the sanitized artifacts used for comparison. Prefer directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Delegation of Control in AD DS on Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegation-control-wizard) — Microsoft ## Primary reference - Name: Delegation of Control in AD DS on Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegation-control-wizard - Source publication date: 2025-07-09 ## Citation and use Preferred citation: “Delegate AD administration at the narrowest OU boundary,” DSE Security, https://update.dsesecurity.com/updates/delegate-ad-administration-at-narrowest-ou-boundary/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Delegate domain join with object-level permissions, not broad quotas > Use Active Directory domain join permissions in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/delegate-domain-join-with-object-level-permissions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:56+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Active Directory domain join permissions in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Active Directory domain join permissions in Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Delegate domain join with object-level permissions, not broad quotas. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Active Directory domain join permissions in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/active-directory-domain-join-permissions) from Microsoft supports the following bounded statements: - Required domain-join permissions differ when creating a new computer account versus reusing an existing one. The research record locates this support at Opening overview. - For a new account, the joiner needs either the workstation-join right or permission to create computer objects; Microsoft does not recommend the quota-based option. The research record locates this support at Section: Scenario 1 – Permissions for creating computer accounts. Keep the evidence boundary at these traced claims. They support a review of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Grant only the object and OU permissions required by the chosen provisioning workflow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section: Scenario 1 – Permissions for creating computer accounts, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Section: Scenario 1 – Permissions for creating computer accounts through directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Active Directory domain join permissions in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/active-directory-domain-join-permissions) — Microsoft ## Primary reference - Name: Active Directory domain join permissions in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/active-directory-domain-join-permissions - Source publication date: 2025-08-26 ## Citation and use Preferred citation: “Delegate domain join with object-level permissions, not broad quotas,” DSE Security, https://update.dsesecurity.com/updates/delegate-domain-join-with-object-level-permissions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Delete unreachable DC objects during forest-recovery cleanup > Use AD Forest Recovery - Cleaning metadata of removed writable domain controllers to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/delete-unreachable-dc-objects-during-recovery-cleanup/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:19+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use AD Forest Recovery - Cleaning metadata of removed writable domain controllers to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of AD Forest Recovery - Cleaning metadata of removed writable domain controllers ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Delete unreachable DC objects during forest-recovery cleanup. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [AD Forest Recovery – Cleaning metadata of removed writable domain controllers](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-cleaning-metadata-of-removed-dcs) from Microsoft supports the following bounded statements: - Metadata cleanup removes AD data that identifies a domain controller to the replication system. The research record locates this support at Opening overview. - The cleanup applies when a controller cannot complete normal demotion because it is no longer reachable. The research record locates this support at Opening overview. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps only where the source and recorded environment align. ## What the source does not establish Delete only controllers the recovery plan identifies for reinstall; preserve surviving authorities. A correct source interpretation can still be inapplicable to a particular design. Confirm offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Opening overview; Opening overview to the observed environment. Useful domain evidence includes backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [AD Forest Recovery – Cleaning metadata of removed writable domain controllers](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-cleaning-metadata-of-removed-dcs) — Microsoft ## Primary reference - Name: AD Forest Recovery - Cleaning metadata of removed writable domain controllers - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-cleaning-metadata-of-removed-dcs - Source publication date: 2023-06-21 ## Citation and use Preferred citation: “Delete unreachable DC objects during forest-recovery cleanup,” DSE Security, https://update.dsesecurity.com/updates/delete-unreachable-dc-objects-during-recovery-cleanup/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Demand evidence, not promises, when buying digital technology > Secure technology procurement evaluates verifiable evidence before purchase and throughout the lifecycle, including defaults, development, components, updates, access, data, support, and exit. - Canonical URL: https://update.dsesecurity.com/updates/secure-verifiable-technology-procurement/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:10+00:00 - Modified: 2026-07-19T21:27:10+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Secure technology procurement evaluates verifiable evidence before purchase and throughout the lifecycle, including defaults, development, components, updates, access, data, support, and exit. ## Potentially affected Executives, procurement teams, IT and security leaders, risk advisers, product owners, and manufacturers buying or supplying digital products and services. ## DSE recommendation Define requirements before solicitation, request proportionate security evidence, distinguish assurance types, validate critical claims, record residual risk, and reassess material change. ## Article A product demonstration can show that a feature exists. It does not prove how the product was developed, whether safe defaults are enabled, what components it contains, how updates are protected, or whether security will be maintained through the promised lifecycle. ## What the joint procurement guidance says Source fact: CISA and international partners encourage buyers to evaluate whether a digital product or service is secure before purchase and whether security will be maintained throughout its specified lifecycle. Security considerations integrated into procurement can support informed, risk-based decisions and reduce avoidable operating and incident costs. Source fact: The co-sealed guidance addresses transparency and reporting, secure defaults, security requirements, supply-chain risk, open-source use, data sharing and sovereignty, development, manufacturer access, insider risk, open standards, connected systems, delivery integrity, updates, and post-purchase management. Source fact: Manufacturer evidence can include attestations, independent assessment, testing, development practices, component transparency, vulnerability handling, digital signatures, and update-delivery controls. The publication states that it is not an exhaustive checklist and cannot guarantee a perfect procurement outcome. ## Define evidence before accepting claims DSE recommendation: document security, privacy, availability, data-location, integration, logging, support, update, recovery, accessibility, and end-of-life requirements before selecting a product. Scale questions and validation to the product’s business impact, privilege, data, connectivity, replaceability, and concentration risk. - Ask how secure development is governed and what evidence shows testing, component control, change approval, and vulnerability remediation operate. - Identify security features enabled by default, added cost or licensing, unsafe deviations, administrative access, and customer configuration duties. - Review open-source and third-party component governance, signed delivery and updates, support duration, end-of-life notice, and recovery options. - Determine manufacturer and subprocessor access, data use and location, incident notification, log availability, ownership changes, and exit treatment. - Test the claims that matter most in a bounded evaluation and record exceptions and compensating controls. ## Distinguish kinds of assurance DSE recommendation: label a statement accurately as a vendor claim, self-attestation, independent assessment, certification, document review, customer test, or observed production evidence. Each supports a different level and scope of confidence. Record residual risk and obtain acceptance from the correct authority rather than converting unanswered questions into assumed compliance. After purchase, reassess material changes in product design, components, provider ownership, hosting, data use, vulnerabilities, support, update method, or access. Procurement evidence becomes stale when the product changes. ## Applicability and limits The full guidance is led by Australia’s ASD/ACSC and co-sealed by CISA and other national authorities. Jurisdiction, sector, contract, sanctions, export, sovereignty, and assurance requirements differ. An attestation or certification is not proof that a product is vulnerability-free, and lack of a particular certificate does not by itself establish insecurity. ## Official reference [Choosing Secure and Verifiable Technologies](https://www.cisa.gov/resources-tools/resources/choosing-secure-and-verifiable-technologies) — CISA’s official page for the co-sealed procurement guidance. ## Primary reference - Name: CISA and international partners: Choosing Secure and Verifiable Technologies - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/resources-tools/resources/choosing-secure-and-verifiable-technologies - Source publication date: 2024-12-05 ## Citation and use Preferred citation: “Demand evidence, not promises, when buying digital technology,” DSE Security, https://update.dsesecurity.com/updates/secure-verifiable-technology-procurement/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Deploy application allowlisting as a controlled production change > Application allowlisting can stop unauthorized code, but rushed enforcement can stop the business too. Discover real execution paths, learn in audit mode, pilot by cohort, and govern exceptions, updates, rollback, and recovery. - Canonical URL: https://update.dsesecurity.com/updates/deploy-application-allowlisting-as-a-controlled-production-change/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 4 minutes ## What you need to know Application allowlisting can stop unauthorized code, but rushed enforcement can stop the business too. Discover real execution paths, learn in audit mode, pilot by cohort, and govern exceptions, updates, rollback, and recovery. ## Potentially affected Endpoint engineering, server and application owners, security operations, change management, service desk, software packaging, and business continuity teams. ## DSE recommendation Select a bounded initial scope, observe legitimate execution in audit mode, build maintainable rules, pilot enforcement, and require owned, expiring exceptions plus tested rollback. ## Article ## Source fact: allowlisting changes the execution rule Application allowlisting permits authorized software and components to run while stopping unauthorized items. [NIST Special Publication 800-167](https://csrc.nist.gov/pubs/sp/800/167/final) explains that the technology can prevent malware and other unauthorized software from executing, but it also requires planning, implementation, maintenance, and lifecycle management. This is a production control, not a scanner that can be enabled everywhere without operational discovery. NIST describes audit mode as informative rather than enforcing and notes its value when a technology is first deployed so that policy can be tuned. NIST’s implementation summary recommends a phased approach: assess risk, operate in monitoring mode, correct problems and retest, then implement gradually. The [NIST implementation overview](https://www.nist.gov/news-events/news/2015/11/nist-offers-guidance-using-technology-prevent-intrusions-malware) reinforces that sequence. ## DSE recommendation: start with a bounded service outcome DSE recommendation: choose a first cohort where the business process, software set, ownership, support path, and recovery method are understood. Stable administrative workstations, kiosks, or a well-owned server role may be better candidates than a heterogeneous developer fleet. Make the selection from local risk and operational evidence; no official source supplies a universal first target. Define success before collecting logs: unauthorized execution is blocked in the enforced cohort, required work continues, incidents route to a staffed owner, software updates remain supportable, and rollback is available. Record systems explicitly out of scope and why. A partial, observable deployment is preferable to nominal enterprise coverage with permanent bypasses. ## Learn what actually executes - Inventory workflows, not only installed applications. Include login scripts, scheduled tasks, management agents, installers, updaters, plug-ins, macros, command interpreters, libraries, portable tools, temporary paths, and recovery utilities. - Run audit mode through representative cycles. Observe routine work, month-end or seasonal jobs, patching, application upgrades, failover, support sessions, and recovery tests. Label events by device, user, parent process, signer, path, hash, and business function where the platform provides those fields. - Resolve unknowns with owners. Do not automatically allow every item seen during learning. Determine whether it is required, supported, authentic, appropriately located, and expected to execute in that context. - Design maintainable rules. Publisher rules can survive signed updates but may authorize a broader product family. Hash rules are narrow but change with each binary. Path rules are dangerous where untrusted users can write. Use the control types supported by the chosen platform and document the trust boundary each rule creates. ## Pilot enforcement and protect the escape path Create small cohorts that represent the target population, with named business testers and support coverage. Enforce, review blocks promptly, correct the rule or workflow, and expand only after the cohort completes the agreed operating cycle. Do not measure the pilot only by ticket volume; a silent failure in a scheduled job can matter more than many harmless audit events. Every exception should identify the software or behavior, affected systems, business justification, requestor, approver, compensating controls, issue date, expiry or review date, and permanent resolution. Emergency approval must remain traceable. Broad exclusions for user-writable folders, interpreters, or entire publisher families deserve higher scrutiny because they can reopen the execution path the control was meant to close. Test policy recovery before broad enforcement. Keep an independently accessible copy of the last known-good policy, removal or break-glass procedure, recovery credentials, responsible contacts, and a way to operate if the policy service is unavailable. Require application owners to test normal updates under the enforced policy and coordinate rule deployment with software releases. This connects allowlisting to change and continuity management rather than leaving it as an endpoint-only setting. ## Review the control as the environment changes NIST’s full publication, available through its [official DOI](https://doi.org/10.6028/NIST.SP.800-167), treats maintenance as part of the technology lifecycle. Review unused rules, expired exceptions, blocked execution with business impact, rule changes, coverage against the intended population, and successful rollback tests. A high count of permitted applications is not evidence of control quality. The question is whether the policy authorizes the smallest maintainable set required for the service. ## Official sources - [NIST: Special Publication 800-167, Guide to Application Whitelisting](https://csrc.nist.gov/pubs/sp/800/167/final) - [NIST: Official SP 800-167 publication](https://doi.org/10.6028/NIST.SP.800-167) - [NIST: Implementation overview for application whitelisting](https://www.nist.gov/news-events/news/2015/11/nist-offers-guidance-using-technology-prevent-intrusions-malware) ## Primary reference - Name: NIST Special Publication 800-167 - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/167/final - Source publication date: 2015-10-28 ## Citation and use Preferred citation: “Deploy application allowlisting as a controlled production change,” DSE Security, https://update.dsesecurity.com/updates/deploy-application-allowlisting-as-a-controlled-production-change/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Deploy Azure-hosted domain controllers across an availability set > Use Install Active Directory Domain Services on an Azure virtual machine to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/deploy-azure-domain-controllers-across-availability-set/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:13+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Install Active Directory Domain Services on an Azure virtual machine to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Install Active Directory Domain Services on an Azure virtual machine ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Deploy Azure-hosted domain controllers across an availability set. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Install Active Directory Domain Services on an Azure virtual machine](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/virtual-dc/adds-on-azure-vm) from Microsoft supports the following bounded statements: - AD DS can run on Azure virtual machines in the same manner as many on-premises deployments. The research record locates this support at Opening overview. - The documented example deploys two domain controllers in an Azure availability set using portal and CLI methods. The research record locates this support at Opening overview. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles and the conditions the source actually describes. ## What the source does not establish The page is a deployment example, not a complete production architecture or disaster-recovery design. No current deployment state or change approval follows from the source alone. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Opening overview. Favor directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Install Active Directory Domain Services on an Azure virtual machine](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/virtual-dc/adds-on-azure-vm) — Microsoft ## Primary reference - Name: Install Active Directory Domain Services on an Azure virtual machine - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/virtual-dc/adds-on-azure-vm - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Deploy Azure-hosted domain controllers across an availability set,” DSE Security, https://update.dsesecurity.com/updates/deploy-azure-domain-controllers-across-availability-set/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Deploy phishing-resistant authentication by user and device readiness > A reliable passkey and passwordless rollout starts with user personas, device and application compatibility, recoverable registration, pilot waves, and measured enforcement. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-entra-phishing-resistant-authentication-rollout/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:53+00:00 - Modified: 2026-07-19T21:27:53+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know A reliable passkey and passwordless rollout starts with user personas, device and application compatibility, recoverable registration, pilot waves, and measured enforcement. ## Potentially affected Microsoft Entra users, administrators, devices, applications, virtual desktops, remote-access workflows, and help desks moving from phishable credentials to passkeys, FIDO2 keys, Windows Hello for Business, or certificate authentication. ## DSE recommendation Map user-device readiness, give users a backup method, pilot credential registration, monitor support demand, and enforce phishing resistance through staged Conditional Access policies only after validation. ## Article ## Source fact: what Microsoft documents Microsoft recommends planning phishing-resistant passwordless authentication around user personas. Administrators, regulated users, people handling sensitive systems, and ordinary users can have different credential and recovery needs. Microsoft recommends broad adoption, but beginning with one persona and expanding through Microsoft Entra groups rather than enforcing every user at once. The current deployment guide lists minimum native-platform readiness of Windows 10 22H2 for Windows Hello for Business, Windows 11 22H2 for the best passkey experience, macOS 13, iOS 17, and Android 14. Older platforms may need an external FIDO2 key, smart card, or cross-device credential. Microsoft recommends that users have at least two registered authentication methods and describes a portable credential, such as a passkey or security key, plus local credentials on the devices they use. Microsoft documents Conditional Access authentication strengths as the primary enforcement mechanism and recommends platform-specific groups and policies. The guide also recommends monitoring registration, sign-ins, audit events, and help-desk volume; rollout should slow when support demand rises. ## Licensing and applicability Microsoft states that passkeys are available in all Microsoft Entra ID editions without an extra passkey license. Conditional Access enforcement generally requires eligible Microsoft Entra ID P1 or suite licensing. Verified ID identity proofing, Identity Protection, log export, and other optional components have separate licensing. Browser, application broker, operating system, VDI, RDP, third-party identity provider, security-key, Bluetooth, and mobile support varies. Preview tools must not be treated as required production dependencies. ## DSE recommendation: production-safe operational steps - Inventory users by persona and build a user-device-application matrix that includes administration, mobile, remote access, VDI, and recovery scenarios. - Select approved portable and local credential types, document hardware procurement and custody, and require a second usable authentication method. - Define identity-proofing and Temporary Access Pass issuance with independent verification, limited duration, least-privileged operators, and an audit trail. - Pilot registration with trained users on every supported platform. Test lost-device, replacement-device, new-hire, and locked-out-user recovery. - Review registration and sign-in logs, application failures, user feedback, and help-desk volume before enforcement. - Enforce phishing-resistant authentication in Conditional Access by ready user-device group. Preserve emergency access and a tested rollback path. - Expand one wave at a time and review dormant, duplicated, or lost credentials as part of the normal identity lifecycle. DSE recommends measuring successful registration and successful recovery separately. Enrollment success does not prove that every application or fallback workflow works. If a platform or critical application cannot use the intended method, document the supported alternative and owner instead of weakening the policy for the entire organization. ## Official references - [Plan a phishing-resistant passwordless authentication deployment](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication) — personas, device readiness, credential bootstrapping, monitoring, and enforcement waves. - [How to enable passkeys (FIDO2) in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkeys-fido2) — passkey availability, profiles, types, and enforcement configuration. ## Primary reference - Name: Microsoft Learn: Plan a phishing-resistant passwordless authentication deployment in Microsoft Entra ID - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication - Source publication date: 2026-03-26 ## Citation and use Preferred citation: “Deploy phishing-resistant authentication by user and device readiness,” DSE Security, https://update.dsesecurity.com/updates/microsoft-entra-phishing-resistant-authentication-rollout/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Deploy SMB over QUIC only after identity, port, and fallback testing > SMB over QUIC protects Windows file access with TLS 1.3 over UDP 443, but Windows clients can still prefer TCP and external authentication can fall back to NTLM. Prove transport, identity, certificates, and renewal before production. - Canonical URL: https://update.dsesecurity.com/updates/smb-over-quic-deployment-readiness/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:04:00+00:00 - Modified: 2026-08-11T14:48:24+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 4 minutes ## What you need to know SMB over QUIC protects Windows file access with TLS 1.3 over UDP 443, but Windows clients can still prefer TCP and external authentication can fall back to NTLM. Prove transport, identity, certificates, and renewal before production. ## Potentially affected Windows Server 2025 file servers; Windows Server 2022 Datacenter: Azure Edition; Windows 11 clients; Active Directory, KDC Proxy, PKI, DNS, firewalls, DFS, remote users, and file-service monitoring. ## DSE recommendation Select supported server and client builds, publish certificate-matching FQDNs, expose UDP 443 for SMB over QUIC without TCP 445, account for HTTPS/TCP 443 when KDC Proxy is used, force QUIC during testing, and rehearse certificate renewal and rollback. ## Article ## Source facts: encryption, transport selection, and identity are separate Microsoft’s [SMB over QUIC documentation](https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-over-quic) describes a TLS 1.3-protected tunnel that carries SMB over UDP 443 instead of TCP 445. Supported servers include Windows Server 2025 and Windows Server 2022 Datacenter: Azure Edition, with Windows 11 clients. The file-server administrator must opt in; a client cannot force a server that has not enabled the feature. Transport selection can hide a testing error. Windows SMB clients use TCP by default and try QUIC after TCP fails unless the connection explicitly requires QUIC with NET USE /TRANSPORT:QUIC or New-SmbMapping -TransportType QUIC. Microsoft says to permit inbound UDP 443 for the QUIC service and not expose inbound TCP 445 on the internet-facing file server. The server certificate needs Server Authentication, an appropriate key and signature, a private key, and a DNS subject alternative name for each fully qualified name clients use. Microsoft warns against IP-address SANs: they can force NTLM and do not work as the server name through Azure IaaS NAT in the described scenario. The published name must resolve correctly. Certificate renewal produces a new thumbprint and requires the SMB server certificate mapping to be updated. An external client normally lacks direct domain-controller access. Microsoft therefore describes NTLMv2 fallback inside the encrypted tunnel, while recommending Kerberos and the supported KDC Proxy design. SMB over QUIC itself uses UDP 443, while the KDC Proxy service is reached over HTTPS/TCP 443; the firewall and publishing design must account for both when KDC Proxy is used. The file server still needs access to a domain controller. The page also cautions that current DFS namespace behavior can return internal names that external clients cannot reach. ## DSE recommendation: prove the exact path before calling it remote file access - Draw both paths. Document the public FQDN, public and translated addresses, UDP 443 rules for SMB over QUIC, HTTPS/TCP 443 rules for KDC Proxy when used, server interface, share name, internal DNS, domain-controller path, certificate issuer, and management route. Show what must remain unreachable from the internet, especially TCP 445. - Validate names and certificates. Confirm that every approved client name is in the certificate SAN and resolves to the intended endpoint from internal and external networks. Record issuer trust, private-key protection, mapping thumbprint, expiration, renewal owner, and monitoring thresholds. - Force the pilot transport. Test with a command that requires QUIC, then confirm client connectivity event evidence rather than inferring the transport from a successful file open. Test again with the ordinary UNC behavior so the team understands when TCP is preferred and when QUIC is attempted. - Prove identity. Verify the expected user, group authorization, Kerberos ticket behavior when KDC Proxy is designed, and any NTLM event that remains. Test expired password, locked account, removed group membership, and a client that should be denied. - Exercise file semantics. Test create, read, modify, rename, delete, locks, large files, interrupted transfers, reconnect, roaming between networks, latency, and any line-of-business application that opens files directly. Confirm audit, malware protection, backup, quota, and recovery behavior at the server. - Rehearse renewal and failure. Replace a pilot certificate, update the thumbprint mapping, and verify continuity. Simulate blocked UDP, unavailable KDC Proxy, DNS error, and revoked access; monitoring should distinguish transport, certificate, identity, and storage failures. Use a named pilot population and restrict access to the smallest justified user and device set. Track forced-QUIC success, authentication method, certificate days remaining, blocked access, transfer failure, latency, NTLM exceptions, and help-desk contacts. Keep a tested disable procedure for the server and clients. SMB over QUIC can remove a broad VPN dependency for a defined file-service use case, but it does not remove the need for endpoint security, file authorization, backup, or an explicit identity design. Approve production only when operations can answer four questions from evidence: which transport carried the session, which identity protocol authenticated it, which certificate and name protected it, and which access rule authorized the share. Add those checks to incident intake so a remote-file complaint reaches the right owner without guesswork. ## Official references - Microsoft Learn, [SMB over QUIC](https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-over-quic), July 24, 2025; reviewed August 11, 2026. ## Primary reference - Name: Microsoft Learn: SMB over QUIC - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-over-quic - Source publication date: 2025-07-24 ## Citation and use Preferred citation: “Deploy SMB over QUIC only after identity, port, and fallback testing,” DSE Security, https://update.dsesecurity.com/updates/smb-over-quic-deployment-readiness/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Deploy the vulnerable driver blocklist through supported App Control > Use Microsoft recommended driver block rules to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/deploy-vulnerable-driver-blocklist-through-app-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:43+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Use Microsoft recommended driver block rules to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft recommended driver block rules ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Deploy the vulnerable driver blocklist through supported App Control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft recommended driver block rules](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules) from Microsoft supports the following bounded statements: - Attackers can exploit vulnerabilities in legitimate signed kernel drivers to run malicious code in the kernel. The research record locates this support at Opening overview. - Microsoft publishes a vulnerable-driver blocklist that can be applied with App Control mechanisms. The research record locates this support at Sections: Microsoft vulnerable driver blocklist; Blocking vulnerable drivers using App Control. Keep the evidence boundary at these traced claims. They support a review of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Audit hardware and software compatibility before enforcing updated driver blocks. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: Microsoft vulnerable driver blocklist; Blocking vulnerable drivers using App Control, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to Opening overview; Sections: Microsoft vulnerable driver blocklist; Blocking vulnerable drivers using App Control and to observable material such as policy and feature state, security events, test detections, administrative assignments, exception approvals, and response tickets. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Microsoft recommended driver block rules](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules) — Microsoft ## Primary reference - Name: Microsoft recommended driver block rules - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules - Source publication date: 2026-05-01 ## Citation and use Preferred citation: “Deploy the vulnerable driver blocklist through supported App Control,” DSE Security, https://update.dsesecurity.com/updates/deploy-vulnerable-driver-blocklist-through-app-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Deploy Windows LAPS through Intune without creating policy conflicts > Windows LAPS can rotate and escrow a unique local administrator password, but conflicting policies, the wrong backup directory, missing accounts, or excessive retrieval rights can leave the control ineffective. - Canonical URL: https://update.dsesecurity.com/updates/intune-windows-laps-conflict-safe-deployment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:53+00:00 - Modified: 2026-07-19T21:27:53+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Windows LAPS can rotate and escrow a unique local administrator password, but conflicting policies, the wrong backup directory, missing accounts, or excessive retrieval rights can leave the control ineffective. ## Potentially affected Windows devices managed with Microsoft Intune, including Microsoft Entra joined, hybrid joined, and appropriately domain-joined devices using a supported Windows LAPS backup directory. ## DSE recommendation Inventory existing LAPS authorities, assign one device-based policy, match backup location to join type, verify escrow and reporting, restrict password retrieval, and test manual rotation on a pilot. ## Article ## Source fact: what Microsoft documents Microsoft Intune manages Windows Local Administrator Password Solution through the Windows LAPS configuration service provider. Microsoft documents that CSP settings take precedence over and overwrite settings from other LAPS sources such as Group Policy or legacy Microsoft LAPS. Intune LAPS manages one local administrator account per device and does not create that account. If a named account does not exist, no account is managed; leaving the account name blank targets the built-in local administrator account identified by its well-known relative identifier. Microsoft recommends one LAPS policy per device and device-group assignments instead of user groups. Conflicting settings can stop processing or prevent the password from being backed up. The policy’s backup directory must be compatible with the device’s join type. A device can apply an incompatible configuration without an Intune policy error while Windows LAPS still fails to escrow the password. Retrieving a Microsoft Entra-escrowed password, scheduled rotation, and manual rotation produce audit events. Passwords backed up to on-premises Active Directory cannot be viewed from the Intune device pane. Manual rotation requires the documented Intune permissions and a successful prior backup. The action is available for Windows devices; for Microsoft Entra–joined devices, the device must be online when requested. Bulk rotation is not supported. ## Licensing and applicability Users or devices benefiting from Intune generally require applicable Intune licensing. Windows edition, update level, join type, tenant configuration, directory schema, role permissions, and the chosen escrow location affect support. Microsoft Entra and Intune roles should be limited to the minimum password-read, policy, and rotation rights needed. ## DSE recommendation: production-safe operational steps - Inventory legacy LAPS, Group Policy, CSP, scripts, local account names, join types, current password custody, and administrators who can retrieve credentials. - Confirm tenant and device prerequisites and choose Microsoft Entra ID or Active Directory escrow based on supported join state. - Create one pilot policy assigned to a device group. Ensure the intended local account already exists and is enabled only where required. - Verify policy success, actual password backup, last and next rotation dates, and the appropriate audit records before relying on the password. - Grant retrieval and rotation through least-privileged roles. Test that unauthorized staff cannot view the secret and that authorized retrieval is audited. - Test manual rotation on an online pilot, confirm the new password is escrowed, and document the effect on the next scheduled rotation. - Resolve every conflict before expanding. Monitor policy, device, retrieval, and rotation reports after each deployment wave. DSE recommends treating a retrieved password as a temporary sensitive secret. Record the business reason, rotate it after use, and investigate unexpected retrieval. Do not delete old policy sources until pilot reporting proves which authority is effective and rollback has been documented. ## Official references - [Deploy Windows LAPS policy with Microsoft Intune](https://learn.microsoft.com/en-us/intune/device-security/laps/deploy-policy) — policy behavior, precedence, assignment, escrow, retrieval, and rotation. - [Reports for LAPS policy in Intune](https://learn.microsoft.com/en-us/intune/device-security/laps/monitor) — policy status, conflicts, device detail, and audited events. - [Microsoft Intune licensing](https://learn.microsoft.com/en-us/intune/fundamentals/licensing) — general user, device, and administrator licensing boundaries. ## Primary reference - Name: Microsoft Learn: Deploy Windows LAPS policy with Microsoft Intune - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/intune/device-security/laps/deploy-policy - Source publication date: 2026-04-15 ## Citation and use Preferred citation: “Deploy Windows LAPS through Intune without creating policy conflicts,” DSE Security, https://update.dsesecurity.com/updates/intune-windows-laps-conflict-safe-deployment/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Deploy Windows NRPT rules as testable name-resolution policy > Use Configure DNSSEC rules using the Name Resolution Policy Table in Windows to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/deploy-windows-nrpt-rules-as-testable-name-resolution-policy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:32+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Configure DNSSEC rules using the Name Resolution Policy Table in Windows to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Configure DNSSEC rules using the Name Resolution Policy Table in Windows ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Deploy Windows NRPT rules as testable name-resolution policy. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Configure DNSSEC rules using the Name Resolution Policy Table in Windows](https://learn.microsoft.com/en-us/windows-server/networking/dns/name-resolution-policy-table) from Microsoft supports the following bounded statements: - Windows uses the Name Resolution Policy Table to apply DNSSEC-related name-resolution policy. The research record locates this support at Article introduction. - NRPT rules can be configured through Group Policy or PowerShell. The research record locates this support at Configure the NRPT; Group Policy and Windows PowerShell procedures. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish An NRPT rule does not sign a zone, guarantee validation by an upstream resolver, or prove compatibility for every client and namespace. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Article introduction, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Configure the NRPT; Group Policy and Windows PowerShell procedures, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from Article introduction; Configure the NRPT; Group Policy and Windows PowerShell procedures to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Configure DNSSEC rules using the Name Resolution Policy Table in Windows](https://learn.microsoft.com/en-us/windows-server/networking/dns/name-resolution-policy-table) — Microsoft ## Primary reference - Name: Configure DNSSEC rules using the Name Resolution Policy Table in Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/name-resolution-policy-table - Source publication date: 2025-08-01 ## Citation and use Preferred citation: “Deploy Windows NRPT rules as testable name-resolution policy,” DSE Security, https://update.dsesecurity.com/updates/deploy-windows-nrpt-rules-as-testable-name-resolution-policy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design anti-passback around sensors, topology, and recovery > Anti-passback depends on reliable door-position state, entry and exit topology, controller communication, and a method to correct occupancy state after exceptions. - Canonical URL: https://update.dsesecurity.com/updates/design-anti-passback-around-sensors-topology-and-recovery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:37+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Access Control, Business Continuity - Reading time: 3 minutes ## What you need to know Anti-passback depends on reliable door-position state, entry and exit topology, controller communication, and a method to correct occupancy state after exceptions. ## Potentially affected AXIS Camera Station Secure Entry deployments using anti-passback to limit credential sharing or enforce entry and exit sequence. ## DSE recommendation Model the complete movement zone, prove every sensor and reader path, document offline behavior, and establish an authorized state-reset and exception process. ## Article Bottom line: anti-passback is a state machine, not a reader checkbox. If the system misses an exit, accepts a door state incorrectly, or loses coordination across controllers, a valid user can be denied and the occupancy record can become unreliable. ## Source fact: the feature has explicit sensor and topology dependencies The [AXIS Camera Station Secure Entry User Manual](https://help.axis.com/en-us/axis-camera-station-secure-entry) documents anti-passback modes and configuration. It states that doors participating in anti-passback need door-position sensors. It describes hard, soft, and timed behavior and explains that some offline operation depends on the relevant doors being connected to the same controller. The manual also places conditions on a zero timeout, including reader coverage on both sides. These dependencies mean a logical area must match the physical route. An unmonitored emergency exit, propped door, elevator, gate, or door on another controller can change a person’s actual location without producing the transition that the anti-passback state expects. ## Source boundary and applicability The manual applies to compatible Axis products and documented versions. It does not establish that anti-passback is suitable for a life-safety, labor, occupancy, privacy, or high-security requirement. The feature does not prevent tailgating by itself and should not be treated as an authoritative people count. Fire and emergency egress must remain compliant. ## Applicability questions - What physical area and every legitimate entry, exit, transfer, and emergency route form the zone? - Are door-position sensors installed, supervised, aligned, and mapped correctly? - Are paired doors on one controller when offline behavior depends on it? - Should a violation deny access, log an exception, or clear after a defined time? - Who may reset a person’s state, for which reasons, and with what audit evidence? ## DSE recommendation: commission movement sequences and state repair The following steps are DSE recommendations based on the cited source. Draw the zone with readers, sensors, controllers, doors, gates, stairs, elevators, emergency exits, and alternate routes. Test correct entry and exit, repeated entry, repeated exit, tailgating observation, held and forced door, missed sensor transition, credential use at two points, controller offline state, server loss, and reconnection. Use test identities and an approved window so no person is trapped or denied required egress. Define hard, soft, or timed handling from the operational consequence. Create a least-privilege reset procedure that records identity, old state, corrected state, reason, approver, operator, and related incident. Reconcile state after evacuation or a broad emergency release. ## Verification and evidence Retain the zone drawing, version and controller topology, sensor tests, configuration export, sequence matrix, access and violation events, offline and recovery results, reset audit, emergency reconciliation procedure, and acceptance signatures. Re-test after route, reader, sensor, controller, timeout, or software changes. ## Official references - [AXIS Camera Station Secure Entry User Manual](https://help.axis.com/en-us/axis-camera-station-secure-entry) – Axis Communications ## Primary reference - Name: AXIS Camera Station Secure Entry User Manual - Authority: Axis Communications - URL: https://help.axis.com/en-us/axis-camera-station-secure-entry - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Design anti-passback around sensors, topology, and recovery,” DSE Security, https://update.dsesecurity.com/updates/design-anti-passback-around-sensors-topology-and-recovery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design Azure Private Endpoint DNS before the first private link > An approved Azure Private Endpoint can still fail when clients resolve the public address or a private zone returns NXDOMAIN. Design service-specific zones, VNet links, hybrid forwarding, fallback, ownership, and tests before deployment. - Canonical URL: https://update.dsesecurity.com/updates/azure-private-endpoint-dns-design/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:57:00+00:00 - Modified: 2026-08-11T14:48:24+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know An approved Azure Private Endpoint can still fail when clients resolve the public address or a private zone returns NXDOMAIN. Design service-specific zones, VNet links, hybrid forwarding, fallback, ownership, and tests before deployment. ## Potentially affected Azure Private Endpoints and Private Link services; Azure Private DNS zones and VNet links; Azure DNS Private Resolver or DNS forwarders; hub-spoke, VPN, ExpressRoute, on-premises, and multicloud clients; application connection strings. ## DSE recommendation Map each service FQDN and recommended private zone, define authoritative zones and VNet links, route hybrid queries through an Azure-reachable resolver, decide NXDOMAIN fallback deliberately, and test resolution from every client boundary. ## Article ## Source facts: the application name stays familiar while DNS changes its answer Microsoft’s [Private Endpoint DNS guidance](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns) says the endpoint network interface contains the private IP and fully qualified domain-name information needed for name resolution. Azure public DNS publishes a CNAME that redirects the ordinary service name toward a privatelink namespace. Inside the intended private network, DNS must override that chain with the endpoint’s private address so applications can continue using the normal connection URL. Microsoft lists recommended private DNS zone names by Azure service and subresource. Automatic private DNS integration depends on using those recommended names. A private zone can be linked to virtual networks, while Azure DNS Private Resolver or a DNS-forwarder design can make linked private-zone answers available to on-premises or other connected clients. The private namespace can also create a negative-answer trap. When a client queries a name for which the linked private zone has no record, the zone can return NXDOMAIN instead of continuing to the public answer. Microsoft documents an optional “fallback to internet” resolution policy on eligible Private Link zone VNet links. When enabled, Azure’s resolver retries public recursion after an authoritative NXDOMAIN. A static public A record in the private zone is not recommended because the service’s public address can change. DNS and access control remain separate. A publicly resolvable CNAME does not reveal the private address or grant data-plane access, and disabling public network access can still reject a caller. Conversely, an endpoint marked Approved does not ensure the client received the private DNS answer or has a working route to it. ## DSE recommendation: make DNS a required design artifact For each private endpoint, document the public application FQDN, CNAME chain, Azure service and subresource, recommended private zone, expected A record, endpoint and VNet, every linked client VNet, hybrid resolver path, forwarding rule, public-access posture, owner, and recovery method. Treat this map as part of the application architecture, not a network-team attachment created after failure. - Define authority centrally. Decide which platform boundary owns each privatelink zone and record lifecycle. Reuse a governed zone for like service endpoints where the Microsoft guidance supports it; prevent application deployments from creating competing zones that different VNets see inconsistently. - Link only intended networks. Verify zone links against the client inventory and hub-spoke design. Remember that peering provides connectivity but does not automatically make a VNet authoritative for another VNet’s private zone. - Design hybrid forwarding. Point on-premises or multicloud DNS to an Azure DNS Private Resolver inbound endpoint or supported forwarder inside Azure. Do not point an external resolver directly at Azure’s platform virtual address, which is reachable only inside a VNet. - Choose fallback explicitly. Determine whether clients in a linked network must also reach public instances of the same Azure service namespace. If so, evaluate the documented NXDOMAIN fallback policy and its access implications. Avoid unmanaged duplicate public records. - Test from every boundary. Resolve the ordinary application FQDN from each VNet, on-premises site, VPN user path, build runner, and recovery network. Capture the complete CNAME chain and final IP, then test route, port, TLS name, service authorization, and the expected denial of public access. - Exercise lifecycle events. Test endpoint replacement, record deletion and recreation, zone-link change, resolver failure, regional recovery, cache expiry, and rollback. Monitoring should distinguish DNS failure, public-answer leakage, route failure, and service authorization. Track endpoints without expected records, zones without owners, missing or excessive VNet links, NXDOMAIN and SERVFAIL trends, public answers where private is required, resolver health, and stale endpoint records. A sound design produces the right answer consistently and can explain why that answer changes by client location. ## Official references - Microsoft Learn, [Azure Private Endpoint private DNS zone values](https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns), August 10, 2026. - Microsoft Learn, [Fallback to internet for Azure Private DNS zones](https://learn.microsoft.com/en-us/azure/dns/private-dns-fallback). - Microsoft Learn, [Troubleshoot private endpoint DNS resolution failure in Azure Private Link](https://learn.microsoft.com/en-us/troubleshoot/azure/private-link/troubleshoot-private-endpoint-dns-resolution). ## Primary reference - Name: Microsoft Learn: Azure Private Endpoint private DNS zone values - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns - Source publication date: 2026-08-10 ## Citation and use Preferred citation: “Design Azure Private Endpoint DNS before the first private link,” DSE Security, https://update.dsesecurity.com/updates/azure-private-endpoint-dns-design/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design camera coverage from the task—not the megapixel count > Detection, observation, recognition, and identification require different image detail. Define the task and target distance first, use pixel density as a planning aid, then prove the recorded result in the real scene. - Canonical URL: https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:45:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Advisory - Topics: Video Surveillance - Reading time: 3 minutes ## What you need to know Detection, observation, recognition, and identification require different image detail. Define the task and target distance first, use pixel density as a planning aid, then prove the recorded result in the real scene. ## Potentially affected Fixed, panoramic, multisensor, and PTZ surveillance cameras; lenses; VMS recording profiles; operator displays; sites planning new coverage or changing layouts. ## DSE recommendation Assign an operational requirement and test point to every important view, validate pixel density at the target plane, and accept the camera only after recorded images work under representative lighting, motion, compression, and display conditions. ## Article ## Source facts: DORI is a planning model, not a result Axis Communications’ [Pixel density and DORI](https://www.axis.com/dam/public/b2/d9/29/pixel-density-en-US-403691.pdf) white paper describes four common operational requirements for video interpreted by people: detection, observation, recognition, and identification. In the paper, detection means determining whether a person is present; observation adds characteristic detail; recognition supports deciding whether someone is the same person seen before; and identification requires enough information to identify the person. The paper relates those tasks to a pixel-density model derived from IEC 62676-4. Its planning values are 25 pixels per meter for detection, 63 px/m for observation, 125 px/m for recognition, and 250 px/m for identification. The same paper warns that this is a simplified model. Lighting direction, optics, compression, distance, pose, scene geometry, and the resolution of the display used by an operator can change the practical result. The values apply to visual images interpreted by people; analytics and thermal imaging need their own performance definitions. Pixel density also changes across a scene. A person farther from the lens occupies fewer pixels than one near it, while a wide overview spreads the sensor’s pixels across more space. A high sensor resolution therefore does not automatically create identification coverage everywhere in the image. The source describes planning and validation tools, including site design, lens calculation, and an on-camera pixel counter, but none replaces a real-scene acceptance test. ## DSE recommendation: turn each view into a testable requirement Start with the decision the video must support, not a camera model. Mark the exact line, doorway, counter, lane, or area where the task matters and assign one intended result: detect, observe, recognize, or identify. Record the expected target direction, distance band, lighting, movement, and viewing method. A parking-lot overview and an identification view at an employee entrance are different requirements even when one camera can see both. - Map the target plane. Put the required coverage line on a drawing or reference image. Measure the near and far distances and identify obstructions, seasonal foliage, door swing, merchandise, parked vehicles, and future layout changes. - Calculate before installation. Use the intended camera, lens, aspect ratio, and stream resolution to estimate pixel density at the target. Preserve the calculation or design export with the project record. Treat it as a design assumption, not acceptance evidence. - Protect the recording path. Confirm that the VMS records the resolution, crop, frame rate, and compression profile used in the calculation. A high-quality live view does not prove that recorded playback or export preserves the same detail. - Test people and objects at the marked points. Use authorized test participants and representative clothing, movement, direction, and speed. Test the center and edges of the image, not only the easiest position. - Exercise difficult conditions. Repeat at daylight, darkness, backlight, artificial-light transitions, and other conditions material to the site. Review motion blur, noise, focus, reflections, headwear, and the effect of compression during scene activity. - Review on the real workstation. Have the intended operator retrieve and display recorded footage through the normal client, monitor, network path, and export workflow. Document whether the assigned task was achieved without relying on digital zoom to manufacture missing detail. When one view must provide both overview and identification, make both requirements explicit. The answer may be a narrower lens, a second camera, a multidirectional device, or a dedicated identification view. Do not silently downgrade the requirement because a broad field of view looks impressive on a wall monitor. Keep an acceptance image for every critical test point, along with camera model, lens position, stream settings, date, lighting condition, result, exception, and approver. Revalidate after a camera is moved, refocused, replaced, re-encoded, or obstructed, and after a material change to the scene. The durable outcome is not “eight megapixels installed”; it is a recorded image that performs the defined job at the defined place. ## Official reference - Axis Communications, [Pixel density and DORI: Meeting operational requirements in network video](https://www.axis.com/dam/public/b2/d9/29/pixel-density-en-US-403691.pdf), May 2023. ## Primary reference - Name: Axis Communications: Pixel density and DORI—Meeting operational requirements in network video - Authority: Axis Communications - URL: https://www.axis.com/dam/public/b2/d9/29/pixel-density-en-US-403691.pdf - Source publication date: 2023-05-01 ## Citation and use Preferred citation: “Design camera coverage from the task—not the megapixel count,” DSE Security, https://update.dsesecurity.com/updates/design-camera-coverage-from-dori-operational-task/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design Certificate Enrollment Web Service for off-domain clients > Use Certificate Enrollment Web Service overview to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/design-certificate-enrollment-web-service-for-off-domain-clients/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:13+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Certificate Enrollment Web Service overview to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Certificate Enrollment Web Service overview ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Design Certificate Enrollment Web Service for off-domain clients. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Certificate Enrollment Web Service overview](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-enrollment-web-service) from Microsoft supports the following bounded statements: - Certificate Enrollment Web Service accepts enrollment over HTTPS for users and computers. The research record locates this support at Opening overview. - Together with the policy service, it supports policy-based enrollment for non-domain or temporarily disconnected domain clients. The research record locates this support at Opening overview. Only the traced statements above are asserted as source facts. Apply the review to certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles after confirming that the source and deployed context match. ## What the source does not establish Authentication type, delegation, CA connectivity, and load balancing must be designed together. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles are in and out of scope? - Which condition in Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities and sanitize protected material before retention. ## Verification and evidence Keep the source locations Opening overview; Opening overview adjacent to the sanitized artifacts used for comparison. Prefer CA and template exports, enrollment tests, certificate chains, access-control entries, event logs, and revocation-path checks, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Certificate Enrollment Web Service overview](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-enrollment-web-service) — Microsoft ## Primary reference - Name: Certificate Enrollment Web Service overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-enrollment-web-service - Source publication date: 2025-03-28 ## Citation and use Preferred citation: “Design Certificate Enrollment Web Service for off-domain clients,” DSE Security, https://update.dsesecurity.com/updates/design-certificate-enrollment-web-service-for-off-domain-clients/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design cloud forensic readiness before evidence is needed > Cloud investigators depend on provider capabilities, customer configuration, jurisdiction, interfaces, time, and retention that cannot be improvised after an incident. Map evidence needs to cloud capabilities and mitigate gaps before collection becomes urgent. - Canonical URL: https://update.dsesecurity.com/updates/design-cloud-forensic-readiness-before-evidence-is-needed/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:39:00+00:00 - Modified: 2026-08-11T15:22:46+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Cloud investigators depend on provider capabilities, customer configuration, jurisdiction, interfaces, time, and retention that cannot be improvised after an incident. Map evidence needs to cloud capabilities and mitigate gaps before collection becomes urgent. ## Potentially affected Cloud accounts and workloads, software-as-a-service data, identity and audit records, incident responders, legal and privacy teams, providers, contracts, retention settings, evidence pipelines, and recovery decisions. ## DSE recommendation Choose a cloud service, map likely investigations and evidence to responsible parties and capabilities, test collection and preservation, document gaps, and add forensic requirements to architecture and supplier governance. ## Article ## Source facts: cloud forensics depends on architecture and shared responsibility NIST Special Publication 800-201 presents a Cloud Computing Forensic Reference Architecture intended to support forensic readiness. It gives organizations a methodology for relating cloud forensic challenges to cloud capabilities and identifying where mitigation may be required before or during an investigation. NIST describes the published mapping as an initial implementation that users should customize for their situations. Cloud investigations can involve consumers, providers, brokers, carriers, auditors, and other parties across software, platform, and infrastructure service models. Evidence may be distributed, virtualized, multi-tenant, elastic, short-lived, remotely administered, or held in provider systems the consumer cannot directly access. Location, jurisdiction, synchronization, provenance, identity, interfaces, retention, and provider cooperation can affect collection and interpretation. The reference architecture does not promise that every forensic challenge can be eliminated. It helps users determine which capabilities are affected, whether a challenge applies, and where partial mitigation can reduce investigative risk. Readiness therefore includes technical design, operations, governance, contracts, and an understood investigative process. ## DSE recommendation: start from questions an investigation must answer Select a cloud-hosted business service and develop credible cases: compromised identity, destructive administration, data extraction, malicious automation, supplier access, workload intrusion, configuration change, or disputed transaction. For each case, list the decisions responders must make and the evidence needed to support them. Include identity, control-plane actions, workload activity, network context, data access, configuration history, time, and custody. Map each evidence type to its creator, owner, storage location, format, clock, retention, access path, cost, and collection authority. Identify whether the organization, provider, or another party can preserve and export it. Do not label a log “available” until a qualified person has retrieved a representative event with the fields and time range required. ## DSE recommendation: mitigate gaps across the service life cycle - Architect for evidence. Enable appropriate audit and data-access records, protect log destinations from workload administrators, preserve identity context, synchronize time, and capture ephemeral resource metadata before it disappears. - Govern retention. Set periods from detection delay, investigation needs, legal and privacy requirements, cost, and business risk. Monitor configuration drift and ingestion failure. - Write provider duties. Address preservation requests, response times, available artifacts, formats, provenance, subcontractors, jurisdiction, notification, secure transfer, costs, and support at contract termination. - Prepare collection. Approve tools, roles, credentials, secure storage, hashing or other integrity methods, chain-of-custody records, and decision authority. Keep an out-of-band path if the normal identity service is suspect. - Connect forensics to recovery. Define who may isolate, snapshot, suspend deletion, rebuild, or restore and what evidence must be captured first. Avoid destroying the only useful state through automatic remediation. ## DSE recommendation: exercise the real interfaces Run a timed exercise using the production service’s supported export, application programming interface, provider request process, and retention. Ask an investigator unfamiliar with the deployment to reconstruct a sequence across identity, control plane, workload, and data events. Test clock alignment, account attribution, completeness, integrity, transfer, and access when a primary administrator is unavailable. Record unavailable evidence, ambiguous fields, provider delays, undocumented costs, privilege barriers, and destructive collection steps. Assign each gap an owner, mitigation, residual risk, and review date. Revisit the mapping after provider, service model, region, architecture, retention, or contract changes. Store collection instructions outside the investigated environment and verify that emergency responders can reach them with alternate credentials. Test that the retained instructions still match the provider interface and that emergency access produces an auditable collection record. Cloud forensic readiness is achieved when the organization knows what evidence it can obtain, how quickly, through whose authority, with what limitations, and how to preserve it without guessing during an incident. ## Official references - National Institute of Standards and Technology, [SP 800-201: NIST Cloud Computing Forensic Reference Architecture](https://csrc.nist.gov/pubs/sp/800/201/final), July 30, 2024; reviewed August 11, 2026. ## Primary reference - Name: NIST SP 800-201: Cloud Computing Forensic Reference Architecture - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/201/final - Source publication date: 2024-07-30 ## Citation and use Preferred citation: “Design cloud forensic readiness before evidence is needed,” DSE Security, https://update.dsesecurity.com/updates/design-cloud-forensic-readiness-before-evidence-is-needed/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design cross-tenant access settings before B2B collaboration scales > Microsoft Entra cross-tenant access settings govern inbound and outbound B2B relationships and trust in external MFA or device claims. Inventory real partners, defaults, applications, and lifecycle before broad collaboration becomes the policy. - Canonical URL: https://update.dsesecurity.com/updates/design-cross-tenant-access-settings-before-b2b-scales/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:04:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Microsoft Entra cross-tenant access settings govern inbound and outbound B2B relationships and trust in external MFA or device claims. Inventory real partners, defaults, applications, and lifecycle before broad collaboration becomes the policy. ## Potentially affected Microsoft Entra workforce tenants, External ID and B2B collaboration, default and organization-specific cross-tenant settings, inbound and outbound users, groups and applications, MFA and device-claim trust, SharePoint and Teams collaboration, invitations, guests, and audit logs. ## DSE recommendation Discover existing partner tenants and access, define conservative default inbound and outbound behavior, create documented organization-specific settings only for approved relationships, test invitations and resource access, monitor trust and lifecycle, and review both sides on a schedule. ## Article ## Source facts: cross-tenant access has inbound, outbound, and trust decisions Microsoft’s [B2B cross-tenant access documentation](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settings-b2b-collaboration) explains that settings control how users in external Microsoft Entra organizations access applications in your tenant and how your users access applications in external organizations. Administrators can configure defaults and organization-specific inbound and outbound settings and can decide whether to trust MFA, compliant-device, or hybrid-joined-device claims from another Entra organization. Microsoft’s [governed B2B collaboration architecture](https://learn.microsoft.com/en-us/entra/architecture/5-secure-access-b2b) recommends identifying collaboration partners and using controls including external collaboration settings, cross-tenant access settings, and entitlement management. It notes that one partner can have multiple domains and domains can change, which makes a simple email-domain list an incomplete model of the relationship. Cross-tenant settings do not replace application authorization, Conditional Access, guest lifecycle, data-sharing controls, terms of use, or contractual review. Some collaboration modes require reciprocal configuration, and behavior varies by tenant type, Microsoft cloud, application, and license. Trusting an external claim means relying on another tenant’s relevant control; it is not Microsoft attesting that the partner’s whole security program meets yours. ## DSE recommendation: make each tenant relationship an owned security object Inventory current B2B reality before changing the defaults. Identify external tenant IDs, guest objects, invitations, sign-ins, resources accessed, Teams shared channels, SharePoint sharing, cross-tenant synchronization, access packages, partner owners, internal sponsors, and contractual purpose. Separate verified tenant relationships from unredeemed, orphaned, consumer, and unknown identities. - Set a deliberate default. Decide what any organization without a specific rule may do inbound and what your users may do outbound. Test the business effect before tightening; default changes can affect many relationships that nobody documented. - Identify the partner by tenant. Verify the tenant ID through an approved business contact and record legal entity, sponsor, purpose, users or groups, applications, data classes, start, review, and end dates. Do not infer trust solely from a familiar domain or display name. - Scope both directions. Select only required external users, groups, and applications for inbound access and required internal users, groups, and external applications for outbound access. A narrowly scoped collaboration project should not silently become tenant-wide access. - Decide claim trust explicitly. If accepting a partner’s MFA or device claims, document why its assurance and lifecycle are sufficient, how exceptions are handled, and who reviews the decision. Otherwise require controls in your own resource tenant as supported. - Test the complete journey. Exercise invitation, redemption, sign-in, Conditional Access, resource authorization, sharing, mobile and browser access, access review, revocation, and re-invitation. Include a user who changes employer or home-tenant identity and an application outside the approved scope. - Monitor and exit. Alert on organization-setting changes, trust changes, unusual guest sign-ins, new high-value resource access, and stale guests. At relationship end, remove access, synchronization and invitations as appropriate, preserve required records, and verify the resource no longer grants access. Maintain separate owners for the business relationship, external identity configuration, application, and shared data. Require coordinated review when either tenant merges, rebrands, changes domains, changes its authentication program, or transfers the application. Reciprocal settings should be compared, not assumed to match. Document effective defaults and organization-specific exceptions in plain language so a reviewer can answer who trusts whom, for what, and until when. The goal is not to block collaboration; it is to keep collaboration from expanding beyond an identified partner, approved resource, sufficient proof, and managed lifecycle. Use release criteria for each relationship: verified tenant ID, named sponsors on both sides, least-privilege user and application scope, an explicit claim-trust decision, successful revocation test, and a dated exit owner. Stop deployment if the partner cannot verify its tenant, required access cannot be scoped, or test users reach an unapproved resource. Business urgency does not convert an unidentified trust boundary into an acceptable one. ## Official references - Microsoft, [Manage cross-tenant access settings for B2B collaboration](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settings-b2b-collaboration). - Microsoft, [Transition to governed collaboration with Microsoft Entra B2B collaboration](https://learn.microsoft.com/en-us/entra/architecture/5-secure-access-b2b). ## Primary reference - Name: Microsoft Learn: Manage cross-tenant access settings for B2B collaboration - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settings-b2b-collaboration - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Design cross-tenant access settings before B2B collaboration scales,” DSE Security, https://update.dsesecurity.com/updates/design-cross-tenant-access-settings-before-b2b-scales/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design cyber recovery playbooks around prioritized services and tested evidence > Cyber recovery requires prioritized resources, service-specific playbooks, realistic testing, measurable outcomes, and continuous improvement—not merely a successful backup job. - Canonical URL: https://update.dsesecurity.com/updates/cybersecurity-event-recovery-playbooks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:26:27+00:00 - Modified: 2026-07-19T21:26:27+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 2 minutes ## What you need to know Cyber recovery requires prioritized resources, service-specific playbooks, realistic testing, measurable outcomes, and continuous improvement—not merely a successful backup job. ## Potentially affected Organizations whose essential services depend on information systems, cloud services, identities, data, providers, facilities, communications, or specialized personnel. ## DSE recommendation Prioritize services and dependencies, document recovery playbooks and validation criteria, run realistic exercises, and improve them using measured results and lessons learned. ## Article A backup can be intact while the organization remains unable to operate. Cyber recovery must restore a trustworthy business service, including the identities, data, systems, networks, providers, people, and decisions that service requires. ## What NIST says recovery planning needs Source fact: NIST SP 800-184 recommends incorporating cybersecurity-event recovery into organizational risk management. NIST explains that identifying and prioritizing organizational resources supports effective plans and realistic test scenarios, helping an organization recover more rapidly and reduce impact. Source fact: The publication covers strategic and tactical recovery planning, playbook development, testing, improvement, and example metrics. It also recommends learning from the organization’s own events and relevant events experienced by others. Recovery is therefore a maintained capability, not a one-time document. ## Start with a service and its dependencies DSE recommendation: choose an essential service and identify what must be available and trustworthy for it to operate. Include business owners, operators, identity and administrative paths, applications, infrastructure, data, encryption keys, monitoring, network services, facilities, suppliers, communications, and manual alternatives. Then create a bounded recovery playbook: - State the activation conditions, decision authority, recovery objective, dependencies, assumptions, and known unsafe actions. - Define containment and evidence-preservation prerequisites before rebuilding or reconnecting technology. - Record the recovery sequence, responsible roles, trusted sources, credentials, clean tools, provider contacts, and alternate communication method. - Specify validation for data integrity, identity, security configuration, monitoring, business transactions, and downstream integrations. - Define who accepts residual risk and authorizes return to production. ## Test more than restoration speed DSE recommendation: exercise partial and widespread scenarios, including unavailable identity, unreachable staff, damaged configuration, a compromised administrator, or a supplier outage. Record decision delays, unavailable prerequisites, data outcomes, failed dependencies, validation defects, actual recovery time, and the point at which the service owner accepted operation. A test that restores files but does not prove the essential transaction, monitoring, access controls, and integrity is incomplete. Retest corrective work rather than closing a finding because a document was updated. ## Applicability and limits SP 800-184 was published in 2016. Its planning principles remain useful, but technology examples and implementation details must be reconciled with current vendor documentation, cloud responsibilities, architecture, and obligations. The source does not assign a universal recovery time or guarantee that a playbook will work. Business owners must approve priorities and acceptable operating conditions. ## Official reference [NIST SP 800-184](https://csrc.nist.gov/pubs/sp/800/184/final) — strategic and tactical guidance for cybersecurity-event recovery. ## Primary reference - Name: NIST SP 800-184: Guide for Cybersecurity Event Recovery - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/184/final - Source publication date: 2016-12-22 ## Citation and use Preferred citation: “Design cyber recovery playbooks around prioritized services and tested evidence,” DSE Security, https://update.dsesecurity.com/updates/cybersecurity-event-recovery-playbooks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design cyber tabletops that force real decisions > A useful cyber tabletop tests who decides, with what evidence, while technology and third parties fail. Build objectives around decisions, inject dependency loss, observe communications, and retest corrective actions. - Canonical URL: https://update.dsesecurity.com/updates/design-cyber-tabletops-that-force-real-decisions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know A useful cyber tabletop tests who decides, with what evidence, while technology and third parties fail. Build objectives around decisions, inject dependency loss, observe communications, and retest corrective actions. ## Potentially affected Executives, incident commanders, IT and security teams, legal, communications, privacy, business operations, facilities, human resources, and critical suppliers. ## DSE recommendation Define decision-centered objectives, exercise degraded dependencies and communications, capture observable performance, and assign every improvement an owner, due date, and retest method. ## Article ## Source fact: a tabletop is an evaluated discussion, not a narrated incident NIST describes tabletop exercises as discussion-based events in which a facilitator presents a scenario and prompts participants to explain decisions and actions. Its [SP 800-84 exercise guidance](https://csrc.nist.gov/pubs/sp/800/84/final) includes facilitators, data collectors, participant debriefs, after-action reporting, and updates to plans. CISA’s [Cybersecurity Tabletop Exercise Package documents](https://www.cisa.gov/resources-tools/resources/ctep-package-documents) likewise provide planner, facilitator, evaluator, participant, feedback, and after-action materials. These roles matter because conversation alone does not show whether an organization can make a timely, authorized decision under pressure. FEMA’s [Homeland Security Exercise and Evaluation Program resources](https://preptoolkit.fema.gov/web/hseep-resources) provide a common approach to design, conduct, evaluation, and improvement planning. Objectives and data collection are established before the exercise; corrective actions are then monitored. The official methods support a cycle, not a one-day event. ## DSE recommendation: write objectives as decisions DSE recommendation: give each objective a decision, condition, responsible role, evidence expected, and observable result. For example: determine whether the incident commander can authorize isolation of a revenue service when identity systems are unreliable, identify what evidence is required, and observe how that decision reaches operators and business leadership. This extends DSE’s existing incident-plan and continuity articles by testing the plan’s decision mechanics. Limit the number of objectives so evaluators can collect evidence. Good objectives can examine declaration authority, legal or regulatory escalation, customer communications, containment tradeoffs, restoration priority, supplier coordination, or executive risk acceptance. A broad goal such as testing readiness is too vague to evaluate consistently. ## Build a scenario around dependencies - Start with a credible service impact. Use a threat only to create the conditions needed for the objectives. CISA provides [cybersecurity scenarios](https://www.cisa.gov/resources-tools/resources/cybersecurity-scenarios) covering several incident types, but local systems, authorities, and dependencies must be added. - Map the dependency chain. Include identity, email, chat, telephony, cloud administration, network access, backups, physical access, managed service providers, legal counsel, insurers, public information channels, and critical suppliers as relevant. - Write timed injects. Remove or degrade selected dependencies; introduce conflicting evidence, executive unavailability, supplier delay, media inquiry, or safety concern. Each inject should serve an objective rather than surprise participants for entertainment. - Define exercise boundaries. State which systems are simulated, which real contacts must not be called, how a participant requests missing information, and when facilitators may advance time. Keep artificialities separate from performance findings. ## Put the right people in the room Invite roles that own decisions and carry them out: incident command, service and business owners, IT, security, communications, legal, privacy, human resources, facilities, finance, and suppliers where the objectives require them. Provide role cards with authority, not scripted answers. An executive substitute should possess the authority the real plan expects; otherwise the exercise tests an organizational absence rather than the intended decision. Evaluators should capture timestamps, evidence requested, assumptions made, decision owner, consulted parties, channel used, handoffs, and whether an action was confirmed. They should distinguish a documented capability from a participant’s belief that someone could do it. Facilitators can ask what happens next, who has authority, how that person is reached, and what changes if the normal tool is untrusted. ## Turn observations into tested change CISA’s [Facilitator and Evaluator Handbook](https://www.cisa.gov/sites/default/files/publications/3%20-%20CTEP%20Facilitator%20Evaluator%20Handbook%20%282020%29%20FINAL_508_2.pdf) connects observations to an after-action report and improvement plan. Hold a hotwash promptly, but validate impressions against evaluator notes and artifacts. Describe the observed condition, risk, corrective action, owner, due date, dependencies, and evidence of completion. Avoid naming an individual as the cause when the issue is unclear authority, missing access, or an unusable process. Close the loop with a focused retest: a communications drill, restoration demonstration, approval walkthrough, supplier call-tree test, or another tabletop inject. Counting participants or completed exercises is an activity metric. The stronger measure is whether previously failed decisions and dependencies work when tested again. ## Official sources - [CISA: Cybersecurity Tabletop Exercise Package Documents](https://www.cisa.gov/resources-tools/resources/ctep-package-documents) - [CISA: Cybersecurity Scenarios](https://www.cisa.gov/resources-tools/resources/cybersecurity-scenarios) - [CISA: CTEP Facilitator and Evaluator Handbook](https://www.cisa.gov/sites/default/files/publications/3%20-%20CTEP%20Facilitator%20Evaluator%20Handbook%20%282020%29%20FINAL_508_2.pdf) - [FEMA: HSEEP Resources](https://preptoolkit.fema.gov/web/hseep-resources) - [NIST: SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities](https://csrc.nist.gov/pubs/sp/800/84/final) ## Primary reference - Name: CISA Cybersecurity Tabletop Exercise Packages - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/resources-tools/resources/ctep-package-documents - Source publication date: 2023-02-02 ## Citation and use Preferred citation: “Design cyber tabletops that force real decisions,” DSE Security, https://update.dsesecurity.com/updates/design-cyber-tabletops-that-force-real-decisions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design multicast video with controlled group membership and tested fallback > Multicast can reduce duplicate video streams, but missing queriers, uncontrolled flooding, inconsistent IGMP behavior, routing boundaries, or silent failback can turn efficiency into an outage. Engineer and test the entire group path. - Canonical URL: https://update.dsesecurity.com/updates/design-multicast-video-with-controlled-membership-and-fallback/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:13:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know Multicast can reduce duplicate video streams, but missing queriers, uncontrolled flooding, inconsistent IGMP behavior, routing boundaries, or silent failback can turn efficiency into an outage. Engineer and test the entire group path. ## Potentially affected Multicast-capable cameras and encoders, operator clients, video walls, VMS services, Layer 2 switches, routed networks, IGMP snooping and queriers, VLANs, ACLs, wireless links, monitoring, and unicast fallback. ## DSE recommendation Map every multicast source, group, receiver, VLAN, router, and querier; constrain forwarding; validate joins, leaves, failover, and recovery under realistic load; monitor group state; and document a capacity-tested unicast fallback. ## Article ## Source facts: multicast forwarding depends on group-control behavior [RFC 4541](https://www.rfc-editor.org/rfc/rfc4541.html) gives implementation considerations for switches that snoop Internet Group Management Protocol and Multicast Listener Discovery traffic. It distinguishes the control path from multicast-data forwarding and describes how a snooping switch learns membership and multicast-router ports. It is an Informational RFC, not an Internet Standard and not a certification of any switch implementation. [RFC 3376](https://www.rfc-editor.org/rfc/rfc3376.html) specifies IGMP version 3, including host reports, membership queries, and source filtering. Real networks can contain different IGMP versions, static groups, queriers, routers, redundant paths, and devices with vendor-specific behavior. Snooping without a functioning query process can leave membership state stale or allow it to age out. Flooding or filtering behavior also varies during startup and topology change. Multicast does not provide confidentiality, authorization, delivery guarantees, or automatic redundancy. An allowed receiver may still fail to decode a stream, and a network may forward a stream to unintended ports if group controls are absent or misconfigured. Product documentation, supported topology, and the organization’s security requirements govern a specific deployment. ## DSE recommendation: document the control plane before enabling the stream Create a multicast register for every production video group. Record the source camera or service, source address, group address, port, bitrate, codec, intended receivers, VLAN, routed boundaries, IGMP version, querier, multicast-routing owner, switch policy, security rule, and unicast alternative. Reserve addresses through the network team; do not let installers choose groups ad hoc. - Establish ownership. Name the authoritative querier or multicast router for each VLAN and the redundant behavior if it disappears. Confirm that switch snooping, querier election, routing, and receiver versions are a supported combination. - Constrain the path. Keep camera networks segmented, limit routed multicast to required interfaces, and use supported filters or access controls. Validate that ordinary user, guest, wireless, voice, and building-device ports do not receive the stream unless explicitly required. - Calculate capacity. Measure each stream during demanding scenes and calculate expected load on camera uplinks, trunks, routed links, receivers, and any fallback server. Include simultaneous operator layouts, video walls, recording traffic, and maintenance overhead. - Test membership transitions. Observe a receiver joining, changing channels, leaving, sleeping, roaming, and reconnecting. Restart the receiver and source separately. Verify switch group tables and confirm traffic stops on ports with no members within the expected interval. - Exercise failures. Under an approved change, fail the querier, a redundant link, a switch, the stream source, and a routed boundary one at a time. Measure video interruption, group relearning, convergence, alarm visibility, and whether traffic floods while state is rebuilt. - Prove fallback. If the design changes clients to unicast when multicast fails, verify the trigger, user behavior, stream quality, server capacity, network capacity, and return to multicast. A fallback that overloads the recorder or WAN is not a fallback. Monitor both experience and state. Useful signals include source reachability, multicast bitrate by interface, unexpected receivers, group-table population, querier changes, interface errors, packet loss, client decode errors, and unicast-fallback volume. Alerting on a camera ping alone misses a broken group path. Keep a rollback for switch and VMS changes, and retest after VLAN, redundancy, firmware, routing, or receiver updates. The acceptance result should identify the tested topology and load; it should not promise identical behavior in another network. Multicast earns its place when it reduces duplicate delivery without weakening segmentation, visibility, or recovery. Define an immediate stop condition for unintended flooding, loss of a priority recording, saturated uplink, unstable querier election, access outside the approved receiver set, or fallback load beyond its reserve. Capture switch and receiver state before rollback, then restore the last approved configuration as a coordinated network and video change. Do not troubleshoot a production storm by making undocumented snooping, static-group, or routing changes. ## Official references - RFC Editor, [RFC 4541: Considerations for IGMP and MLD snooping switches](https://www.rfc-editor.org/rfc/rfc4541.html). - RFC Editor, [RFC 3376: Internet Group Management Protocol, Version 3](https://www.rfc-editor.org/rfc/rfc3376.html). ## Primary reference - Name: RFC 4541: IGMP and MLD snooping switch considerations - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4541.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Design multicast video with controlled group membership and tested fallback,” DSE Security, https://update.dsesecurity.com/updates/design-multicast-video-with-controlled-membership-and-fallback/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design psychiatric residential emergency plans around youth custody and care > Use 42 CFR 441.184 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/design-psychiatric-residential-emergency-plans-around-youth-custody-and-care/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:07+00:00 - Modified: 2026-08-27T13:06:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 441.184 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 441.184 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Design psychiatric residential emergency plans around youth custody and care. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 441.184 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-441.184) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 441, the rule requires that if elected, the unified and integrated emergency preparedness program do the following: include integrated policies and procedures that meet the requirements set forth in paragraph (b) of this section, a coordinated communication plan and training and testing programs that meet the requirements of paragraphs (c) and (d) of this section, respectively. The research record locates this support at 42 CFR 441.184(e)(5), read with 42 CFR 441.184(e) (eCFR anchor p-441.184(e)(5)). - Under 42 CFR 441, the rule requires that the PRTF develop and maintain an emergency preparedness training program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 441.184(d) (eCFR anchor p-441.184(d)). Only the traced statements above are asserted as source facts. Apply the review to essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives after confirming that the source and deployed context match. ## What the source does not establish PRTF-specific federal requirement; custody, behavioral health, family communication, evacuation, staffing, Medicaid, state licensing, and survey guidance require setting-specific treatment. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 441.184(e)(5), read with 42 CFR 441.184(e) (eCFR anchor p-441.184(e)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 441.184(d) (eCFR anchor p-441.184(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from 42 CFR 441.184(e)(5), read with 42 CFR 441.184(e) (eCFR anchor p-441.184(e)(5)); 42 CFR 441.184(d) (eCFR anchor p-441.184(d)) through business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [42 CFR 441.184 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-441.184) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 441.184 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-441.184 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Design psychiatric residential emergency plans around youth custody and care,” DSE Security, https://update.dsesecurity.com/updates/design-psychiatric-residential-emergency-plans-around-youth-custody-and-care/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design shielded-VM key recovery before protecting the fabric from its admins > Shielded VMs use Host Guardian Service attestation and key protection to limit host-administrator access, which also makes guardian, owner-key, and disaster-recovery design part of availability. - Canonical URL: https://update.dsesecurity.com/updates/hyper-v-shielded-vm-key-recovery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:02+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Shielded VMs use Host Guardian Service attestation and key protection to limit host-administrator access, which also makes guardian, owner-key, and disaster-recovery design part of availability. ## Potentially affected Organizations operating Windows Server Hyper-V guarded fabrics or evaluating shielded VMs for high-value workloads. ## DSE recommendation Separate fabric and HGS trust, protect owner and guardian keys, authorize recovery fabrics in advance, and exercise VM start and recovery without privileged shortcuts. ## Article Bottom line: Hyper-V shielded VMs are designed to protect a VM from a compromised fabric and fabric administrator. Host Guardian Service (HGS) attests guarded hosts and releases protected keys to approved healthy hosts. The same boundary that blocks unauthorized inspection can also block recovery if HGS, guardian keys, owner keys, and the disaster-recovery fabric are not designed and tested. ## Source fact: what Microsoft documents Microsoft’s [guarded fabric and shielded VM overview](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms) describes a guarded fabric as HGS, one or more guarded Hyper-V hosts, and shielded VMs. HGS provides attestation and key-protection services so a shielded VM can start or live-migrate only on a host that is authorized and has successfully attested. Microsoft distinguishes regular, encryption-supported, and shielded virtual machines. Shielded VMs are generation 2 VMs with a virtual TPM and BitLocker protection and restrict fabric-administrator capabilities, including PowerShell Direct and specified integration components. The source is internally inconsistent on console access: its narrative says shielded VMs never permit a VM console connection, while its current comparison table says console and HID are enabled on hosts beginning with Windows Server version 1803 and disabled on earlier hosts. Shielding data contains sensitive provisioning information and a key protector identifying authorized guardian fabrics. Microsoft’s [tenant planning guide](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-shielded-vm-planning-for-tenants) separately describes owner keys as a last-resort recovery mechanism and supports authorizing primary and disaster-recovery fabrics. ## What the source does not establish Shielding does not secure an unpatched guest, prevent misuse by a valid guest administrator, guarantee HGS availability, or replace backup and application recovery. Encryption-supported VMs do not provide the same fabric-admin boundary as fully shielded VMs. Possession of a recovery key can weaken separation if it is poorly controlled, while loss of required keys can make a protected VM unavailable. ## Applicability questions - Is the threat model a malicious or compromised fabric administrator, host malware, stolen VHDX, or an at-rest requirement only? - Which workloads can operate within the documented console, PowerShell Direct, and integration-component restrictions for the deployed host version? - Who administers HGS, guarded hosts, guest OS, owner keys, and recovery, and are those roles separated? - Which primary and DR fabrics must be authorized, and how are guardian keys protected and restored? - Can backup, replication, monitoring, support, and incident response operate within the shielded boundary? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Write the threat model and choose shielded versus encryption-supported VMs deliberately; do not treat the terms as equivalent. - Separate HGS administration from fabric administration and protect owner and guardian keys under dual-controlled recovery procedures. - Build the primary and DR authorization model before production shielding. Preserve offline recovery material according to an approved key-management standard. - Pilot workload deployment, patching, backup, monitoring, guest administration, host attestation failure, HGS outage, migration, and DR start. - Exercise recovery without granting fabric administrators an undocumented bypass. ## Verification and evidence - Preserve HGS topology, attestation mode, guardian authorization, shielding-data provenance, role separation, and approvals. - Record successful and denied VM starts on approved, unhealthy, and unauthorized hosts in a safe test. - Demonstrate owner-key custody and recovery through an approved exercise without exposing key material in the report. - Verify application function, backup, restore, and DR from the guest and client perspective. ## Official references - [Guarded Fabric and Shielded VMs overview](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms) — Microsoft - [Shielded VM planning guide for tenants](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-shielded-vm-planning-for-tenants) — Microsoft ## Primary reference - Name: Guarded Fabric and Shielded VMs overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Design shielded-VM key recovery before protecting the fabric from its admins,” DSE Security, https://update.dsesecurity.com/updates/hyper-v-shielded-vm-key-recovery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Design the access path for a dedicated WAC gateway in Azure > What should be reviewed before hosting a Windows Admin Center gateway on an Azure VM? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-214-design-the-access-path-for-a-dedicated-wac-gateway-in-azure/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:37+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What should be reviewed before hosting a Windows Admin Center gateway on an Azure VM? ## Potentially affected Administrators deploying an Azure-hosted Windows Admin Center gateway to manage multiple VMs. ## DSE recommendation Prepare the resource, certificate, and network-access plan before running a deployment script. ## Article ## Source facts Microsoft distinguishes deploying a dedicated WAC gateway on an Azure VM for multiple VMs from using the portal experience for one VM. Its deployment script can create the environment, including the resource group. The documented gateway needs HTTPS access on port 443. Microsoft recommends limiting self-signed gateway certificates to test environments. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/deploy-wac-in-azure). ## Applicability Choose the dedicated-gateway deployment deliberately and identify its intended operators and managed machines. Review the current script parameters, certificate guidance, and network requirements. Keep a gateway VM deployment separate from enabling the portal extension on an individual server. ## DSE recommendation Prepare the resource, certificate, and network-access plan before running a deployment script. Have the Azure owner review every resource the selected parameters may create and the scope of allowed HTTPS clients. Assign an owner for the gateway name and certificate renewal. Use a controlled pilot and retain a documented management alternative while the gateway is being introduced. ## Verification Verify the created resources against the approved plan and connect using the intended DNS name and trusted certificate. Test one authorized managed VM and an unauthorized gateway user. Review the actual network exposure and any unexpected created resource. Accept the gateway only after its management path and operational ownership are clear. ## Official references [Microsoft Learn: Deploy a Windows Admin Center gateway in Azure](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/deploy-wac-in-azure). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy a Windows Admin Center gateway in Azure - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/deploy-wac-in-azure - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Design the access path for a dedicated WAC gateway in Azure,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-214-design-the-access-path-for-a-dedicated-wac-gateway-in-azure/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Designate and protect restricted maritime-facility areas based on operations and risk > Use 33 CFR 105.260 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/designate-and-protect-restricted-maritime-facility-areas-based-on-operations-and-risk/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:08+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.260 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.260 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Designate and protect restricted maritime-facility areas based on operations and risk. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.260 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.260) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, a facility owner or operator must designate restricted areas to protect the facility. The research record locates this support at 33 CFR 105.260(a)(3), read with 33 CFR 105.260(a) (eCFR anchor p-105.260(a)(3)). - Under 33 CFR 105, restricted areas must be clearly marked to show that access is restricted and unauthorized presence constitutes a security breach. The research record locates this support at 33 CFR 105.260(c)(6), read with 33 CFR 105.260(c) (eCFR anchor p-105.260(c)(6)). The source support ends with the statements listed above. Use them to examine credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.260(a)(3), read with 33 CFR 105.260(a) (eCFR anchor p-105.260(a)(3)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.260(c)(6), read with 33 CFR 105.260(c) (eCFR anchor p-105.260(c)(6)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from 33 CFR 105.260(a)(3), read with 33 CFR 105.260(a) (eCFR anchor p-105.260(a)(3)); 33 CFR 105.260(c)(6), read with 33 CFR 105.260(c) (eCFR anchor p-105.260(c)(6)) to the observed environment. Useful domain evidence includes approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [33 CFR 105.260 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.260) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.260 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.260 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Designate and protect restricted maritime-facility areas based on operations and risk,” DSE Security, https://update.dsesecurity.com/updates/designate-and-protect-restricted-maritime-facility-areas-based-on-operations-and-risk/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Designate checked-baggage screening space and keep accepted baggage controlled > Use 33 CFR 105.525 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/designate-checked-baggage-screening-space-and-keep-accepted-baggage-controlled/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:01+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.525 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.525 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Designate checked-baggage screening space and keep accepted baggage controlled. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.525 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.525) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that screening or security personnel constantly control the checked baggage, in a secure area, from the time it is accepted at the terminal until it is onboard the cruise ship. The research record locates this support at 33 CFR 105.525(c)(4) (eCFR anchor p-105.525(c)(4)). - Under 33 CFR 105, the rule requires that a cruise ship terminal that accepts baggage have at least one location designated for the screening of checked baggage. The research record locates this support at 33 CFR 105.525(c)(1) (eCFR anchor p-105.525(c)(1)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces and the conditions the source actually describes. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.525(c)(4) (eCFR anchor p-105.525(c)(4)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.525(c)(1) (eCFR anchor p-105.525(c)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations 33 CFR 105.525(c)(4) (eCFR anchor p-105.525(c)(4)); 33 CFR 105.525(c)(1) (eCFR anchor p-105.525(c)(1)) adjacent to the sanitized artifacts used for comparison. Prefer approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [33 CFR 105.525 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.525) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.525 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.525 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Designate checked-baggage screening space and keep accepted baggage controlled,” DSE Security, https://update.dsesecurity.com/updates/designate-checked-baggage-screening-space-and-keep-accepted-baggage-controlled/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Detect, mitigate, and contain data-integrity events as one response workflow > Use SP 1800-26, Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/detect-mitigate-and-contain-data-integrity-events-as-one-response-workflow/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:18:05+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use SP 1800-26, Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of SP 1800-26, Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Detect, mitigate, and contain data-integrity events as one response workflow. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [SP 1800-26, Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events](https://csrc.nist.gov/pubs/sp/1800/26/final) from National Institute of Standards and Technology supports the following bounded statements: - NIST SP 1800-26 addresses detecting and responding to ransomware and other destructive data-integrity events. The research record locates this support at Title and Abstract. - The project describes methods and potential tool sets to detect, mitigate, contain, and support response to data-integrity events. The research record locates this support at Abstract. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives only where the source and recorded environment align. ## What the source does not establish The example solution does not guarantee detection coverage, containment safety, evidence preservation, or business recovery for another architecture. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Title and Abstract, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Abstract, which observable configuration, record, or test can confirm applicability here? - Within essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, which versions, roles, and configuration states define the review population? - Could identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Title and Abstract; Abstract. Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [SP 1800-26, Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events](https://csrc.nist.gov/pubs/sp/1800/26/final) — National Institute of Standards and Technology ## Primary reference - Name: SP 1800-26, Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/1800/26/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Detect, mitigate, and contain data-integrity events as one response workflow,” DSE Security, https://update.dsesecurity.com/updates/detect-mitigate-and-contain-data-integrity-events-as-one-response-workflow/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Determine and assess threats after protected-zone intrusion indications > Use 10 CFR 73.50 - Physical protection of licensed activities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/determine-and-assess-threats-after-protected-zone-intrusion-indications/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:48+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.50 - Physical protection of licensed activities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.50 - Physical protection of licensed activities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Determine and assess threats after protected-zone intrusion indications. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.50 – Physical protection of licensed activities](https://www.ecfr.gov/current/title-10/section-73.50) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, after detecting abnormal presence, activity, or intrusion indications in a protected zone, the security organization must assess the threat’s extent. The research record locates this support at 10 CFR 73.50(g)(3)(ii), read with 10 CFR 73.50(g)(3) (eCFR anchor p-73.50(g)(3)(ii)). - Under 10 CFR 73, after detecting abnormal presence, activity, or intrusion indications in a protected zone, the security organization must determine whether a threat exists. The research record locates this support at 10 CFR 73.50(g)(3)(i), read with 10 CFR 73.50(g)(3) (eCFR anchor p-73.50(g)(3)(i)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths only where the source and recorded environment align. ## What the source does not establish NRC regulation with specific scope, thresholds, and license conditions; qualified review is required before concluding that an activity is covered or a control is sufficient. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.50(g)(3)(ii), read with 10 CFR 73.50(g)(3) (eCFR anchor p-73.50(g)(3)(ii)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.50(g)(3)(i), read with 10 CFR 73.50(g)(3) (eCFR anchor p-73.50(g)(3)(i)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from 10 CFR 73.50(g)(3)(ii), read with 10 CFR 73.50(g)(3) (eCFR anchor p-73.50(g)(3)(ii)); 10 CFR 73.50(g)(3)(i), read with 10 CFR 73.50(g)(3) (eCFR anchor p-73.50(g)(3)(i)) through asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [10 CFR 73.50 – Physical protection of licensed activities](https://www.ecfr.gov/current/title-10/section-73.50) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.50 - Physical protection of licensed activities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.50 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Determine and assess threats after protected-zone intrusion indications,” DSE Security, https://update.dsesecurity.com/updates/determine-and-assess-threats-after-protected-zone-intrusion-indications/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Determine the applicable EPA risk-management program level before relying on prevention controls > Use 40 CFR 68.12 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/determine-the-applicable-epa-risk-management-program-level-before-relying-on-prevention-controls/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:20+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.12 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.12 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Determine the applicable EPA risk-management program level before relying on prevention controls. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.12 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.12) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, a Program 3 source must implement the management system required by section 68.15. The research record locates this support at 40 CFR 68.12(d)(1), read with 40 CFR 68.12(d) (eCFR anchor p-68.12(d)(1)). - Under 40 CFR 68, a Program 3 source must implement the prevention program requirements in sections 68.65 through 68.87. The research record locates this support at 40 CFR 68.12(d)(3), read with 40 CFR 68.12(d) (eCFR anchor p-68.12(d)(3)). The source support ends with the statements listed above. Use them to examine critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 40 CFR 68.12(d)(1), read with 40 CFR 68.12(d) (eCFR anchor p-68.12(d)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.12(d)(3), read with 40 CFR 68.12(d) (eCFR anchor p-68.12(d)(3)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from 40 CFR 68.12(d)(1), read with 40 CFR 68.12(d) (eCFR anchor p-68.12(d)(1)); 40 CFR 68.12(d)(3), read with 40 CFR 68.12(d) (eCFR anchor p-68.12(d)(3)) to the observed environment. Useful domain evidence includes facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [40 CFR 68.12 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.12) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.12 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.12 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Determine the applicable EPA risk-management program level before relying on prevention controls,” DSE Security, https://update.dsesecurity.com/updates/determine-the-applicable-epa-risk-management-program-level-before-relying-on-prevention-controls/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Diagnose an invalid Change ID in the VM Conversion preview > What evidence should be collected when VM Conversion synchronization cannot validate a disk Change ID? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-048-diagnose-an-invalid-change-id-in-the-vm-conversion-preview/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:23+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What evidence should be collected when VM Conversion synchronization cannot validate a disk Change ID? ## Potentially affected Use this review only for the documented preview extension and matching synchronization symptom. ## DSE recommendation Preserve the failed operation details and the disk identifiers before attempting recovery. ## Article ## Source facts Microsoft labels the Windows Admin Center VM Conversion extension as a preview product. Its troubleshooting guide identifies a synchronization failure in which the extension cannot retrieve or validate the Change ID for one or more disks on the source VMware VM. One documented recovery path regenerates Changed Block Tracking and includes powering the source VM off and back on before retrying synchronization. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/use/troubleshoot-vm-conversion-extension). ## Applicability Use this review only for the documented preview extension and matching synchronization symptom. Identify the extension version, source VM, affected disks, and exact error. Review current preview limitations before planning further migration work. ## DSE recommendation Preserve the failed operation details and the disk identifiers before attempting recovery. Have the VMware owner examine the Changed Block Tracking state and confirm whether the documented path applies. Treat its power transition as an interruption requiring workload approval. Record the intended recovery sequence and the approved retry point rather than repeatedly restarting synchronization without evidence. ## Verification After an authorized corrective action, record the source VM and disk state and retry the selected synchronization. Compare the result with the original Change ID failure. Verify application readiness after any power transition through the agreed guest checks. Escalate a continuing failure with the retained extension, VM, and disk details before proceeding with conversion. ## Official references [Microsoft Learn: Troubleshoot the VM Conversion Extension in Windows Admin Center (Preview)](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/use/troubleshoot-vm-conversion-extension). Source reviewed September 8, 2026. ## Primary reference - Name: Troubleshoot the VM Conversion Extension in Windows Admin Center (Preview) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/use/troubleshoot-vm-conversion-extension - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Diagnose an invalid Change ID in the VM Conversion preview,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-048-diagnose-an-invalid-change-id-in-the-vm-conversion-preview/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Disable an enabled domain Guest account surfaced by identity infrastructure assessments > Use Identity infrastructure security assessments to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/disable-enabled-domain-guest-account-from-infrastructure-assessment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:06+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Identity infrastructure security assessments to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Identity infrastructure security assessments ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Disable an enabled domain Guest account surfaced by identity infrastructure assessments. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Identity infrastructure security assessments](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/identity-infrastructure) from Microsoft supports the following bounded statements: - The identity-infrastructure assessment includes a recommendation that identifies whether an Active Directory Guest account is enabled. The research record locates this support at Domain Guest account assessment description. - The stated goal of that recommendation is for the domain Guest account not to be enabled. The research record locates this support at Domain Guest account assessment description. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking and the conditions the source actually describes. ## What the source does not establish Confirm application and recovery dependencies before changing the account and validate status after the documented assessment delay. No current deployment state or change approval follows from the source alone. Validate Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Domain Guest account assessment description, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Domain Guest account assessment description, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Domain Guest account assessment description; Domain Guest account assessment description to the observed environment. Useful domain evidence includes affected-entity lists, directory attributes, relationship paths, assessment timestamps, remediation tests, and accepted exceptions; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Identity infrastructure security assessments](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/identity-infrastructure) — Microsoft ## Primary reference - Name: Identity infrastructure security assessments - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/identity-infrastructure - Source publication date: 2025-09-10 ## Citation and use Preferred citation: “Disable an enabled domain Guest account surfaced by identity infrastructure assessments,” DSE Security, https://update.dsesecurity.com/updates/disable-enabled-domain-guest-account-from-infrastructure-assessment/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Disable Azure Storage Shared Key only after every caller identifies itself > Disallowing Shared Key rejects account-key and dependent SAS authorization while allowing supported Microsoft Entra authorization, so caller discovery and migration must precede enforcement. - Canonical URL: https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:58+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Disallowing Shared Key rejects account-key and dependent SAS authorization while allowing supported Microsoft Entra authorization, so caller discovery and migration must precede enforcement. ## Potentially affected Azure Storage accounts used by applications, Azure services, scripts, portals, Azure Files, or clients that may depend on account keys or Shared Key-based SAS. ## DSE recommendation Inventory authorization type per caller, migrate supported workloads to Entra identities or user-delegation SAS, isolate incompatible Azure Files workloads, and deny Shared Key through staged policy. ## Article Bottom line: Azure Storage can reject requests authorized with the account key by setting AllowSharedKeyAccess to false. That blocks direct Shared Key use and Shared Key-backed service or account SAS. Supported Microsoft Entra authorization and Blob user-delegation SAS follow different paths. Discover every caller before enforcement or applications and Azure services may lose data access. ## Source fact: what Microsoft documents Microsoft’s [Shared Key prevention guide](https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent) says a storage account permits Shared Key when AllowSharedKeyAccess is true or unset. When the property is false, requests authorized with the account key are rejected. Microsoft recommends Entra authorization where supported. The source distinguishes SAS types. Account SAS and service SAS depend on Shared Key and are rejected when Shared Key is disallowed. A Blob user-delegation SAS is authorized through Entra and can continue under documented conditions. Microsoft warns that logs and metrics do not always make SAS type easy to distinguish. It also documents compatibility issues: some Azure services and tools use Shared Key, and Azure Files requires careful identity and portal behavior review. Microsoft proposes detection, remediation, audit, and governance, including Azure Policy in audit before deny. ## What the source does not establish Disabling Shared Key does not make all storage access least privilege, remove existing Entra role assignments, prevent anonymous access where separately enabled, or rotate data-encryption keys. A successful Entra request does not prove the identity has only necessary permissions. Metrics showing SAS use do not by themselves identify whether it is service, account, or user-delegation SAS. ## Applicability questions - Which applications, scripts, users, managed identities, Azure services, and third parties call the account? - Do they use account keys, account SAS, service SAS, user-delegation SAS, Entra OAuth, anonymous access, SFTP local users, or SMB identity? - Does the account host Azure Files, and can each file-access and portal scenario use supported identity authorization? - Which callers can migrate, which need a separate account, and which are vendor-blocked? - Who can list account keys or change AllowSharedKeyAccess after enforcement? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Inventory storage accounts and set the built-in policy to audit. Treat an unset property as allowing Shared Key, consistent with Microsoft’s documentation. - Use logs, metrics, code search, secret inventory, and application-owner interviews to identify authorization per caller. Validate ambiguous SAS traffic directly. - Migrate supported callers to managed identity or another Entra identity with narrow data-plane roles; use user-delegation SAS where appropriate. - Separate incompatible Azure Files or service dependencies rather than leaving a broad mixed-use account permanently exposed. - Set AllowSharedKeyAccess false in a pilot, monitor 403 failures, then move policy from audit to deny after successful migration. ## Verification and evidence - Preserve caller inventory, authorization type, migration owner, RBAC assignments, exceptions, and approval. - Query the account property and prove it returns false after enforcement. - Demonstrate Entra-authorized test access succeeds while an account-key or service-SAS test is rejected. - Monitor policy compliance and failed authorization after rollout; investigate any reenablement. ## Official references - [Prevent Shared Key authorization for an Azure Storage account](https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent) — Microsoft ## Primary reference - Name: Prevent Shared Key authorization for an Azure Storage account - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/storage/common/shared-key-authorization-prevent - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Disable Azure Storage Shared Key only after every caller identifies itself,” DSE Security, https://update.dsesecurity.com/updates/azure-storage-shared-key-migration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Disable-DnsServerPolicy: disable dns server policy under AD/DNS change control > Use Disable-DnsServerPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/disable-dnsserverpolicy-disable-dns-server-policy-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:10+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Disable-DnsServerPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Disable-DnsServerPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Disable-DnsServerPolicy: disable dns server policy under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Disable-DnsServerPolicy](https://learn.microsoft.com/en-us/powershell/module/dnsserver/disable-dnsserverpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Disable-DnsServerPolicy cmdlet disables Domain Name System (DNS) server policies.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can disable both query resolution policies and zone transfer policies.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-256 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Disable-DnsServerPolicy](https://learn.microsoft.com/en-us/powershell/module/dnsserver/disable-dnsserverpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Disable-DnsServerPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/disable-dnsserverpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Disable-DnsServerPolicy: disable dns server policy under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/disable-dnsserverpolicy-disable-dns-server-policy-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Disable-DnsServerSigningKeyRollover: disable dns server signing key rollover with before-and-after evidence > Use Disable-DnsServerSigningKeyRollover to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/disable-dnsserversigningkeyrollover-disable-dns-server-signing-key-rollover-with-before-and-after/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:57+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Disable-DnsServerSigningKeyRollover to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Disable-DnsServerSigningKeyRollover ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Disable-DnsServerSigningKeyRollover: disable dns server signing key rollover with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Disable-DnsServerSigningKeyRollover](https://learn.microsoft.com/en-us/powershell/module/dnsserver/disable-dnsserversigningkeyrollover?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Disable-DnsServerSigningKeyRollover cmdlet disables key rollover on an input key.” The research record locates this support at DESCRIPTION. - At Example 1: Get and disable keys, Microsoft states: “This command gets DNSSEC keys for the DNSServer06.contoso.com zone and disables rollover for each key.” The research record locates this support at Example 1: Get and disable keys. The source support ends with the statements listed above. Use them to examine Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Get and disable keys, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; Example 1: Get and disable keys. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-269 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Disable-DnsServerSigningKeyRollover](https://learn.microsoft.com/en-us/powershell/module/dnsserver/disable-dnsserversigningkeyrollover?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Disable-DnsServerSigningKeyRollover - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/disable-dnsserversigningkeyrollover?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Disable-DnsServerSigningKeyRollover: disable dns server signing key rollover with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/disable-dnsserversigningkeyrollover-disable-dns-server-signing-key-rollover-with-before-and-after/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Discover mail endpoints through service-specific SRV records > Use RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:04+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Discover mail endpoints through service-specific SRV records. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services](https://www.rfc-editor.org/rfc/rfc6186.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A mail client uses the domain part of the user’s address to query service-specific SRV names and obtains the selected endpoint’s target host and port. The research record locates this support at Section 4 (Guidance for MUAs). - The _imap and _pop3 labels identify explicit-TLS-upgrade services, while _imaps and _pop3s identify services that begin TLS immediately on connection. The research record locates this support at Sections 3.2 (IMAP) and 3.3 (POP3). - When several SRV records describe one service, the client must apply SRV priority and weight; a target of a single dot marks that service unavailable. The research record locates this support at Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs). Keep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 4 (Guidance for MUAs), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 3.2 (IMAP) and 3.3 (POP3), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations Section 4 (Guidance for MUAs); Sections 3.2 (IMAP) and 3.3 (POP3); Sections 3.4 (Priority for Domain Preferences) and 4 (Guidance for MUAs) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services](https://www.rfc-editor.org/rfc/rfc6186.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6186 — Use of SRV Records for Locating Email Submission/Access Services - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6186.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Discover mail endpoints through service-specific SRV records,” DSE Security, https://update.dsesecurity.com/updates/discover-mail-endpoints-through-service-specific-srv-records/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Distinguish a cluster name object from the administrator who creates it > Which Active Directory computer objects are created for a domain failover cluster? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-145-distinguish-a-cluster-name-object-from-the-administrator-who-creates-it/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:46+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which Active Directory computer objects are created for a domain failover cluster? ## Potentially affected Administrators reviewing Active Directory identities used by Windows failover clusters. ## DSE recommendation Maintain an inventory separating the administrator account, CNO, and role-specific computer objects. ## Article ## Source facts For the documented domain cluster, the creation wizards generate computer objects and assign required permissions. The cluster itself receives a cluster name object, or CNO. Most clustered services and applications receive additional computer accounts; Hyper-V VMs do not require a dedicated account through this process. The user who runs the cluster-creation wizard supplies the initial permission context from which the cluster account is created. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-cluster-accounts-overview). ## Applicability Identify the intended cluster, its domain location, creation account, and clustered roles. Review the required permissions and any prestaging procedure before changing objects or directory delegation. ## DSE recommendation Maintain an inventory separating the administrator account, CNO, and role-specific computer objects. Have the directory and cluster owners agree on who manages each object and its permissions. Before modifying an existing account, record the current access control and the cluster role that depends on it. ## Verification After approved creation or permission maintenance, inspect the expected objects and test the relevant network-name resources and role access. Correlate directory changes with cluster observations. Treat an unexpected missing account or altered permission as a finding to resolve rather than creating replacement identities without understanding the dependency. ## Official references [Microsoft Learn: Failover cluster accounts overview](https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-cluster-accounts-overview). Source reviewed September 8, 2026. ## Primary reference - Name: Failover cluster accounts overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-cluster-accounts-overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Distinguish a cluster name object from the administrator who creates it,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-145-distinguish-a-cluster-name-object-from-the-administrator-who-creates-it/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Distinguish a Hyper-V heartbeat from a graceful guest shutdown > What do the heartbeat and guest-shutdown integration services actually establish? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-184-distinguish-a-hyper-v-heartbeat-from-a-graceful-guest-shutdown/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:07+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What do the heartbeat and guest-shutdown integration services actually establish? ## Potentially affected Administrators interpreting Hyper-V guest monitoring and shutdown behavior. ## DSE recommendation Update the operations runbook so each action names its intended integration service and expected guest behavior. ## Article ## Source facts The Hyper-V heartbeat service reports to the host that the guest operating system is installed and has booted; disabling it limits that host-side signal. The guest-shutdown service lets the host request an orderly shutdown inside the VM. Microsoft warns that, without that service, host-triggered shutdowns become hard power-offs with possible data loss or corruption. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/integration-services). ## Applicability Identify which host-side observation is being used to assess the guest and which mechanism an operator intends to use for shutdown. Keep operating-system heartbeat, application readiness, and successful shutdown as separate acceptance results. Review workload-specific handling before testing. ## DSE recommendation Update the operations runbook so each action names its intended integration service and expected guest behavior. Ask the application owner to define the transaction that demonstrates readiness after startup. For shutdown testing, schedule an approved disposable or recoverable workload and record the expected orderly sequence. Do not use a positive heartbeat as the sole evidence that an application can safely be stopped. ## Verification Observe the heartbeat state after the test VM starts, then verify the application independently. Request an approved graceful shutdown and retain guest and host observations showing how it completed. Investigate absent integration-service responses before substituting a forced power action. Record the actual service state and any exception. ## Official references [Microsoft Learn: Hyper-V Integration Services](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/integration-services). Source reviewed September 8, 2026. ## Primary reference - Name: Hyper-V Integration Services - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/integration-services - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Distinguish a Hyper-V heartbeat from a graceful guest shutdown,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-184-distinguish-a-hyper-v-heartbeat-from-a-graceful-guest-shutdown/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Distinguish a Storage Spaces pool from the resiliency of each virtual disk > Where is the data-protection choice made in a Windows Storage Spaces design? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-160-distinguish-a-storage-spaces-pool-from-the-resiliency-of-each-virtual-disk/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:31+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Where is the data-protection choice made in a Windows Storage Spaces design? ## Potentially affected Administrators reviewing Windows Server Storage Spaces pools and virtual disks. ## DSE recommendation Prepare a mapping from each workload to its virtual disk and selected resiliency. ## Article ## Source facts Storage Spaces combines physical drives into logical pools and creates virtual disks from the pooled capacity. Microsoft describes choosing resiliency and performance characteristics for each virtual disk. A simple space stripes data without redundancy, so a drive failure can lose data. Mirror spaces duplicate data into two or three copies, providing a different protection model from a simple space. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/overview). ## Applicability Identify the physical drives, pool, virtual disks, workload data, and required recovery behavior. Review the supported hardware and configuration for the actual Storage Spaces design rather than inferring protection from a pool name. ## DSE recommendation Prepare a mapping from each workload to its virtual disk and selected resiliency. Have the data owner explicitly approve any simple space and document how its contents can be recreated or recovered. Keep the physical pool inventory separate from the virtual-disk protection decision. ## Verification Inspect the actual virtual-disk resiliency and compare it with the approved mapping. Verify representative file access and the documented recovery procedure using an authorized test. Record unprotected data or an unexpected virtual-disk layout as a finding before expanding the workload onto that storage. ## Official references [Microsoft Learn: Storage Spaces overview](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/overview). Source reviewed September 8, 2026. ## Primary reference - Name: Storage Spaces overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Distinguish a Storage Spaces pool from the resiliency of each virtual disk,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-160-distinguish-a-storage-spaces-pool-from-the-resiliency-of-each-virtual-disk/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Distinguish an intentionally dismounted Storage Replica destination from a failed copy > How should replication progress be checked when a destination volume is not mounted? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-042-distinguish-an-intentionally-dismounted-storage-replica-destination-from-a-failed/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:29+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should replication progress be checked when a destination volume is not mounted? ## Potentially affected Use this review when assessing an existing server-to-server relationship. ## DSE recommendation Record the relationship and replica-group state before attempting any corrective change. ## Article ## Source facts Microsoft documents server-to-server Storage Replica as synchronization of a volume between two servers. Destination volumes and their drive letters or mount points are deliberately dismounted by Storage Replica. The destination replica group exposes the remaining byte count for progress inspection. Microsoft documents Get-SRPartnership and Get-SRGroup for checking the actual replication endpoints and state. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-replica/server-to-server-storage-replication). ## Applicability Use this review when assessing an existing server-to-server relationship. Identify its current source, destination, and volumes before interpreting a missing destination drive letter as a storage failure. ## DSE recommendation Record the relationship and replica-group state before attempting any corrective change. Examine copy progress and the relevant replication events together. Keep a source/destination worksheet with the investigation so the intended passive endpoint is unmistakable. Do not authorize a direction change solely to make the destination visible for an informal file inspection. ## Verification Compare repeated progress observations and recorded events with the agreed monitoring criteria. Investigate errors or lack of expected progress through the matching source procedure. If recovery testing is required, arrange it as a separate approved exercise. Preserve the endpoint identities, observations, and conclusion so intentional dismounting remains distinguishable from a later genuine failure. ## Official references [Microsoft Learn: Server-to-Server Storage Replication](https://learn.microsoft.com/en-us/windows-server/storage/storage-replica/server-to-server-storage-replication). Source reviewed September 8, 2026. ## Primary reference - Name: Server-to-Server Storage Replication - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-replica/server-to-server-storage-replication - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Distinguish an intentionally dismounted Storage Replica destination from a failed copy,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-042-distinguish-an-intentionally-dismounted-storage-replica-destination-from-a-failed/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Distinguish creating an NPS template from applying it > When does an NPS template actually change server behavior? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-225-distinguish-creating-an-nps-template-from-applying-it/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:26+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know When does an NPS template actually change server behavior? ## Potentially affected Administrators managing reusable Network Policy Server templates. ## DSE recommendation Name the template owner and record its intended consumers before application. ## Article ## Source facts Microsoft describes NPS templates as reusable configuration elements, including RADIUS clients and shared secrets, that can be exported to other NPS servers. Creating a template alone does not change NPS operation; the template takes effect when it is selected and applied in the relevant console location. Templates Management provides functions to inspect template use as well as create, modify, duplicate, or remove templates. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-templates). ## Applicability Identify the configuration element being reused and the server objects intended to consume it. Separate a newly saved template from an applied configuration. Review any sensitive values through the approved secret-handling process rather than copying them into ordinary change notes. ## DSE recommendation Name the template owner and record its intended consumers before application. Have the NPS administrator review the template content and select a representative client or configuration object for the pilot. Preserve the original consumer settings. When distributing templates to another server, include the intended use and approval scope so a receiving operator does not assume import automatically applies every setting. ## Verification Inspect the actual consumer object after application and compare its effective configuration with the template decision. Test the associated RADIUS transaction, then verify that an unrelated object was not changed. Record where the template is in use and who will review later revisions. Keep template creation, transfer, and application as separate completed actions. ## Official references [Microsoft Learn: Manage NPS Templates](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-templates). Source reviewed September 8, 2026. ## Primary reference - Name: Manage NPS Templates - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-templates - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Distinguish creating an NPS template from applying it,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-225-distinguish-creating-an-nps-template-from-applying-it/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Distinguish DSCP marking from outbound throttling in Windows QoS policy > Should a Windows QoS policy mark traffic, throttle it, or apply both controls? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-131-distinguish-dscp-marking-from-outbound-throttling-in-windows-qos-policy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:00+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Should a Windows QoS policy mark traffic, throttle it, or apply both controls? ## Potentially affected Administrators creating application-scoped Windows QoS policies through Group Policy. ## DSE recommendation Have the application and network owners agree on the selected executable or path and the intended traffic behavior. ## Article ## Source facts Windows QoS policies combine traffic controls with Group Policy management. A DSCP setting specifies the marking used for outbound traffic. A throttle setting limits the rate of outgoing traffic, and Microsoft permits marking and throttling together. The policy can target all applications, a named executable, a path and executable, or HTTP-server applications handling a specified URL. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/qos/qos-policy-manage). ## Applicability Identify the application, traffic direction, endpoints, and the actual network treatment expected for its marking. Review whether the requirement is classification, a rate cap, or both before setting policy. ## DSE recommendation Have the application and network owners agree on the selected executable or path and the intended traffic behavior. Record the DSCP value and any throttle separately, including the chosen rate units. Scope the GPO to a representative pilot group and retain the former policy configuration. ## Verification Run the intended application and inspect its outbound marking and measured rate. Include another application that should remain outside the policy. Compare observed traffic with the approved settings and investigate unexpected matches or restrictions before assigning the policy to a larger device group. ## Official references [Microsoft Learn: Manage QoS Policy](https://learn.microsoft.com/en-us/windows-server/networking/technologies/qos/qos-policy-manage). Source reviewed September 8, 2026. ## Primary reference - Name: Manage QoS Policy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/qos/qos-policy-manage - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Distinguish DSCP marking from outbound throttling in Windows QoS policy,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-131-distinguish-dscp-marking-from-outbound-throttling-in-windows-qos-policy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Distinguish NPS revocation exceptions before changing the registry > Which NPS setting bypasses all client revocation checks versus an unavailable CRL service? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-229-distinguish-nps-revocation-exceptions-before-changing-the-registry/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:22+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which NPS setting bypasses all client revocation checks versus an unavailable CRL service? ## Potentially affected Administrators reviewing EAP-TLS revocation-check exceptions on NPS. ## DSE recommendation Ask the identity and PKI owners to document the reason for any exception, its scope, and the plan to repair the underlying validation path. ## Article ## Source facts Microsoft documents separate registry controls for different NPS certificate-revocation conditions. Enabling NoRevocationCheck prevents EAP-TLS from checking the client certificate for revocation. Enabling IgnoreRevocationOffline allows EAP-TLS clients to connect when the network server holding the CRL is unavailable. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/network-policy-server-certificate-revocation-list-check-registry-settings). ## Applicability Inventory the effective exception values and the actual certificate-validation failure before proposing a change. Separate a revoked credential from a failure to reach revocation information. Review the source definition of the selected value rather than inferring behavior from a similar registry name. ## DSE recommendation Ask the identity and PKI owners to document the reason for any exception, its scope, and the plan to repair the underlying validation path. Preserve the initial settings and relevant authentication events. Use a controlled test with a dedicated certificate set before changing production behavior. Keep any exception time-bounded and assigned to an owner who can remove it after repair. ## Verification Test valid, revoked, and unavailable-CRL conditions according to the approved laboratory plan. Compare NPS decisions with the intended exception semantics and record each outcome separately. Verify that repairing CRL access permits removal of the exception. Do not treat a newly successful connection as evidence that revocation validation remains intact. ## Official references [Microsoft Learn: Configure Network Policy Server Certificate Revocation List registry settings for Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/network-policy-server-certificate-revocation-list-check-registry-settings). Source reviewed September 8, 2026. ## Primary reference - Name: Configure Network Policy Server Certificate Revocation List registry settings for Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/network-policy-server-certificate-revocation-list-check-registry-settings - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Distinguish NPS revocation exceptions before changing the registry,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-229-distinguish-nps-revocation-exceptions-before-changing-the-registry/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Distinguish public access areas from secure areas at regulated maritime facilities > Use 33 CFR 105.106 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/distinguish-public-access-areas-from-secure-areas-at-regulated-maritime-facilities/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:47+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.106 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.106 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Distinguish public access areas from secure areas at regulated maritime facilities. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.106 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.106) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, a public access area is a defined space within a facility that is open to all persons and provides pedestrian access through the facility from public thoroughfares to the vessel. The research record locates this support at 33 CFR 105.106(b) (eCFR anchor p-105.106(b)). - Under 33 CFR 105, a facility serving ferries or passenger vessels certificated to carry more than 150 passengers, other than cruise ships, may designate an area within the facility as a public access area. The research record locates this support at 33 CFR 105.106(a) (eCFR anchor p-105.106(a)). Keep the evidence boundary at these traced claims. They support a review of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.106(b) (eCFR anchor p-105.106(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.106(a) (eCFR anchor p-105.106(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 33 CFR 105.106(b) (eCFR anchor p-105.106(b)); 33 CFR 105.106(a) (eCFR anchor p-105.106(a)). Favor approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [33 CFR 105.106 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.106) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.106 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.106 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Distinguish public access areas from secure areas at regulated maritime facilities,” DSE Security, https://update.dsesecurity.com/updates/distinguish-public-access-areas-from-secure-areas-at-regulated-maritime-facilities/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Distinguish SDN load balancing from outbound NAT and full VIP forwarding > Which SDN load-balancer rule matches the required traffic direction and exposure? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-104-distinguish-sdn-load-balancing-from-outbound-nat-and-full-vip-forwarding/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:27+00:00 - Modified: 2026-09-08T18:23:26+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which SDN load-balancer rule matches the required traffic direction and exposure? ## Potentially affected Administrators configuring Microsoft SDN Software Load Balancer rules. ## DSE recommendation Create a traffic contract listing the required source, destination, direction, and scope. ## Article ## Source facts Microsoft documents Software Load Balancer for incoming distribution, inbound NAT, and outbound NAT. Its outbound NAT example gives a VM in private virtual-network address space an internet-bound translation path. An L3 forwarding rule maps a virtual IP to one VM network interface without specifying individual ports. Microsoft describes that rule as forwarding all traffic to and from that VM through the assigned VIP. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Configure-SLB-and-NAT). ## Applicability Identify the traffic direction, intended virtual IP, backend interfaces, approved ports, and service owner. Review whether the requirement is a shared service, outbound access, or a whole-address mapping before adapting an example. ## DSE recommendation Create a traffic contract listing the required source, destination, direction, and scope. Have the application and network owners review any whole-address forwarding request explicitly. Record the backend membership and avoid substituting a broad rule merely because a narrower service test failed. ## Verification Test the required traffic and a deliberately excluded path from the intended networks. Confirm which backend receives the request and which translated address is observed. Preserve the actual rule and membership with the test results, and investigate unexpected exposure before placing the rule into wider service. ## Official references [Microsoft Learn: Configure the Software Load Balancer for Load Balancing and Network Address Translation (NAT)](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Configure-SLB-and-NAT). Source reviewed September 8, 2026. ## Primary reference - Name: Configure the Software Load Balancer for Load Balancing and Network Address Translation (NAT) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Configure-SLB-and-NAT - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Distinguish SDN load balancing from outbound NAT and full VIP forwarding,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-104-distinguish-sdn-load-balancing-from-outbound-nat-and-full-vip-forwarding/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Distribute trusted certificates through a controlled GPO > Use Distribute certificates to Windows devices by using Group Policy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/distribute-trusted-certificates-through-controlled-gpo/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:07+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Distribute certificates to Windows devices by using Group Policy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Distribute certificates to Windows devices by using Group Policy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Distribute trusted certificates through a controlled GPO. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Distribute certificates to Windows devices by using Group Policy](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/distribute-certificates-group-policy) from Microsoft supports the following bounded statements: - Group Policy can distribute certificates that chain to a trusted root to Windows devices in an AD domain. The research record locates this support at Opening overview. - The documented workflow imports the certificates into a Group Policy object after prerequisites are met. The research record locates this support at Sections: Prerequisites; Import certificates to Group Policy. Keep the evidence boundary at these traced claims. They support a review of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Limit GPO scope and validate certificate fingerprints before trust-store distribution. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: Prerequisites; Import certificates to Group Policy, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles are in and out of scope? - Which condition in Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Sections: Prerequisites; Import certificates to Group Policy through CA and template exports, enrollment tests, certificate chains, access-control entries, event logs, and revocation-path checks. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Distribute certificates to Windows devices by using Group Policy](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/distribute-certificates-group-policy) — Microsoft ## Primary reference - Name: Distribute certificates to Windows devices by using Group Policy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/distribute-certificates-group-policy - Source publication date: 2024-02-16 ## Citation and use Preferred citation: “Distribute trusted certificates through a controlled GPO,” DSE Security, https://update.dsesecurity.com/updates/distribute-trusted-certificates-through-controlled-gpo/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Do not confuse Group Policy preferences with enforced policy > Use Group Policy preferences in Windows to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/do-not-confuse-gpp-with-enforced-policy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:49+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Group Policy preferences in Windows to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Group Policy preferences in Windows ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Do not confuse Group Policy preferences with enforced policy. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Group Policy preferences in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-preferences) from Microsoft supports the following bounded statements: - Group Policy preferences configure settings beyond standard policy options but can be overridden by policy settings. The research record locates this support at Opening overview. - Preferences are generally changeable by users, while policy settings are administrator-enforced. The research record locates this support at Opening overview. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles and the conditions the source actually describes. ## What the source does not establish Use preferences only where user changeability and tattooing behavior are acceptable. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Opening overview. Favor directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Group Policy preferences in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-preferences) — Microsoft ## Primary reference - Name: Group Policy preferences in Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-policy/group-policy-preferences - Source publication date: 2025-06-16 ## Citation and use Preferred citation: “Do not confuse Group Policy preferences with enforced policy,” DSE Security, https://update.dsesecurity.com/updates/do-not-confuse-gpp-with-enforced-policy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Do not let a familiar voice or face authorize a sensitive action > Synthetic voice and video can make an impostor look familiar. Remove media familiarity from help-desk resets, executive requests, and payment approvals; verify through independent identity and workflow controls. - Canonical URL: https://update.dsesecurity.com/updates/do-not-let-a-familiar-voice-or-face-authorize-a-sensitive-action/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, Cybersecurity, Microsoft 365 & Identity - Reading time: 4 minutes ## What you need to know Synthetic voice and video can make an impostor look familiar. Remove media familiarity from help-desk resets, executive requests, and payment approvals; verify through independent identity and workflow controls. ## Potentially affected Help desks, identity administrators, executives and assistants, finance and payment teams, procurement, human resources, communications, and fraud or incident response teams. ## DSE recommendation Identify sensitive workflows, stop treating voice or video as identity proof, require independent callbacks and in-system approvals, and use detection tools only as supporting evidence. ## Article ## Source fact: realistic media does not establish identity The FBI has described attackers who impersonate employees to persuade help desks to reset credentials and attackers who use synthetic voice or video to impersonate executives. In an [FBI Ahead of the Threat discussion](https://www.fbi.gov/video-repository/ahead-of-the-threat-podcast-s1-e6-charles-carmakal/view), investigators explain that personal knowledge questions may be answered from information attackers obtain elsewhere. A familiar face, voice, supervisor name, or biographical detail can make a request persuasive without making it authentic. The FBI’s [2025 impersonation alert](https://www.fbi.gov/investigate/cyber/alerts/2025/senior-us-officials-continue-to-be-impersonated-in-malicious-messaging-campaign) reports malicious text and AI-generated voice messages impersonating senior officials and advises recipients to independently verify identity rather than assume a message is authentic. The FTC’s [review of approaches to AI-enabled voice cloning](https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2024/04/approaches-address-ai-enabled-voice-cloning) says no single intervention solves the problem and discusses limitations and false results across detection and other technical approaches. ## DSE recommendation: make the workflow the authority DSE recommendation: classify live and recorded audio or video as untrusted presentation, not identity proof. A detector may add a signal, but a sensitive action should be authorized by an independently authenticated person using an approved system of record. This article differs from DSE’s existing business-email-compromise guidance: it focuses on identity proof and action authorization when an attacker can convincingly reproduce a person’s voice or image. ## Apply the control where impersonation changes access or money - Help-desk and identity actions: password and multifactor resets, new authenticator enrollment, recovery-contact changes, account unlocks, privilege changes, and device registration. - Executive and administrative requests: release of confidential information, creation of accounts, changes to access, urgent travel or personnel requests, and instructions to bypass a normal control. - Finance and commercial actions: new or changed payment instructions, bank-detail changes, refunds, gift-card or cryptocurrency purchases, new suppliers, and release of a held payment. Map each action to an authoritative request channel, required authentication, approver, separation of duties, evidence retained, and an alternate process for genuine emergencies. The requester must not be allowed to choose a new phone number, email address, messaging account, or colleague as the only verification route. ## Checklist for help desks - Locate the user in an existing trusted directory; do not rely on contact details provided in the inbound request. - Use an established authenticated channel or call a previously recorded number. If that path is unavailable, use the documented recovery process and its additional approval rather than improvising. - Verify the requested action and its business reason. Treat urgency, secrecy, and pressure to avoid a callback as risk signals, not proof of fraud. - Require independent approval for high-impact resets or privilege changes according to local policy. The same person should not both override identity proof and execute an irreversible action without review. - Notify the account owner through a separate established channel and preserve the request, verification steps, decision, operator, and resulting account changes. ## Checklist for executives and payment teams Route instructions into the normal approval system and require the same authorization steps regardless of whether the request arrived by video conference, phone, text, or email. For a material change, call back through a known directory or confirm in an existing authenticated workflow. Verify the transaction details as well as the person: payee, account, amount, purpose, contract or invoice, and approving authority. An executive’s presence on video should not cancel dual approval or supplier bank-change validation. ## Use detection as supporting evidence [NIST AI 100-4](https://www.nist.gov/publications/reducing-risks-posed-synthetic-content-overview-technical-approaches-digital-content) surveys provenance and authentication, watermarking, detection, testing, and auditing for synthetic content. These techniques can contribute evidence, but coverage varies by content, generator, transformation, and operating condition. Validate any tool on the media and decisions where it will be used; document false-positive and false-negative consequences. Do not let a detector’s clean result authorize a reset or payment. When impersonation is suspected, stop the action, preserve the original message and metadata, contact the real person through a known route, notify fraud or incident response, and follow reporting obligations. Avoid repeatedly forwarding sensitive media through consumer tools, which can lose metadata and expose information. The durable defense is a workflow that remains valid even when the voice and face are perfect. ## Official sources - [FBI: Ahead of the Threat, identity impersonation and synthetic media discussion](https://www.fbi.gov/video-repository/ahead-of-the-threat-podcast-s1-e6-charles-carmakal/view) - [FBI: Senior Officials Continue to Be Impersonated in Malicious Messaging Campaign](https://www.fbi.gov/investigate/cyber/alerts/2025/senior-us-officials-continue-to-be-impersonated-in-malicious-messaging-campaign) - [FTC: Approaches to Address AI-Enabled Voice Cloning](https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2024/04/approaches-address-ai-enabled-voice-cloning) - [NIST: AI 100-4, Reducing Risks Posed by Synthetic Content](https://www.nist.gov/publications/reducing-risks-posed-synthetic-content-overview-technical-approaches-digital-content) ## Primary reference - Name: NIST AI 100-4, Reducing Risks Posed by Synthetic Content - Authority: National Institute of Standards and Technology - URL: https://www.nist.gov/publications/reducing-risks-posed-synthetic-content-overview-technical-approaches-digital-content - Source publication date: 2024-11-20 ## Citation and use Preferred citation: “Do not let a familiar voice or face authorize a sensitive action,” DSE Security, https://update.dsesecurity.com/updates/do-not-let-a-familiar-voice-or-face-authorize-a-sensitive-action/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Do not substitute cameras for a required CJIS visitor escort > The FBI CJIS Security Policy explicitly says camera or electronic monitoring does not constitute an escort. Design visitor procedures around a qualified person where escort is required. - Canonical URL: https://update.dsesecurity.com/updates/do-not-substitute-cameras-for-a-required-cjis-visitor-escort/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:46+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Briefing - DSE priority: Important - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 2 minutes ## What you need to know The FBI CJIS Security Policy explicitly says camera or electronic monitoring does not constitute an escort. Design visitor procedures around a qualified person where escort is required. ## Potentially affected Criminal justice agencies, contractors, and facilities applying CJIS Security Policy visitor controls in physically secure locations or controlled areas. ## DSE recommendation Identify where CJIS escort requirements apply, assign trained escort roles and coverage, and use video only as a supporting control rather than the escort itself. ## Article Bottom line: live or recorded camera coverage may help observe and investigate a visit, but it does not meet a CJIS requirement for an escort. A qualified person must perform the escort function wherever the current policy requires it. ## Source fact: electronic monitoring is not an escort The [FBI CJIS Security Policy v6.1 — Appendix A definition of Escort](https://le.fbi.gov/file-repository/cjis_security_policy_v6-1_20260625.pdf#page=302), dated June 25, 2026, states that camera and electronic monitoring do not constitute an escort. The policy contains physical-protection and visitor-control requirements that must be read in their complete applicability context. This sentence closes a common design shortcut. A control room operator watching multiple feeds cannot automatically replace the person responsible for maintaining the required relationship with a visitor and limiting that visitor’s activity. ## Source boundary and applicability The CJIS Security Policy applies according to criminal justice information, agency relationships, contracts, location classification, and CJIS Systems Agency or Information Security Officer direction. This article does not determine whether a particular person is a visitor, whether an escort is required in a specific area, or what local procedure satisfies the requirement. Consult the current policy and responsible CJIS authority. ## Applicability questions - Which locations, systems, media, or work activities bring the visit into CJIS scope? - Who is considered authorized unescorted personnel under current policy and local approval? - What qualifications, proximity, and duties must the escort maintain? - Can staffing cover simultaneous visitors, breaks, emergencies, and after-hours work? - How do sign-in, badge, access events, camera records, and escort records reconcile? ## DSE recommendation: design a human escort workflow The following steps are DSE recommendations based on the cited source. Have the CJIS authority define scope, authorized populations, escort qualifications, permitted visitor areas, prohibited actions, and required records. At sign-in, verify identity as required, record purpose and sponsor, issue a visibly distinct and time-bounded credential, brief restrictions, and name the responsible escort. Transfer responsibility only through an explicit handoff. Use access control and video to reinforce boundaries, investigate exceptions, and document events; do not label those systems as the escort. Stop work if required escort coverage is lost. At departure, recover credentials, reconcile tools or media where required, record time out, and review anomalies. Exercise an escort handoff and an unexpected staffing interruption so the procedure proves continuous responsibility instead of assuming one named employee is always available. ## Verification and evidence Retain the applicability determination, current local procedure, escort roster and training, visitor logs, badge issue/return records, access events, exception reports, contractor instructions, and periodic observation of the workflow. Protect visitor personal information and CJIS-sensitive facility details according to policy. ## Official references - [FBI CJIS Security Policy v6.1 — Appendix A definition of Escort](https://le.fbi.gov/file-repository/cjis_security_policy_v6-1_20260625.pdf#page=302) – Federal Bureau of Investigation; June 25, 2026 ## Primary reference - Name: FBI CJIS Security Policy v6.1 — Appendix A definition of Escort - Authority: le.fbi.gov - URL: https://le.fbi.gov/file-repository/cjis_security_policy_v6-1_20260625.pdf#page=302 - Source publication date: 2026-06-25 ## Citation and use Preferred citation: “Do not substitute cameras for a required CJIS visitor escort,” DSE Security, https://update.dsesecurity.com/updates/do-not-substitute-cameras-for-a-required-cjis-visitor-escort/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Document release-scenario assumptions, methods, data, and endpoint results > Use 40 CFR 68.39 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/document-release-scenario-assumptions-methods-data-and-endpoint-results/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:12+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.39 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.39 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Document release-scenario assumptions, methods, data, and endpoint results. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.39 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.39) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, offsite-consequence records for alternative release scenarios must describe the scenarios, assumptions, parameters, selection rationale, administrative controls, and mitigation assumed to limit a release. The research record locates this support at 40 CFR 68.39(b), read with the unnumbered introductory paragraph of 40 CFR 68.39 (eCFR anchor p-68.39(b)). - Under 40 CFR 68, the owner or operator must retain the data used to estimate potentially affected populations and environmental receptors. The research record locates this support at 40 CFR 68.39(e), read with the unnumbered introductory paragraph of 40 CFR 68.39 (eCFR anchor p-68.39(e)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths and the conditions the source actually describes. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 40 CFR 68.39(b), read with the unnumbered introductory paragraph of 40 CFR 68.39 (eCFR anchor p-68.39(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.39(e), read with the unnumbered introductory paragraph of 40 CFR 68.39 (eCFR anchor p-68.39(e)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and sanitize protected material before retention. ## Verification and evidence Keep the source locations 40 CFR 68.39(b), read with the unnumbered introductory paragraph of 40 CFR 68.39 (eCFR anchor p-68.39(b)); 40 CFR 68.39(e), read with the unnumbered introductory paragraph of 40 CFR 68.39 (eCFR anchor p-68.39(e)) adjacent to the sanitized artifacts used for comparison. Prefer facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [40 CFR 68.39 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.39) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.39 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.39 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Document release-scenario assumptions, methods, data, and endpoint results,” DSE Security, https://update.dsesecurity.com/updates/document-release-scenario-assumptions-methods-data-and-endpoint-results/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Document tenant and subnet identifiers in an HNVv2 overlay network > How should tenant boundaries be represented when HNVv2 virtual networks reuse IP ranges? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-049-document-tenant-and-subnet-identifiers-in-an-hnvv2-overlay-network/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:22+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know How should tenant boundaries be represented when HNVv2 virtual networks reuse IP ranges? ## Potentially affected Use this review for a documented HNVv2 deployment. ## DSE recommendation Maintain a mapping that records tenant ownership and overlay identifiers alongside address ranges. ## Article ## Source facts The implementation described by this Microsoft source is HNVv2. Microsoft models a Hyper-V Network Virtualization customer as an owner of one or more virtual networks, each containing virtual subnets. HNV uses NVGRE or VXLAN encapsulation to isolate overlay networks, allowing different tenants to use overlapping IP subnets. A virtual subnet supplies Layer 3 subnet semantics and a broadcast domain, with isolation associated with an NVGRE TNI or VXLAN VNI. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/sdn/technologies/hyper-v-network-virtualization/hyperv-network-virtualization-technical-details-windows-server). ## Applicability Use this review for a documented HNVv2 deployment. Identify the tenant, virtual network, subnet, and encapsulation in use before interpreting an IP address or troubleshooting a connection. Verify the current platform requirements for that design. ## DSE recommendation Maintain a mapping that records tenant ownership and overlay identifiers alongside address ranges. Have the network owner inspect any reused address ranges and confirm their intended isolation boundaries. Include both permitted intra-tenant paths and prohibited cross-tenant paths in the test plan. Preserve the mapping with the configuration so operational records do not depend on IP addresses alone. ## Verification Test representative connections within an intended virtual network and across a boundary that should remain isolated. Record the tenant and overlay context for every result. Compare the observed path with the approved mapping and investigate a misplaced identifier before changing application addressing. Update the map after any accepted network change. ## Official references [Microsoft Learn: Hyper-V Network Virtualization Technical Details in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/sdn/technologies/hyper-v-network-virtualization/hyperv-network-virtualization-technical-details-windows-server). Source reviewed September 8, 2026. ## Primary reference - Name: Hyper-V Network Virtualization Technical Details in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/sdn/technologies/hyper-v-network-virtualization/hyperv-network-virtualization-technical-details-windows-server - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Document tenant and subnet identifiers in an HNVv2 overlay network,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-049-document-tenant-and-subnet-identifiers-in-an-hnvv2-overlay-network/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Document the capability claims behind an enhanced state mitigation plan > Use 44 CFR 201.5 - Enhanced State Mitigation Plans to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/document-the-capability-claims-behind-an-enhanced-state-mitigation-plan/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:25+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 44 CFR 201.5 - Enhanced State Mitigation Plans to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 44 CFR 201.5 - Enhanced State Mitigation Plans ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Document the capability claims behind an enhanced state mitigation plan. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [44 CFR 201.5 – Enhanced State Mitigation Plans](https://www.ecfr.gov/current/title-44/section-201.5) from Federal Emergency Management Agency via eCFR supports the following bounded statements: - Under 44 CFR 201, the rule requires that enhanced State Mitigation Plans include all elements of the Standard State Mitigation Plan identified in section 201.4, as well as document the following: documentation of the State’s project implementation capability, identifying and demonstrating the ability to implement the plan, including: established eligibility criteria for multi-hazard mitigation measures. The research record locates this support at 44 CFR 201.5(b)(2)(i), read with 44 CFR 201.5(b)(2) and 44 CFR 201.5(b) (eCFR anchor p-201.5(b)(2)(i)). - Under 44 CFR 201, the rule requires that the Enhanced State Mitigation Plan demonstrate that a State has developed a comprehensive mitigation program, that the State effectively uses available mitigation funding, and that it is capable of managing the increased funding. The research record locates this support at 44 CFR 201.5(a) (eCFR anchor p-201.5(a)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives only where the source and recorded environment align. ## What the source does not establish Federal hazard-mitigation regulation for states; funding percentages, approval period, Stafford Act context, current FEMA programs, plan review, and disaster declaration details require rechecking. No current deployment state or change approval follows from the source alone. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 44 CFR 201.5(b)(2)(i), read with 44 CFR 201.5(b)(2) and 44 CFR 201.5(b) (eCFR anchor p-201.5(b)(2)(i)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 44 CFR 201.5(a) (eCFR anchor p-201.5(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from 44 CFR 201.5(b)(2)(i), read with 44 CFR 201.5(b)(2) and 44 CFR 201.5(b) (eCFR anchor p-201.5(b)(2)(i)); 44 CFR 201.5(a) (eCFR anchor p-201.5(a)) through business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [44 CFR 201.5 – Enhanced State Mitigation Plans](https://www.ecfr.gov/current/title-44/section-201.5) — Federal Emergency Management Agency via eCFR ## Primary reference - Name: 44 CFR 201.5 - Enhanced State Mitigation Plans - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-44/section-201.5 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Document the capability claims behind an enhanced state mitigation plan,” DSE Security, https://update.dsesecurity.com/updates/document-the-capability-claims-behind-an-enhanced-state-mitigation-plan/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Document vulnerabilities, countermeasures, and constraints in the Facility Security Assessment > Use 33 CFR 105.305 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/document-vulnerabilities-countermeasures-and-constraints-in-the-facility-security-assessment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:57+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.305 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.305 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Document vulnerabilities, countermeasures, and constraints in the Facility Security Assessment. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.305 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.305) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that the facility owner or operator ensure that the following background information, if applicable, is provided to the person or persons who will conduct the assessment: previous reports on security needs. The research record locates this support at 33 CFR 105.305(a)(9), read with 33 CFR 105.305(a) (eCFR anchor p-105.305(a)(9)). - Under 33 CFR 105, the rule requires that the facility owner or operator ensure that the following background information, if applicable, is provided to the person or persons who will conduct the assessment: response capability to security incidents. The research record locates this support at 33 CFR 105.305(a)(7), read with 33 CFR 105.305(a) (eCFR anchor p-105.305(a)(7)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths only where the source and recorded environment align. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.305(a)(9), read with 33 CFR 105.305(a) (eCFR anchor p-105.305(a)(9)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.305(a)(7), read with 33 CFR 105.305(a) (eCFR anchor p-105.305(a)(7)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from 33 CFR 105.305(a)(9), read with 33 CFR 105.305(a) (eCFR anchor p-105.305(a)(9)); 33 CFR 105.305(a)(7), read with 33 CFR 105.305(a) (eCFR anchor p-105.305(a)(7)) through asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [33 CFR 105.305 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.305) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.305 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.305 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Document vulnerabilities, countermeasures, and constraints in the Facility Security Assessment,” DSE Security, https://update.dsesecurity.com/updates/document-vulnerabilities-countermeasures-and-constraints-in-the-facility-security-assessment/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Document why energized electrical work could not be avoided > Use 29 CFR 1910.333 - Selection and use of work practices to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/document-why-energized-electrical-work-could-not-be-avoided/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:12+00:00 - Modified: 2026-08-27T13:06:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.333 - Selection and use of work practices to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.333 - Selection and use of work practices ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Document why energized electrical work could not be avoided. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.333 – Selection and use of work practices](https://www.ecfr.gov/current/title-29/section-1910.333) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, if the exposed live parts are not deenergized (i.e., for reasons of increased or additional hazards or infeasibility), other safety-related work practices must be used to protect employees who may be exposed to the electrical hazards involved. The research record locates this support at 29 CFR 1910.333(a)(2) (eCFR anchor p-1910.333(a)(2)). - Under 29 CFR 1910, conductors and parts of electric equipment that have been deenergized but have not been locked out or tagged in accordance with paragraph (b) of this section must be treated as energized parts, and paragraph (c) of this section applies to work on or near them. The research record locates this support at 29 CFR 1910.333(b)(1) (eCFR anchor p-1910.333(b)(1)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths only where the source and recorded environment align. ## What the source does not establish Federal workplace rule; qualified-person status, task, voltage, lockout and tagging, and electrical-safety standards require competent evaluation. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 29 CFR 1910.333(a)(2) (eCFR anchor p-1910.333(a)(2)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.333(b)(1) (eCFR anchor p-1910.333(b)(1)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations 29 CFR 1910.333(a)(2) (eCFR anchor p-1910.333(a)(2)); 29 CFR 1910.333(b)(1) (eCFR anchor p-1910.333(b)(1)) adjacent to the sanitized artifacts used for comparison. Prefer facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [29 CFR 1910.333 – Selection and use of work practices](https://www.ecfr.gov/current/title-29/section-1910.333) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.333 - Selection and use of work practices - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.333 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Document why energized electrical work could not be avoided,” DSE Security, https://update.dsesecurity.com/updates/document-why-energized-electrical-work-could-not-be-avoided/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Drive QUIC loss detection from acknowledgments without conflating congestion control > Use RFC 9002 — QUIC Loss Detection and Congestion Control to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/drive-quic-loss-detection-from-acknowledgments-without-conflating-congestion-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:56+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 9002 — QUIC Loss Detection and Congestion Control to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 9002 — QUIC Loss Detection and Congestion Control ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Drive QUIC loss detection from acknowledgments without conflating congestion control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 9002 — QUIC Loss Detection and Congestion Control](https://www.rfc-editor.org/rfc/rfc9002.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - QUIC declares an in-flight packet lost only after a later packet is acknowledged and either the packet threshold or time threshold is met. The research record locates this support at Section 6.1 (Acknowledgment-Based Detection). - A Probe Timeout sends one or two probe datagrams, but expiration alone does not indicate loss and must not mark prior unacknowledged packets lost. The research record locates this support at Section 6.2 (Probe Timeout). - ACK-only packets do not count toward bytes in flight and are not congestion controlled, even though QUIC can detect when they are lost. The research record locates this support at Section 7 (Congestion Control). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 6.1 (Acknowledgment-Based Detection), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 6.2 (Probe Timeout), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 7 (Congestion Control), which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify DNS, certificates, identity providers, time, content delivery, network paths, and application ownership. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from Section 6.1 (Acknowledgment-Based Detection); Section 6.2 (Probe Timeout); Section 7 (Congestion Control) to the observed environment. Useful domain evidence includes request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 9002 — QUIC Loss Detection and Congestion Control](https://www.rfc-editor.org/rfc/rfc9002.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 9002 — QUIC Loss Detection and Congestion Control - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9002.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Drive QUIC loss detection from acknowledgments without conflating congestion control,” DSE Security, https://update.dsesecurity.com/updates/drive-quic-loss-detection-from-acknowledgments-without-conflating-congestion-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Drop source addresses that cannot legitimately arrive on an ingress interface > Use RFC 2827 — Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/drop-source-addresses-that-cannot-legitimately-arrive-on-an-ingress-interface/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:31+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2827 — Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2827 — Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Drop source addresses that cannot legitimately arrive on an ingress interface. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2827 — Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing](https://www.rfc-editor.org/rfc/rfc2827.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An aggregation edge restricts downstream transit traffic to source prefixes that the downstream network intentionally advertises, rejecting sources outside those prefixes. The research record locates this support at Sections 1 (Introduction) and 3 (Restricting forged traffic). - Administrators should log packets rejected by an ingress source-address filter so suspicious activity can be monitored. The research record locates this support at Section 3 (Restricting forged traffic), dropped-packet logging. - A remote-access server can admit only the address assigned to a single-host customer, while strict return-interface validation is unsuitable where Internet paths are asymmetric. The research record locates this support at Section 4 (Further possible capabilities for networking equipment). The source support ends with the statements listed above. Use them to examine address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Sections 1 (Introduction) and 3 (Restricting forged traffic), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Restricting forged traffic), dropped-packet logging, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4 (Further possible capabilities for networking equipment), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from Sections 1 (Introduction) and 3 (Restricting forged traffic); Section 3 (Restricting forged traffic), dropped-packet logging; Section 4 (Further possible capabilities for networking equipment) through configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 2827 — Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing](https://www.rfc-editor.org/rfc/rfc2827.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2827 — Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2827.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Drop source addresses that cannot legitimately arrive on an ingress interface,” DSE Security, https://update.dsesecurity.com/updates/drop-source-addresses-that-cannot-legitimately-arrive-on-an-ingress-interface/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Embed reliability, authenticity, integrity, usability, and disposition in electronic records systems > Use 36 CFR 1236.10 - Controls for electronic information systems to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/embed-reliability-authenticity-integrity-usability-and-disposition-in-electronic-records-systems/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:28+00:00 - Modified: 2026-08-27T13:07:00+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 36 CFR 1236.10 - Controls for electronic information systems to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 36 CFR 1236.10 - Controls for electronic information systems ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Embed reliability, authenticity, integrity, usability, and disposition in electronic records systems. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [36 CFR 1236.10 – Controls for electronic information systems](https://www.ecfr.gov/current/title-36/section-1236.10) from National Archives and Records Administration via eCFR supports the following bounded statements: - Under 36 CFR 1236, agencies must establish integrity controls, such as audit trails, so records in electronic information systems remain complete and unaltered. The research record locates this support at 36 CFR 1236.10(c), read with the unnumbered introductory paragraph of 36 CFR 1236.10 (eCFR anchor p-1236.10(c)). - Under 36 CFR 1236, agencies must use structure controls that preserve records’ physical and logical formats and the relationships among their data elements. The research record locates this support at 36 CFR 1236.10(g), read with the unnumbered introductory paragraph of 36 CFR 1236.10 (eCFR anchor p-1236.10(g)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives and the conditions the source actually describes. ## What the source does not establish Federal agency records-management regulation; system scope, record status, schedules, metadata, security, privacy, migrations, and NARA guidance require records-professional review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 36 CFR 1236.10(c), read with the unnumbered introductory paragraph of 36 CFR 1236.10 (eCFR anchor p-1236.10(c)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 36 CFR 1236.10(g), read with the unnumbered introductory paragraph of 36 CFR 1236.10 (eCFR anchor p-1236.10(g)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations 36 CFR 1236.10(c), read with the unnumbered introductory paragraph of 36 CFR 1236.10 (eCFR anchor p-1236.10(c)); 36 CFR 1236.10(g), read with the unnumbered introductory paragraph of 36 CFR 1236.10 (eCFR anchor p-1236.10(g)) adjacent to the sanitized artifacts used for comparison. Prefer business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [36 CFR 1236.10 – Controls for electronic information systems](https://www.ecfr.gov/current/title-36/section-1236.10) — National Archives and Records Administration via eCFR ## Primary reference - Name: 36 CFR 1236.10 - Controls for electronic information systems - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-36/section-1236.10 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Embed reliability, authenticity, integrity, usability, and disposition in electronic records systems,” DSE Security, https://update.dsesecurity.com/updates/embed-reliability-authenticity-integrity-usability-and-disposition-in-electronic-records-systems/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Emit machine-readable message and recipient delivery-status fields > Use RFC 3464 — An Extensible Message Format for Delivery Status Notifications to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:03+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3464 — An Extensible Message Format for Delivery Status Notifications to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3464 — An Extensible Message Format for Delivery Status Notifications ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Emit machine-readable message and recipient delivery-status fields. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3464 — An Extensible Message Format for Delivery Status Notifications](https://www.rfc-editor.org/rfc/rfc3464.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A delivery-status notification is a multipart/report with report-type delivery-status, a human-readable part, and a message/delivery-status part; returned original content is optional. The research record locates this support at Section 2 (Format of a Delivery Status Notification). - The message/delivery-status body places its per-message fields first, followed by one or more blank-line-separated groups of per-recipient fields. The research record locates this support at Section 2.1 (The message/delivery-status content-type). - Each recipient group identifies the final recipient and records the delivery action and status, with optional diagnostic and retry fields. The research record locates this support at Section 2.3 (Per-Recipient DSN fields). Keep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 2 (Format of a Delivery Status Notification), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.1 (The message/delivery-status content-type), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2.3 (Per-Recipient DSN fields), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations Section 2 (Format of a Delivery Status Notification); Section 2.1 (The message/delivery-status content-type); Section 2.3 (Per-Recipient DSN fields) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 3464 — An Extensible Message Format for Delivery Status Notifications](https://www.rfc-editor.org/rfc/rfc3464.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 3464 — An Extensible Message Format for Delivery Status Notifications - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3464.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Emit machine-readable message and recipient delivery-status fields,” DSE Security, https://update.dsesecurity.com/updates/emit-machine-readable-message-and-recipient-delivery-status-fields/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enable AD Recycle Bin before relying on object-level recovery > Use Enable Active Directory Recycle Bin in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/enable-ad-recycle-bin-before-object-recovery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:19+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Enable Active Directory Recycle Bin in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Enable Active Directory Recycle Bin in Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Enable AD Recycle Bin before relying on object-level recovery. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Enable Active Directory Recycle Bin in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/active-directory-recycle-bin) from Microsoft supports the following bounded statements: - AD Recycle Bin preserves link-valued and non-link-valued attributes of deleted AD objects. The research record locates this support at Opening overview. - A restored user can regain the group memberships and access rights held immediately before deletion. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Recycle Bin is object recovery, not a substitute for system-state backup or forest recovery. No current deployment state or change approval follows from the source alone. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Enable Active Directory Recycle Bin in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/active-directory-recycle-bin) — Microsoft ## Primary reference - Name: Enable Active Directory Recycle Bin in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/adac/active-directory-recycle-bin - Source publication date: 2025-06-06 ## Citation and use Preferred citation: “Enable AD Recycle Bin before relying on object-level recovery,” DSE Security, https://update.dsesecurity.com/updates/enable-ad-recycle-bin-before-object-recovery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enable and attest System Guard Secure Launch on supported processors > Use System Guard Secure Launch and SMM protection to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/enable-and-attest-system-guard-secure-launch/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:52+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Use System Guard Secure Launch and SMM protection to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of System Guard Secure Launch and SMM protection ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Enable and attest System Guard Secure Launch on supported processors. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [System Guard Secure Launch and SMM protection](https://learn.microsoft.com/en-us/windows/security/hardware-security/system-guard-secure-launch-and-smm-protection) from Microsoft supports the following bounded statements: - System Guard Secure Launch and SMM protection improve Windows startup security. The research record locates this support at Opening overview. - Secure Launch requires a supported processor and Microsoft documents how to verify that it is configured and running. The research record locates this support at Opening overview; section: How to verify. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows only where the source and recorded environment align. ## What the source does not establish Treat enablement and runtime verification as separate acceptance checks. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview; section: How to verify, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations Opening overview; Opening overview; section: How to verify adjacent to the sanitized artifacts used for comparison. Prefer policy and feature state, security events, test detections, administrative assignments, exception approvals, and response tickets, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [System Guard Secure Launch and SMM protection](https://learn.microsoft.com/en-us/windows/security/hardware-security/system-guard-secure-launch-and-smm-protection) — Microsoft ## Primary reference - Name: System Guard Secure Launch and SMM protection - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/hardware-security/system-guard-secure-launch-and-smm-protection - Source publication date: 2025-08-15 ## Citation and use Preferred citation: “Enable and attest System Guard Secure Launch on supported processors,” DSE Security, https://update.dsesecurity.com/updates/enable-and-attest-system-guard-secure-launch/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enable BitLocker with Intune only after recovery is proven > Intune can deploy standard or silent BitLocker encryption, but production readiness depends on supported hardware, usable recovery-key escrow, policy compatibility, and removal of conflicting encryption software. - Canonical URL: https://update.dsesecurity.com/updates/intune-bitlocker-recovery-first-deployment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:53+00:00 - Modified: 2026-07-19T21:27:53+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 2 minutes ## What you need to know Intune can deploy standard or silent BitLocker encryption, but production readiness depends on supported hardware, usable recovery-key escrow, policy compatibility, and removal of conflicting encryption software. ## Potentially affected Supported Windows devices managed by Microsoft Intune, especially organizations planning silent encryption or migrating from third-party full-disk encryption. ## DSE recommendation Inventory encryption and hardware prerequisites, define restricted recovery access, verify key escrow and recovery on a pilot, remove conflicts, and expand only after reporting confirms success. ## Article ## Source fact: what Microsoft documents Microsoft Intune supports standard BitLocker, where users can see and interact with prompts, and silent BitLocker, which can encrypt a managed device without user interaction or local administrative rights. Microsoft identifies Endpoint security > Disk encryption as the focused policy surface and provides an encryption report for device status and recovery-key management. For silent encryption, Microsoft documents supported Windows versions, Microsoft Entra join or hybrid join, TPM 1.2 or later, native UEFI, Secure Boot, and a configured Windows Recovery Environment. Silent enablement cannot require a TPM startup PIN or startup key because those require user interaction. Some Microsoft security-baseline settings can conflict by enabling those startup requirements. Microsoft warns that suppressing the warning for other disk-encryption software allows BitLocker to continue even when another product is present. The result can include data loss, instability, boot failures, and complex recovery. Microsoft therefore directs administrators to identify and safely remove third-party encryption before silent deployment and to pilot representative devices. ## Licensing and applicability Applicable Intune licensing and a Windows edition that supports BitLocker management are required. Some settings require a supported TPM. Windows 10 reached end of support on 2025-10-14; although it can remain enrolled in Intune, Microsoft does not guarantee continuing functionality. Hardware capability, modern standby, policy type, recovery configuration, and user privilege affect encryption behavior. Personal Data Encryption on Windows 11 is a separate file-level feature and is not a replacement for BitLocker. ## DSE recommendation: production-safe operational steps - Inventory Windows version and edition, join state, TPM, UEFI, Secure Boot, WinRE, modern-standby capability, current encryption, and every third-party encryption agent. - Define the recovery-key escrow location, authorized retrieval roles, identity-verification process, audit review, and post-recovery key rotation before enabling encryption. - Resolve duplicate BitLocker settings across Endpoint security, device configuration, security baselines, Group Policy, and scripts. Use one documented authority where possible. - Select representative pilot devices, including older hardware, standard users, remote users, and devices with important applications. - Verify key escrow before restart. Perform a controlled recovery test using the supported process, then confirm access and audit evidence. - Deploy the intended standard or silent policy, monitor encryption and error reports, and validate boot, sign-in, application, update, and remote-support workflows. - Expand in rings only after recovery and business-function exit criteria pass. Stop on unexplained missing keys, conflicting encryption, or boot failures. DSE recommends never using an encryption-status percentage as the only success measure. A production-safe result requires encrypted devices, retrievable keys, authorized recovery, healthy restarts, and a tested response when a user reaches the recovery screen. ## Official reference [Encrypt Windows devices with BitLocker using Intune](https://learn.microsoft.com/en-us/intune/device-configuration/endpoint-security/encrypt-bitlocker-windows) — policy types, silent-encryption prerequisites, conflicts, reporting, and recovery planning. ## Primary reference - Name: Microsoft Learn: Encrypt Windows devices with BitLocker using Intune - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/intune/device-configuration/endpoint-security/encrypt-bitlocker-windows - Source publication date: 2026-04-15 ## Citation and use Preferred citation: “Enable BitLocker with Intune only after recovery is proven,” DSE Security, https://update.dsesecurity.com/updates/intune-bitlocker-recovery-first-deployment/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enable command-line detail in native process-creation auditing > Use Command line process auditing to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/enable-command-line-detail-in-process-creation-auditing/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:57+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Command line process auditing to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Command line process auditing ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Enable command-line detail in native process-creation auditing. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Command line process auditing](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing) from Microsoft supports the following bounded statements: - Event 4688 can include the command line used to create a process. The research record locates this support at Section: Overview. - Both Audit Process Creation and the policy to include command lines in process-creation events must be enabled. The research record locates this support at Section: Configuration. Keep the evidence boundary at these traced claims. They support a review of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Command lines can expose sensitive values; define access, retention, and redaction before collection. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section: Overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section: Configuration, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Section: Overview; Section: Configuration through directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Command line process auditing](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing) — Microsoft ## Primary reference - Name: Command line process auditing - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/command-line-process-auditing - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Enable command-line detail in native process-creation auditing,” DSE Security, https://update.dsesecurity.com/updates/enable-command-line-detail-in-process-creation-auditing/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enable Credential Guard only after testing authentication dependencies > Windows Credential Guard isolates selected secrets with virtualization-based security, but legacy protocols, delegation, security packages, remote access, firmware, virtualization, and applications can change behavior. Discover and pilot before enforcement. - Canonical URL: https://update.dsesecurity.com/updates/enable-credential-guard-after-testing-authentication-dependencies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:58:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Windows Credential Guard isolates selected secrets with virtualization-based security, but legacy protocols, delegation, security packages, remote access, firmware, virtualization, and applications can change behavior. Discover and pilot before enforcement. ## Potentially affected Supported Windows 10, Windows 11 and Windows Server devices; virtualization-based security, Secure Boot and TPM; Kerberos, NTLM, Credential Manager, CredSSP, delegation, RDP, VPN and Wi-Fi authentication; security packages; hypervisors; help desk; and recovery. ## DSE recommendation Confirm supported hardware and operating systems, inventory authentication and credential dependencies, establish a compatible firmware and virtualization baseline, pilot representative devices and workflows, collect errors and user impact, remediate dependencies, stage enforcement, and retain recovery procedures. ## Article ## Source facts: Credential Guard changes how selected credentials are available Microsoft’s [Credential Guard considerations and known-issues guidance](https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues) documents compatibility implications and scenarios that require planning. Credential Guard uses virtualization-based security, and enabling or disabling it can interact with operating-system defaults, policy, firmware, virtual machines, and deployment method. Microsoft’s [technical overview](https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/how-it-works) explains that isolated LSA stores selected Kerberos, NTLM, and Credential Manager secrets outside the ordinary operating-system process using VBS. It also states protection limits. Credential Guard does not protect credentials managed outside Windows protections, keyloggers, physical attacks, the Active Directory database on a domain controller, or every credential supplied to legacy authentication. The documentation describes protocol effects: certain uses of NTLMv1, MS-CHAPv2, Digest, CredSSP, unconstrained delegation, and DES can no longer use signed-in credentials as before. Exact defaults, hardware requirements, support, and behavior vary by Windows edition, version, device role, virtualization platform, and policy. Review current Microsoft and product-vendor documentation for the target fleet. ## DSE recommendation: use deployment to expose and retire weak dependencies Do not begin by forcing the policy across the fleet. Build a readiness inventory that connects devices to business workflows and authentication dependencies. Include privileged workstations, standard laptops, shared workstations, kiosks, jump hosts, servers used interactively, virtual desktops, VPN, Wi-Fi, RDP, file and print, line-of-business applications, smart cards, third-party credential providers, endpoint security, and backup or recovery tools. - Confirm platform readiness. Verify supported Windows edition and build, firmware, Secure Boot, virtualization extensions, TPM state where applicable, VBS and hypervisor compatibility, driver and security-software support, and virtual-machine configuration. Remediate unsupported firmware and drivers before attributing failures to authentication. - Find legacy protocols. Use approved directory, network, endpoint, and application evidence to identify NTLM versions, MS-CHAPv2, Digest, CredSSP, unconstrained delegation, DES, saved credentials, and non-Microsoft security packages. Validate each dependency with its owner; a log event does not by itself prove safe removal. - Define the pilot. Include each hardware model, Windows build, user type, location, network, privileged workflow, remote-access method, and critical application. Provide a control group, change window, support contact, stop threshold, and documented recovery that does not require an unavailable credential path. - Exercise real workflows. Test sign-in with and without domain connectivity, lock and unlock, password and authenticator change, VPN, Wi-Fi, RDP, file shares, print, administration, application single sign-on, scheduled work, sleep, hibernate, restart, patching, and disaster-recovery access. Include help-desk and break-glass procedures. - Observe and remediate. Collect supported Credential Guard state, VBS status, authentication events, application and driver errors, help-desk cases, latency, and fallback authentication. Fix the protocol or application where possible rather than creating broad exclusions that restore credential exposure. - Stage enforcement. Expand by well-understood rings, monitor after each wave, and pause on systemic failure. Keep policy ownership and rollback controlled. A device that reports the feature enabled but cannot perform its required recovery path is not production-ready. Separate Credential Guard from Remote Credential Guard, LSA protection, Windows Hello, and other related features in design and test records; they have different requirements and boundaries. Protect the hypervisor and host of virtual machines, because in-guest isolation does not defend against a privileged host attack. Retest after major Windows, firmware, hypervisor, VPN, security-agent, or application changes. The completion record should list supported devices, workflows exercised, remaining legacy dependencies, exceptions, and recovery results. Credential Guard reduces specific credential-theft paths; it is not a substitute for privileged-access separation, patching, phishing resistance, endpoint protection, or least privilege. Use an exit gate for every deployment ring: all required workflows pass, recovery was demonstrated, state reporting is reliable, support can recognize known errors, and every exception has an owner and end condition. Stop on widespread fallback prompts, lost remote administration, incompatible security software, or inability to boot and recover. Preserve diagnostic evidence, restore the approved configuration, remediate the dependency, and rerun the full ring. ## Official references - Microsoft, [Considerations and known issues when using Credential Guard](https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues). - Microsoft, [How Credential Guard works](https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/how-it-works). ## Primary reference - Name: Microsoft Learn: Considerations and known issues when using Credential Guard - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/considerations-known-issues - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Enable Credential Guard only after testing authentication dependencies,” DSE Security, https://update.dsesecurity.com/updates/enable-credential-guard-after-testing-authentication-dependencies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enable DNSSEC validation without mistaking authentication for encryption > DNSSEC validation can authenticate signed DNS data and detect certain tampering, but it does not encrypt queries or certify that a destination is safe. Deploy it with measured resolver tests and failure handling. - Canonical URL: https://update.dsesecurity.com/updates/enable-dnssec-validation-authentication-not-encryption/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:20:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know DNSSEC validation can authenticate signed DNS data and detect certain tampering, but it does not encrypt queries or certify that a destination is safe. Deploy it with measured resolver tests and failure handling. ## Potentially affected Recursive DNS resolvers; forwarders; trust anchors; firewalls; branch networks; VPN clients; cloud DNS; monitoring; applications with unusual DNS behavior; and incident-response procedures. ## DSE recommendation Inventory every resolver path, enable validation in stages, confirm trust-anchor maintenance, test valid, unsigned, and deliberately broken domains, monitor SERVFAIL behavior, document exceptions, and preserve a controlled recovery path. ## Article ## Source facts: DNSSEC validates signed DNS data [NIST SP 800-81 Rev. 3](https://csrc.nist.gov/pubs/sp/800/81/r3/final) provides current guidance for secure Domain Name System deployment. It describes DNSSEC as a mechanism that uses digital signatures and a chain of trust to provide origin authentication and integrity for DNS data. A validating recursive resolver evaluates signed responses and treats a response as bogus when required validation fails. RFC 9364 is a roadmap to the DNSSEC standards and operational documents. It identifies the core RFCs for signing, serving, resolving, and authenticating DNSSEC-signed data and points implementers and operators to later updates and operational guidance. ICANN maintains a page that helps operators check whether recursive resolvers are using current root trust anchors, an important dependency for validation of the root trust chain. DNSSEC does not encrypt a DNS question or response. It does not hide the requested name from the resolver or network path, and it does not prove that an authenticated destination is benign. It also cannot authenticate an unsigned zone through a signed chain. Encrypted DNS transports, application-layer TLS, reputation controls, filtering, and secure endpoint behavior solve different problems. ## DSE recommendation: deploy validation as a measured resolver change Make the resolver path visible before changing it. A successful pilot should prove both that valid signed domains resolve and that intentionally broken signatures fail in an understandable, supportable way. - Inventory resolution paths. Identify recursive resolvers, forwarders, branch appliances, domain controllers, VPN configurations, cloud networks, guest systems, security products, and endpoints that bypass approved DNS. Record which component performs validation and where responses can be altered or cached. - Confirm resolver readiness. Review the implementation and current vendor guidance, enable automatic trust-anchor maintenance where supported, secure administrative access, synchronize time, patch the platform, and verify adequate capacity. Do not assume that a DNSSEC checkbox means every forwarded response is validated locally. - Build a test matrix. Test correctly signed names, unsigned names, nonexistent names, expired or broken signatures, large responses, TCP fallback, IPv4 and IPv6, VPN and branch paths, and applications that use embedded resolvers. Record the response code, latency, validating resolver, and user-visible behavior. - Stage by population. Start with technical users and representative sites, then expand through controlled change windows. Keep comparison telemetry from a known resolver path. Coordinate with helpdesk teams so validation failures are not misdiagnosed as generic internet outages. - Monitor failure meaning. Track SERVFAIL increases, validation errors, timeouts, trust-anchor status, cache health, upstream behavior, and affected names. Preserve query metadata consistent with privacy and retention requirements. Alert on a resolver silently operating without validation after configuration or software change. - Govern exceptions. A negative trust anchor or other bypass can restore access to a misconfigured signed zone, but it weakens validation for that namespace. Require an owner, evidence, narrow scope, expiration, periodic review, and removal when the zone is repaired. Never normalize permanent bypasses as routine operations. - Prepare recovery. Keep versioned resolver configuration, tested rollback, alternate validated resolvers, contact paths for authoritative-zone owners, and clear escalation. Exercise trust-anchor and upstream failures without disabling security globally as the first troubleshooting step. Factual boundary: Validation can fail because an authoritative zone, signing process, network path, clock, resolver, or trust anchor is wrong. A validation failure is not automatically evidence of an attack. Conversely, a validated answer authenticates signed DNS data; it does not attest to the security or ownership of the service reached. Useful measures include the percentage of clients using approved validating resolvers, validation success and failure rates, trust-anchor freshness, bypass age, resolver latency, TCP fallback, and time to diagnose a bogus domain. A sound rollout improves DNS authenticity without making broader claims about confidentiality or destination safety. ## Official references - NIST, [Secure Domain Name System (DNS) Deployment Guide](https://csrc.nist.gov/pubs/sp/800/81/r3/final), SP 800-81 Rev. 3, March 19, 2026. - IETF, [DNS Security Extensions (DNSSEC)](https://www.rfc-editor.org/rfc/rfc9364.html), RFC 9364. - ICANN, [DNS Resolvers Checking Current Trust Anchors](https://www.icann.org/dns-resolvers-checking-current-trust-anchors/). ## Primary reference - Name: IETF RFC 9364: DNS Security Extensions (DNSSEC) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9364.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Enable DNSSEC validation without mistaking authentication for encryption,” DSE Security, https://update.dsesecurity.com/updates/enable-dnssec-validation-authentication-not-encryption/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enable Key Vault purge protection only after choosing a recoverability window > Key Vault soft delete makes deleted vaults and objects recoverable for a retention period, while purge protection prevents permanent purge during that period and cannot be disabled after enablement. - Canonical URL: https://update.dsesecurity.com/updates/azure-key-vault-purge-protection-recovery-window/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:00+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Key Vault soft delete makes deleted vaults and objects recoverable for a retention period, while purge protection prevents permanent purge during that period and cannot be disabled after enablement. ## Potentially affected Azure environments storing production keys, secrets, or certificates in Key Vault. ## DSE recommendation Select retention from recovery requirements, enable purge protection for production vaults through governed deployment, separate purge and recovery authority, and exercise object recovery. ## Article Bottom line: Azure Key Vault soft delete retains deleted vaults and objects for a configured period so they can be recovered. Purge protection prevents permanent deletion during that retention period. Microsoft states that purge protection cannot be disabled or overridden once enabled. Choose the retention and recovery operating model before production enforcement. ## Source fact: what Microsoft documents Microsoft’s [Key Vault recovery overview](https://learn.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery) distinguishes soft delete from purge protection. Soft delete places a deleted vault, key, secret, or certificate into a recoverable state for a configurable retention period. Names remain reserved while the corresponding object is soft-deleted, subject to the documented naming scope. Purge protection prevents permanent purge until the retention period has elapsed. Microsoft states that no administrator and not even Microsoft can override or disable purge protection once it is enabled. After retention ends, deletion completes according to the service behavior. Recovery and purge require appropriate permissions, and linked Azure services can have additional recovery steps because role assignments, Event Grid subscriptions, or other integrations might not be restored automatically. ## What the source does not establish Soft delete does not protect a secret from authorized reading, stop use of a compromised key, maintain application availability after deletion, or replace backup and configuration evidence. Recovery of a vault object does not necessarily restore dependent application configuration or permissions. Purge protection can also delay legitimate name reuse or decommissioning; the retention window is an operational constraint, not only a security benefit. ## Applicability questions - Which keys, secrets, certificates, applications, managed identities, and services depend on each vault? - What deletion-detection and recovery time is required, and what retention period supports it? - Who can delete, recover, purge, change retention-related settings, and modify access? - Which role assignments, network rules, private endpoints, Event Grid subscriptions, or integrations must be recreated after recovery? - Is the vault production, test, ephemeral, or subject to a legal deletion requirement? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Inventory vault dependencies and select retention from incident detection, recovery, and legitimate decommissioning needs. - Enable purge protection for production through infrastructure as code or a governed change, recognizing that it cannot later be disabled. - Separate routine object administration from deletion, purge, and recovery authority and alert on those operations. - Exercise key, secret, certificate, and vault recovery in a safe scope, including recreation of dependent permissions and integrations. - Preserve independent configuration and application-recovery procedures; do not rely on the recycle state as the complete recovery plan. ## Verification and evidence - Preserve vault retention, soft-delete and purge-protection state, role assignments, dependencies, and approval. - Record deletion and recovery tests with timestamps and object identifiers but never secret values or private keys. - Verify applications can use the recovered object and that network and permission dependencies are restored. - Monitor delete, recover, purge, and access-policy or RBAC changes through protected logging. ## Official references - [Azure Key Vault recovery overview](https://learn.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery) — Microsoft ## Primary reference - Name: Azure Key Vault recovery overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/key-vault/general/key-vault-recovery - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Enable Key Vault purge protection only after choosing a recoverability window,” DSE Security, https://update.dsesecurity.com/updates/azure-key-vault-purge-protection-recovery-window/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enable QNAME minimisation as one DNS privacy layer > Reduce unnecessary query-name disclosure from recursive resolvers while preserving a tested compatibility and fallback path. - Canonical URL: https://update.dsesecurity.com/updates/enable-qname-minimisation-as-one-dns-privacy-layer/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:46+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Reduce unnecessary query-name disclosure from recursive resolvers while preserving a tested compatibility and fallback path. ## Potentially affected Organizations operating recursive DNS resolvers that query the public or delegated DNS hierarchy ## DSE recommendation Confirm resolver support, test known delegated and atypical domains, then enable QNAME minimisation with failure telemetry. ## Article A recursive resolver usually does not need to disclose a user’s complete original query name to every authoritative server along the delegation path. QNAME minimisation reduces that exposure, but it should be deployed as one privacy control with compatibility monitoring—not described as private DNS by itself. ## Source fact: [IETF RFC 9156](https://www.rfc-editor.org/rfc/rfc9156.html) specifies DNS Query Name Minimisation. Instead of always sending the full original query name and type to each upstream server, a recursive resolver asks for only the portion needed to discover the next delegation. The resolver progressively learns the path and sends the full name to the authority that ultimately needs it. The standard updates earlier guidance and includes behavior intended to work with the deployed DNS. It discusses resolver algorithms, caching, handling unexpected replies, and implementation considerations. The privacy benefit is reduced disclosure of the complete name to unnecessary DNS servers; the RFC does not encrypt DNS packets or hide queries from the recursive resolver, the final authoritative service, or network observers who can infer information from unencrypted traffic. ## Boundary QNAME minimisation is a resolver behavior, not an endpoint or authoritative-server guarantee. Compatibility can be affected by nonconforming DNS servers, unusual delegations, and product-specific fallback choices. DNS-over-TLS, DNS-over-HTTPS, logging minimisation, access controls, and retention policies address different exposure points. Enabling several controls does not establish anonymity. ## Applicability questions - Which resolvers support the current RFC behavior, and is it enabled, disabled, or operating in a compatibility mode? - Are internal namespaces, split-horizon zones, forwarding zones, and DNSSEC validation in the test scope? - What logs identify minimisation-related fallback without recording more query detail than operations needs? - Do critical applications depend on unusual public or partner DNS delegations? - How will a temporary exception be reviewed and removed? ## DSE recommendation: Document the privacy objective and the resolvers in scope. Check the exact product release’s implementation notes and default. In a representative test resolver, compare results with minimisation on and off across internal forwarding, common public names, deep delegations, aliases, DNSSEC-signed domains, negative answers, and business-critical partner services. Observe query traces at controlled authorities when possible to verify what name each layer receives. Roll out by resolver pool with latency, SERVFAIL, fallback, and support-ticket monitoring. Keep a narrow, time-limited exception mechanism for a demonstrably incompatible domain rather than disabling the control globally. Align resolver query logging and retention with the same privacy objective so that reduced upstream disclosure is not offset by unnecessary local collection. ## Verification and evidence Retain the resolver/version matrix, configuration, official product guidance, representative query corpus, packet captures from a controlled test, DNS response comparisons, and exception approvals. Evidence should demonstrate successful resolution and validation where applicable, plus reduced name disclosure at an intermediate authority. Re-run the corpus after major resolver upgrades. ## Official references - [IETF RFC 9156](https://www.rfc-editor.org/rfc/rfc9156.html) ## Primary reference - Name: RFC 9156: DNS Query Name Minimisation to Improve Privacy - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9156.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Enable QNAME minimisation as one DNS privacy layer,” DSE Security, https://update.dsesecurity.com/updates/enable-qname-minimisation-as-one-dns-privacy-layer/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enable-ADOptionalFeature: enable adoptional feature under AD/DNS change control > Use Enable-ADOptionalFeature to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/enable-adoptionalfeature-enable-adoptional-feature-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:15+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Enable-ADOptionalFeature to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Enable-ADOptionalFeature ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Enable-ADOptionalFeature: enable adoptional feature under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Enable-ADOptionalFeature](https://learn.microsoft.com/en-us/powershell/module/activedirectory/enable-adoptionalfeature?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Enable-ADOptionalFeature cmdlet enables an Active Directory optional feature that is associated with a particular domain mode or forest mode.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “Active Directory optional features that depend on a specified domain mode or forest mode must be explicitly enabled after the domain mode or forest mode is set.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-191 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Enable-ADOptionalFeature](https://learn.microsoft.com/en-us/powershell/module/activedirectory/enable-adoptionalfeature?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Enable-ADOptionalFeature - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/enable-adoptionalfeature?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Enable-ADOptionalFeature: enable adoptional feature under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/enable-adoptionalfeature-enable-adoptional-feature-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enable-DnsServerPolicy: enable dns server policy with rollback checks > Use Enable-DnsServerPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/enable-dnsserverpolicy-enable-dns-server-policy-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:09+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Enable-DnsServerPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Enable-DnsServerPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Enable-DnsServerPolicy: enable dns server policy with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Enable-DnsServerPolicy](https://learn.microsoft.com/en-us/powershell/module/dnsserver/enable-dnsserverpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Enable-DnsServerPolicy cmdlet enables Domain Name System (DNS) server policies.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can enable both query resolution policies and zone transfer policies.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-257 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Enable-DnsServerPolicy](https://learn.microsoft.com/en-us/powershell/module/dnsserver/enable-dnsserverpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Enable-DnsServerPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/enable-dnsserverpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Enable-DnsServerPolicy: enable dns server policy with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/enable-dnsserverpolicy-enable-dns-server-policy-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Encrypted DNS in enterprise networks: preserve privacy without losing visibility > DNS over HTTPS protects client-to-resolver traffic, but unmanaged external resolvers can bypass enterprise filtering, logging, caching, internal naming, and split-DNS behavior. - Canonical URL: https://update.dsesecurity.com/updates/encrypted-dns-enterprise-visibility/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:09+00:00 - Modified: 2026-07-19T21:27:09+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know DNS over HTTPS protects client-to-resolver traffic, but unmanaged external resolvers can bypass enterprise filtering, logging, caching, internal naming, and split-DNS behavior. ## Potentially affected Organizations managing recursive DNS, browsers, operating systems, mobile devices, VPN clients, roaming endpoints, internal DNS zones, or network-based DNS protections. ## DSE recommendation Inventory resolver behavior, select designated enterprise resolvers, configure managed clients, constrain unauthorized paths, preserve DNS telemetry, and test every operating location. ## Article Encrypted DNS can protect a user’s query from observation or manipulation between the client and resolver. In an enterprise, the design must also preserve approved resolution, internal names, policy enforcement, and evidence needed to investigate malicious activity. ## The benefit and the tradeoff Source fact: NIST SP 800-81 Rev. 3 covers DoH, DoT, and DoQ as encrypted transports for DNS messages between supported endpoints. Encryption protects that DNS transport path; it does not encrypt the later application connection, prove that the destination is safe, or replace DNSSEC validation of DNS data. Source fact: NIST addresses enterprise control of resolver selection and DNS logging. It explains that encrypted DNS sent to an unauthorized external resolver can bypass the enterprise’s local recursive resolver and recommends restricting unauthorized use of public DNS services. DSE analysis: depending on the deployed architecture, that bypass can also remove enterprise filtering or caching, disrupt internal-name or split-DNS behavior, and disclose query data to a provider outside the approved path. Validate these consequences on the actual browsers, operating systems, applications, VPNs, networks, and resolvers before enforcing a restriction. Encrypted DNS and protective DNS solve different problems. An approved resolver may offer both, but encryption by itself does not apply malicious-domain policy or preserve the investigation evidence an organization needs. ## Choose a deliberate enterprise path Source fact: NIST’s deployment guidance supports organization-designated DNS services, managed encrypted-DNS configuration, and policy restrictions on unapproved resolver paths. It also emphasizes retaining DNS logs and protecting the privacy and integrity of DNS operations. Enforcement must account for the protocol and platform behavior actually in use. DSE recommendation: inventory recursive resolvers, internal zones, split-DNS behavior, DHCP and VPN assignments, mobile and roaming paths, browsers, operating systems, and applications that can choose their own resolver. Record which systems are managed, which require exceptions, and which cannot provide adequate DNS logs. - Select approved resolver paths and configure managed clients through supported enterprise policy. - Where operationally appropriate, constrain unauthorized port 53 DNS, port 853 DoT, and known unapproved DoH paths. - Enable resolver and host or device DNS telemetry so encryption does not remove all investigation context. - Validate DNSSEC and any protective-DNS functions independently of transport encryption. - Test internal and external names, VPN, home, branch, guest, mobile, failover, resolver outage, and recovery scenarios. ## Applicability and limits SP 800-81 Rev. 3 is current technical guidance, but browser, operating-system, resolver, firewall, mobile-management, and VPN controls remain product-specific. NIST added a July 10, 2026 planning note pointing to potential errata. Review that note and current vendor documentation before enforcement. Blocking a resolver without proving alternate resolution can interrupt production services. ## Official reference [NIST SP 800-81 Rev. 3](https://csrc.nist.gov/pubs/sp/800/81/r3/final) — current NIST guidance for encrypted DNS, resolver control, public-provider restrictions, DNS logging, and protective DNS. ## Primary reference - Name: NIST SP 800-81 Rev. 3: Secure Domain Name System (DNS) Deployment Guide - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/81/r3/final - Source publication date: 2026-03-19 ## Citation and use Preferred citation: “Encrypted DNS in enterprise networks: preserve privacy without losing visibility,” DSE Security, https://update.dsesecurity.com/updates/encrypted-dns-enterprise-visibility/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enforce approval outside the model before an AI agent commits a consequential action > An AI agent must not decide for itself whether its next action needs human review. Define consequential actions in policy and code, present the exact proposed effect, issue narrow expiring approval, detect compound actions, and preserve an accountable record. - Canonical URL: https://update.dsesecurity.com/updates/ai-agent-deterministic-approval-consequential-actions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:26:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know An AI agent must not decide for itself whether its next action needs human review. Define consequential actions in policy and code, present the exact proposed effect, issue narrow expiring approval, detect compound actions, and preserve an accountable record. ## Potentially affected AI agents that send external messages, modify records, change access, execute code, deploy configuration, disclose sensitive data, approve transactions, delete content, or coordinate tools and sub-agents. ## DSE recommendation Classify action risk and reversibility, enforce deterministic approval triggers in the orchestrator, show reviewers the exact target and change, bind approval to narrow expiring parameters, detect chained effects, and test denial, timeout, cancellation, and rollback. ## Article ## Source facts: the model cannot be its own escalation authority Microsoft’s [defense-in-depth guidance for autonomous AI agents](https://www.microsoft.com/en-us/security/blog/2026/05/14/defense-in-depth-autonomous-ai-agents/) describes deterministic human-in-the-loop review as an application-layer control. It warns against letting the model decide when review is needed because probabilistic reasoning, ambiguous instructions, or adversarial input can bypass the escalation mechanism. The guidance recommends defining triggers in code and enforcing them through the application or orchestrator, including during tool execution. Microsoft’s related Zero Trust guidance says users should be able to set boundaries for what agents access, do, and remember; high-risk or irreversible actions should require approval; and organizations need reliable system-level methods to pause or stop agents. The design point is separation of duties. The model may propose and explain an action, but a deterministic policy point decides whether execution is allowed, denied, or held for a qualified person. Human approval is not automatically safe. A reviewer can be rushed, receive a vague description, miss several individually small actions that create a large combined effect, or approve a request whose parameters change before execution. Approval must therefore bind to the proposed operation and provide enough context for an informed decision. ## DSE recommendation: make approval a narrow execution capability Start with business consequences rather than a generic “confirm” button. Define which decisions remain human-owned and what evidence a reviewer needs before accepting them. - Classify actions. Inventory every tool operation and rate data sensitivity, people affected, financial value, external visibility, privilege change, reversibility, blast radius, legal or safety consequence, and ease of independent verification. Define actions that are prohibited, autonomous within limits, or approval required. - Encode mandatory triggers. Put rules in the orchestrator, policy engine, or tool gateway. Require approval for defined recipients, data classes, access changes, production deployments, deletions, payments, external sharing, credential operations, and threshold crossings. The model must not be able to suppress or rewrite those rules. - Present the real effect. Show the tool, authenticated identity, exact target, before-and-after values, recipients, records affected, data to be disclosed, source evidence, dependencies, reversibility, and expected follow-on actions. Distinguish model-generated rationale from verified system facts. - Bind and expire the decision. Issue approval for the specific action hash, parameters, identity, environment, and short execution window. Any changed recipient, scope, amount, file, query, or tool definition should require a new decision. Prevent replay and record denial, timeout, cancellation, and execution status. - Evaluate compound behavior. Aggregate related steps before review. A sequence of read, export, upload, and share operations may be consequential even if each isolated tool call is below a threshold. Limit recursion, parallelism, total records, cumulative value, and repeated approval prompts. - Protect the reviewer. Route decisions to a role with authority and context, avoid self-approval, pace notifications to reduce consent fatigue, provide a safe deny-and-investigate path, and never punish a reviewer for stopping an ambiguous action. Use dual approval where the business risk justifies it. - Exercise containment. Test forged approval, stale approval, altered parameters, unavailable reviewer, prompt injection, incremental escalation, partial completion, rollback failure, and emergency stop. Verify that disabling the agent identity and tool gateway actually blocks pending work. Factual boundary: Human approval reduces risk but cannot prove an action is correct or harmless. The threshold is environment specific; no source supplies a universal list of consequential actions. Deterministic enforcement should not be confused with a guarantee that the policy itself is complete. Measure approvals without sufficient context, altered requests, repeated prompts, reviewer turnaround, denied high-risk actions, expired approvals, self-approval attempts, and rollback success. The mature outcome is not a human clicking after the model. It is an application that refuses to create consequential authority until a qualified person approves the exact effect. ## Official references - Microsoft Security, [Defense in depth for autonomous AI agents](https://www.microsoft.com/en-us/security/blog/2026/05/14/defense-in-depth-autonomous-ai-agents/), May 14, 2026. - Microsoft Learn, [Reduce autonomous agentic AI risk](https://learn.microsoft.com/en-us/security/zero-trust/sfi/manage-agentic-risk). - NIST AI Resource Center, [AI RMF Playbook](https://airc.nist.gov/airmf-resources/playbook/). ## Primary reference - Name: Microsoft Security: Defense in depth for autonomous AI agents - Authority: www.microsoft.com - URL: https://www.microsoft.com/en-us/security/blog/2026/05/14/defense-in-depth-autonomous-ai-agents/ - Source publication date: 2026-05-14 ## Citation and use Preferred citation: “Enforce approval outside the model before an AI agent commits a consequential action,” DSE Security, https://update.dsesecurity.com/updates/ai-agent-deterministic-approval-consequential-actions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enforce HTTP/3 control-stream and request-stream roles over QUIC > Use RFC 9114 — HTTP/3 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/enforce-http-3-control-stream-and-request-stream-roles-over-quic/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:55+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 9114 — HTTP/3 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 9114 — HTTP/3 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Enforce HTTP/3 control-stream and request-stream roles over QUIC. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 9114 — HTTP/3](https://www.rfc-editor.org/rfc/rfc9114.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Each HTTP/3 request occupies one client-initiated bidirectional stream, with interim and final responses returned on that same stream. The research record locates this support at Sections 4.1 (HTTP Message Framing) and 6.1 (Bidirectional Streams). - Each endpoint creates exactly one control stream, sends SETTINGS first, and keeps that critical stream open for the connection’s lifetime. The research record locates this support at Section 6.2.1 (Control Streams). - Only a server creates a push stream, whose stream-type prefix and unique Push ID associate its response frames with one promised push. The research record locates this support at Section 6.2.2 (Push Streams). Only the traced statements above are asserted as source facts. Apply the review to clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Sections 4.1 (HTTP Message Framing) and 6.1 (Bidirectional Streams), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 6.2.1 (Control Streams), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 6.2.2 (Push Streams), which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, certificates, identity providers, time, content delivery, network paths, and application ownership in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations Sections 4.1 (HTTP Message Framing) and 6.1 (Bidirectional Streams); Section 6.2.1 (Control Streams); Section 6.2.2 (Push Streams) adjacent to the sanitized artifacts used for comparison. Prefer request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 9114 — HTTP/3](https://www.rfc-editor.org/rfc/rfc9114.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 9114 — HTTP/3 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9114.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Enforce HTTP/3 control-stream and request-stream roles over QUIC,” DSE Security, https://update.dsesecurity.com/updates/enforce-http-3-control-stream-and-request-stream-roles-over-quic/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enforce Kubernetes Pod Security Standards by namespace and exception > Kubernetes Pod Security Admission can enforce privileged, baseline, or restricted profiles by namespace while audit and warn modes expose violations first. Govern labels, policy versions, exemptions, and controller-created Pods as one system. - Canonical URL: https://update.dsesecurity.com/updates/kubernetes-pod-security-admission-governance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:02:00+00:00 - Modified: 2026-08-11T14:48:24+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Kubernetes Pod Security Admission can enforce privileged, baseline, or restricted profiles by namespace while audit and warn modes expose violations first. Govern labels, policy versions, exemptions, and controller-created Pods as one system. ## Potentially affected Kubernetes clusters; namespaces; Pods, Deployments, Jobs, and controllers; platform engineering; application teams; CI/CD; admission configuration; audit logs; Prometheus monitoring; Linux and Windows workloads. ## DSE recommendation Inventory every namespace and workload, apply audit and warn profiles at an explicit version, remediate violations, stage enforcement, constrain privileged namespaces, and review all admission exemptions and related metrics. ## Article ## Source facts: three profiles, three modes, and important boundaries The [Kubernetes documentation](https://kubernetes.io/docs/concepts/security/pod-security-admission/) describes the built-in Pod Security admission controller as stable since Kubernetes 1.25. It applies Pod Security Standards at namespace level when Pods are created. The standards define privileged, baseline, and restricted profiles: privileged is unrestricted, baseline prevents known privilege escalations while supporting common workloads, and restricted follows current Pod-hardening practices. Namespace labels select both a profile and a mode. enforce rejects a violating Pod. audit allows it but adds an annotation to the audit event. warn allows it but returns a user-facing warning. Each mode can also pin a Kubernetes policy version or use latest. A namespace can use different levels and versions for different modes. The controller boundary matters. Audit and warning checks apply to workload resources such as Deployments and Jobs so template problems can be shown early, but enforcement applies to resulting Pod objects rather than the workload object itself. An accepted Deployment can therefore fail later when its controller tries to create noncompliant Pods. Static exemptions can match usernames, runtime classes, or namespaces. When an exemption matches, all enforce, audit, and warn behavior is skipped. Kubernetes cautions against broadly exempting controller service accounts because any user who can create the corresponding workload may inherit the bypass. The API server exposes evaluation, error, and exemption metrics for the admission controller. ## DSE recommendation: make namespace posture part of workload ownership Create a register of every cluster and namespace with business service, owner, data sensitivity, internet exposure, node operating system, workload controller, intended Pod Security profile, pinned policy version, and exception status. Reconcile it against the live API. An unlabeled namespace is a governance finding even when its current Pods happen to satisfy the desired profile. - Observe first. Apply audit and warn at the intended profile to representative nonproduction namespaces. Capture violations from manifests, charts, operators, jobs, init containers, and generated workloads rather than relying on a scan of long-running Pods alone. - Assign remediation. Translate each field violation into a workload change, owner, target release, and test. Common fixes affect capabilities, privilege escalation, host namespaces, volumes, user identity, and security profiles; validate application behavior after changing them. - Version deliberately. Pin enforcement to the cluster minor version that has been tested. Consider audit and warn against the next intended or latest profile to expose future drift, but assess version changes during every cluster upgrade instead of silently inheriting new restrictions. - Stage enforcement. Start with a limited namespace class, deploy a known-violating test manifest to prove rejection, and confirm that compliant controllers still create and replace Pods. Test rollout, rollback, autoscaling, scheduled Jobs, disaster recovery, and node replacement. - Isolate privileged workloads. Place necessary infrastructure components in specifically governed namespaces. Restrict who can change namespace labels, create workloads there, select privileged runtime classes, or modify admission configuration. Keep ordinary applications out of that boundary. - Govern exemptions as bypasses. Record exact dimension, business reason, requester, approver, risk, compensating controls, affected workload, expiry, and removal test. Prefer the narrowest supported exemption and review controller-service-account implications before approval. Alert on namespace label changes, admission configuration changes, enforcement rejections, evaluation errors, and unexpected increases in pod_security_exemptions_total. Trend warnings by owner and profile, and verify that audit events reach the security logging destination. Pod Security Admission is a useful platform floor; it does not replace image provenance, vulnerability management, network policy, secrets protection, runtime detection, RBAC, or node hardening. The durable outcome is a known policy at every namespace and a short, reviewable path for the rare workload that cannot meet it. Include namespace-label restoration in cluster recovery testing. A restored workload without its intended admission posture can look healthy while accepting weaker replacement Pods, so compare labels and exemption configuration with the governed inventory before reopening service. ## Official references - Kubernetes Documentation, [Pod Security Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/), page last modified March 7, 2024; version-specific documentation reviewed August 11, 2026. - Kubernetes Documentation, [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/). ## Primary reference - Name: Kubernetes Documentation: Pod Security Admission - Authority: kubernetes.io - URL: https://kubernetes.io/docs/concepts/security/pod-security-admission/ - Source publication date: 2024-03-07 ## Citation and use Preferred citation: “Enforce Kubernetes Pod Security Standards by namespace and exception,” DSE Security, https://update.dsesecurity.com/updates/kubernetes-pod-security-admission-governance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Enforce MTA-STS only after retrieving and authenticating domain policy > Use RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:02+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Enforce MTA-STS only after retrieving and authenticating domain policy. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A sender discovers MTA-STS through the policy domain’s _mta-sts TXT record, whose id value distinguishes policy revisions. The research record locates this support at Section 3.1 (MTA-STS TXT Records). - The sender fetches the policy from the fixed HTTPS path on mta-sts.; only a 200 response with a certificate valid for that host yields a live policy. The research record locates this support at Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching). - In enforce mode, the sender requires STARTTLS and valid MX identity for each candidate, while a still-valid cached policy remains applicable when live retrieval fails. The research record locates this support at Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow). Keep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 3.1 (MTA-STS TXT Records), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations Section 3.1 (MTA-STS TXT Records); Sections 3.2 (MTA-STS Policies) and 3.3 (HTTPS Policy Fetching); Sections 3.3 (HTTPS Policy Fetching) and 5.1 (Policy Application Control Flow) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8461.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Enforce MTA-STS only after retrieving and authenticating domain policy,” DSE Security, https://update.dsesecurity.com/updates/enforce-mta-sts-only-after-retrieving-and-authenticating-domain-policy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Engineer critical services to anticipate, withstand, recover, and adapt > Cyber resilience is an engineered ability to continue mission-essential outcomes through attack and compromise—not a synonym for prevention or backup. Define what must endure, then design and test for anticipation, resistance, recovery, and adaptation. - Canonical URL: https://update.dsesecurity.com/updates/engineer-critical-services-anticipate-withstand-recover-adapt/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:33:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Cyber resilience is an engineered ability to continue mission-essential outcomes through attack and compromise—not a synonym for prevention or backup. Define what must endure, then design and test for anticipation, resistance, recovery, and adaptation. ## Potentially affected Business-critical services, applications, identity dependencies, communications, facilities technology, third-party integrations, data flows, recovery platforms, and the people who operate them. ## DSE recommendation Choose one critical service, define its essential outcomes and adverse conditions, map dependencies, select complementary resilience techniques, and test degraded operation as well as restoration. ## Article ## Source facts: resilience begins after prevention is assumed imperfect NIST Special Publication 800-160 Volume 2 Revision 1 describes cyber resiliency engineering as a systems discipline for developing systems that can anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises involving cyber resources. Its purpose is not to declare prevention unimportant. It recognizes that systems support missions over time and that determined adversaries, latent defects, and disrupted dependencies can defeat individual safeguards. The publication organizes cyber resiliency around goals, objectives, techniques, approaches, and design principles. Its techniques include adaptive response, analytic monitoring, coordinated protection, deception, diversity, dynamic positioning, non-persistence, privilege restriction, realignment, redundancy, segmentation, substantiated integrity, unpredictability, and deception. NIST does not prescribe every technique for every system. Organizations select and tailor constructs for their mission, system life cycle, threat environment, and risk. Cyber resilience is also broader than restoration. A system may need to continue a reduced but safe function during an attack, preserve trustworthy state for recovery, prevent one compromised component from controlling the whole service, and incorporate lessons into future architecture. Recovery time alone does not describe those outcomes. ## DSE recommendation: define the service outcome before selecting techniques Start with one business or safety outcome whose loss would matter. Name the accountable owner and describe the minimum acceptable service during normal, degraded, recovery, and emergency operation. Record maximum tolerable interruption, data-loss tolerance, integrity requirements, manual alternatives, safety constraints, and the decisions that only authorized people may make. Map the complete service, not just its visible application. Include identity, name resolution, secrets, network paths, cloud control planes, data stores, time sources, facilities, vendors, communications, staffing, and recovery tooling. Mark single points of failure and dependencies shared with other critical services. A redundant application is not resilient when both instances rely on one administrative identity path or one corrupted data source. ## DSE recommendation: combine techniques around credible adverse conditions - Write adverse-condition scenarios. Include credential compromise, destructive administration, corrupted data, unavailable communications, supplier failure, malicious persistence, and loss of a shared dependency. State what the service must still accomplish. - Reduce propagation. Segment trust, restrict privilege, separate recovery authority, and define integrity checks so one compromise cannot silently rewrite every operating and recovery copy. - Create genuinely different paths. Redundancy that repeats the same vulnerability or administrative plane can reproduce the same failure. Use diversity where its operational cost is justified and test the alternate path independently. - Prepare controlled degradation. Document which features can stop, which transactions can queue, what becomes read-only, who may authorize a manual process, and how deferred work is reconciled. - Instrument adaptation. Collect evidence that reveals changing threats, failed assumptions, integrity loss, and recovery performance. Assign an owner to translate observations into design changes. ## DSE recommendation: test survival, not only failover Exercise the service while a trusted component is assumed compromised. Remove a dependency, introduce delayed or suspect data, deny an administrative path, and require the team to identify trustworthy state. Observe whether essential outcomes continue, whether responders know the degradation limits, and whether recovery reconnects a still-compromised dependency. Retain evidence for each objective: detection time, time to isolate, minimum service achieved, integrity decisions, recovery point, recovery time, operator workload, external coordination, and defects found. After each exercise or incident, decide whether the architecture, operating procedure, supplier requirement, or risk acceptance must change. Cyber resilience becomes credible when the organization can show how the service behaves through adversity—not when a diagram merely contains redundant boxes. Include unresolved weaknesses in the service risk record, with interim operating limits and an accountable decision-maker. ## Official references - National Institute of Standards and Technology, [SP 800-160 Volume 2 Revision 1: Developing Cyber-Resilient Systems—A Systems Security Engineering Approach](https://csrc.nist.gov/pubs/sp/800/160/v2/r1/final), December 9, 2021; reviewed August 11, 2026. ## Primary reference - Name: NIST SP 800-160 Vol. 2 Rev. 1: Developing Cyber-Resilient Systems - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/160/v2/r1/final - Source publication date: 2021-12-09 ## Citation and use Preferred citation: “Engineer critical services to anticipate, withstand, recover, and adapt,” DSE Security, https://update.dsesecurity.com/updates/engineer-critical-services-anticipate-withstand-recover-adapt/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Establish DNS shared keys only through an explicit TKEY exchange mode > Use RFC 2930 — Secret Key Establishment for DNS (TKEY RR) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/establish-dns-shared-keys-only-through-an-explicit-tkey-exchange-mode/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:43+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2930 — Secret Key Establishment for DNS (TKEY RR) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2930 — Secret Key Establishment for DNS (TKEY RR) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Establish DNS shared keys only through an explicit TKEY exchange mode. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2930 — Secret Key Establishment for DNS (TKEY RR)](https://www.rfc-editor.org/rfc/rfc2930.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A TKEY record carries the key algorithm, inception and expiration times, exchange mode, error, key data, and optional other data. The research record locates this support at Section 2 (The TKEY Resource Record). - A TKEY query places its TKEY record in the additional-information section and uses the mode field to select the key-agreement procedure. The research record locates this support at Section 3 (General TKEY Considerations). - The defined TKEY modes cover server assignment, Diffie-Hellman exchange, GSS negotiation, resolver assignment, and key deletion. The research record locates this support at Section 2.5 (Modes). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2 (The TKEY Resource Record), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (General TKEY Considerations), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2.5 (Modes), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to Section 2 (The TKEY Resource Record); Section 3 (General TKEY Considerations); Section 2.5 (Modes) and to observable material such as zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 2930 — Secret Key Establishment for DNS (TKEY RR)](https://www.rfc-editor.org/rfc/rfc2930.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2930 — Secret Key Establishment for DNS (TKEY RR) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2930.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Establish DNS shared keys only through an explicit TKEY exchange mode,” DSE Security, https://update.dsesecurity.com/updates/establish-dns-shared-keys-only-through-an-explicit-tkey-exchange-mode/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Establish GSS-TSIG context keys without confusing them with zone data > Use RFC 3645 — Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/establish-gss-tsig-context-keys-without-confusing-them-with-zone-data/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:42+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3645 — Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3645 — Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Establish GSS-TSIG context keys without confusing them with zone data. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3645 — Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)](https://www.rfc-editor.org/rfc/rfc3645.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - GSS-TSIG uses a TKEY exchange to establish a GSS security context and then uses the derived context key with TSIG. The research record locates this support at Sections 2.1 (GSS API) and 2.2 (TKEY and TSIG). - The client repeats GSS_Init_sec_context token exchanges in TKEY queries until the security context is complete or an error occurs. The research record locates this support at Section 3.1 (Negotiating Context). - A server that receives a TSIG name for which it has no established security context returns the TSIG error BADKEY. The research record locates this support at Section 5.2 (Server Processing of TSIG). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Sections 2.1 (GSS API) and 2.2 (TKEY and TSIG), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3.1 (Negotiating Context), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5.2 (Server Processing of TSIG), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to Sections 2.1 (GSS API) and 2.2 (TKEY and TSIG); Section 3.1 (Negotiating Context); Section 5.2 (Server Processing of TSIG) and to observable material such as zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 3645 — Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)](https://www.rfc-editor.org/rfc/rfc3645.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 3645 — Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3645.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Establish GSS-TSIG context keys without confusing them with zone data,” DSE Security, https://update.dsesecurity.com/updates/establish-gss-tsig-context-keys-without-confusing-them-with-zone-data/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Estimate exposed offsite populations with required census and mapping methods > Use 40 CFR 68.30 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/estimate-exposed-offsite-populations-with-required-census-and-mapping-methods/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:15+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.30 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.30 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Estimate exposed offsite populations with required census and mapping methods. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.30 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.30) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the owner or operator may use the most recent Census data, or other updated information, to estimate the population potentially affected. The research record locates this support at 40 CFR 68.30(c) (eCFR anchor p-68.30(c)). - Under 40 CFR 68, the rule requires that the owner or operator estimate in the RMP the population within a circle with its center at the point of the release and a radius determined by the distance to the endpoint defined in section 68.22(a). The research record locates this support at 40 CFR 68.30(a) (eCFR anchor p-68.30(a)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths and the conditions the source actually describes. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 40 CFR 68.30(c) (eCFR anchor p-68.30(c)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.30(a) (eCFR anchor p-68.30(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations 40 CFR 68.30(c) (eCFR anchor p-68.30(c)); 40 CFR 68.30(a) (eCFR anchor p-68.30(a)) adjacent to the sanitized artifacts used for comparison. Prefer facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [40 CFR 68.30 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.30) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.30 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.30 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Estimate exposed offsite populations with required census and mapping methods,” DSE Security, https://update.dsesecurity.com/updates/estimate-exposed-offsite-populations-with-required-census-and-mapping-methods/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Evaluate contractors and communicate covered-process hazards before work > Use 40 CFR 68.87 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/evaluate-contractors-and-communicate-covered-process-hazards-before-work/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:49+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.87 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.87 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Evaluate contractors and communicate covered-process hazards before work. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.87 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.87) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the owner or operator inform contract owner or operator of the known potential fire, explosion, or toxic release hazards related to the contractor’s work and the process. The research record locates this support at 40 CFR 68.87(b)(2) (eCFR anchor p-68.87(b)(2)). - Under 40 CFR 68, the rule requires that the owner or operator develop and implement safe work practices consistent with section 68.69(d), to control the entrance, presence, and exit of the contract owner or operator and contract employees in covered process areas. The research record locates this support at 40 CFR 68.87(b)(4) (eCFR anchor p-68.87(b)(4)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths and the conditions the source actually describes. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.87(b)(2) (eCFR anchor p-68.87(b)(2)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.87(b)(4) (eCFR anchor p-68.87(b)(4)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations 40 CFR 68.87(b)(2) (eCFR anchor p-68.87(b)(2)); 40 CFR 68.87(b)(4) (eCFR anchor p-68.87(b)(4)) adjacent to the sanitized artifacts used for comparison. Prefer facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [40 CFR 68.87 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.87) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.87 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.87 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Evaluate contractors and communicate covered-process hazards before work,” DSE Security, https://update.dsesecurity.com/updates/evaluate-contractors-and-communicate-covered-process-hazards-before-work/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Evaluate CSV memory caching against the workload’s read and write balance > When should CSV in-memory read caching be evaluated or disabled for a workload? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-138-evaluate-csv-memory-caching-against-the-workloads-read-and-write-balance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:53+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know When should CSV in-memory read caching be evaluated or disabled for a workload? ## Potentially affected Administrators tuning the CSV in-memory read cache on supported Windows clusters. ## DSE recommendation Agree on a representative workload interval and the application measures that would justify the allocated memory. ## Article ## Source facts The CSV memory cache stores reads; Microsoft states that it does not cache writes. The guidance identifies read-intensive workloads such as VDI as good candidates and warns that an extremely write-intensive workload can incur more overhead than benefit. Windows Admin Center provides a cluster setting to enable the cache and choose the maximum memory allocated per server. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/use-csv-cache). ## Applicability Identify the workload, observed read/write pattern, server memory budget, current setting, and supported platform release. Separate this use of system RAM from the persistent cache media in the storage pool. ## DSE recommendation Agree on a representative workload interval and the application measures that would justify the allocated memory. Record the original setting and ask the platform owner to approve the test allocation. Review the source’s instructions for applying the change before conducting the comparison. ## Verification Compare the workload with the approved cache settings under comparable conditions, recording read/write mix and available memory. Evaluate the application result together with the resource cost. Preserve an inconclusive or worse result as such rather than declaring that enabling a cache necessarily improved the workload. ## Official references [Microsoft Learn: Use the CSV in-memory read cache with Azure Local and Windows Server clusters](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/use-csv-cache). Source reviewed September 8, 2026. ## Primary reference - Name: Use the CSV in-memory read cache with Azure Local and Windows Server clusters - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/use-csv-cache - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Evaluate CSV memory caching against the workload’s read and write balance,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-138-evaluate-csv-memory-caching-against-the-workloads-read-and-write-balance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Evaluate nested resiliency for a two-node storage cluster > When should a two-node Storage Spaces Direct design consider nested resiliency? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-173-evaluate-nested-resiliency-for-a-two-node-storage-cluster/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:18+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know When should a two-node Storage Spaces Direct design consider nested resiliency? ## Potentially affected Administrators planning nested resiliency for a two-node Storage Spaces Direct cluster. ## DSE recommendation Compare the available nested-resiliency choices using the actual drive inventory and a capacity calculation reviewed by the storage owner. ## Article ## Source facts Microsoft limits the documented nested-resiliency configuration to exactly two server nodes and lists supported operating-system versions. The design can keep a volume available through combinations such as a server failure together with a drive failure, beyond classic two-way mirroring. Nested two-way mirroring maintains two copies on different physical disks in each server. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/nested-resiliency). ## Applicability Verify the cluster topology and operating-system release against the source before choosing a resiliency option. Identify the exact failure combinations the storage design must address. Include usable capacity and workload performance in the same decision rather than evaluating redundancy alone. ## DSE recommendation Compare the available nested-resiliency choices using the actual drive inventory and a capacity calculation reviewed by the storage owner. Draw where each copy resides and identify which proposed failures remove it. Agree on a controlled lab exercise for the required failure combinations. Document the intended workload behavior and the stop condition before simulating unavailable storage. ## Verification Confirm the created volume layout and measured usable capacity. In an approved test environment, exercise the selected failure combination and observe volume availability together with an application transaction. Record recovery and repair behavior before declaring the exercise complete. Preserve any deviations between the planned copy layout and the observed configuration. ## Official references [Microsoft Learn: Nested resiliency for Storage Spaces Direct](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/nested-resiliency). Source reviewed September 8, 2026. ## Primary reference - Name: Nested resiliency for Storage Spaces Direct - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/nested-resiliency - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Evaluate nested resiliency for a two-node storage cluster,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-173-evaluate-nested-resiliency-for-a-two-node-storage-cluster/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Evaluate Network HUD preview as intent-aware network diagnostics > When can Network HUD preview add useful cluster-network health context? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-007-evaluate-network-hud-preview-as-intent-aware-network-diagnostics/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:17:04+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know When can Network HUD preview add useful cluster-network health context? ## Potentially affected Teams evaluating Network HUD preview for eligible, Azure Arc-connected Windows Server 2025 Datacenter clusters. ## DSE recommendation Choose one known network-health concern for an approved evaluation, such as an unstable link observed by the network team. ## Article ## Source facts Microsoft identifies Network HUD for Windows Server as a preview feature. Its availability requires eligibility for Windows Server Management enabled by Azure Arc. The documented environment requires Windows Server 2025 Datacenter cluster nodes, Network ATC intents, Storage Spaces Direct, and Azure Arc connectivity on each node. Network HUD correlates host and fabric signals with declared network intents and cluster state to produce contextual health detections. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/network-hud-overview). ## Applicability Treat this as a preview evaluation, not a production capability guarantee. Confirm eligibility and every documented cluster prerequisite before planning a trial. Keep the diagnostic question separate from the configuration work that establishes Network ATC intents. ## DSE recommendation Choose one known network-health concern for an approved evaluation, such as an unstable link observed by the network team. Map the affected adapter to its intent and physical port. Agree who will review a correlated fault and any proposed remediation. Keep existing monitoring in place and define an exit condition if the preview does not provide useful, explainable evidence. ## Verification Compare the reported health context with the host, physical switch, and intended traffic role. Record whether the detection identifies the same component and condition as the independent observations. Review unexpected correlations before acting, and document the preview version and eligibility state alongside the evaluation outcome. ## Official references [Microsoft Learn: What is Network HUD (preview) for Windows Server?](https://learn.microsoft.com/en-us/windows-server/networking/network-hud-overview). Source reviewed September 8, 2026. ## Primary reference - Name: What is Network HUD (preview) for Windows Server? - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/network-hud-overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Evaluate Network HUD preview as intent-aware network diagnostics,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-007-evaluate-network-hud-preview-as-intent-aware-network-diagnostics/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Evaluate reactor physical protection against radiological-sabotage objectives > Use 10 CFR 73.55 - Nuclear power reactor physical protection to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/evaluate-reactor-physical-protection-against-radiological-sabotage-objectives/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:45+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.55 - Nuclear power reactor physical protection to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.55 - Nuclear power reactor physical protection ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Evaluate reactor physical protection against radiological-sabotage objectives. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.55 – Nuclear power reactor physical protection](https://www.ecfr.gov/current/title-10/section-73.55) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, consistent with the physical protection program design requirements of section 73.55(b), and in accordance with the site-specific analysis, the licensee must establish and maintain vehicle control measures, as necessary, to protect against the design basis threat of radiological sabotage vehicle bomb assault. The research record locates this support at 10 CFR 73.55(e)(10) (eCFR anchor p-73.55(e)(10)). - Under 10 CFR 73, to satisfy the general performance objective of paragraph (b)(1) of this section, the physical protection program must protect against the design basis threat of radiological sabotage as stated in section 73.1. The research record locates this support at 10 CFR 73.55(b)(2) (eCFR anchor p-73.55(b)(2)). Only the traced statements above are asserted as source facts. Apply the review to access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths after confirming that the source and deployed context match. ## What the source does not establish NRC regulation for covered reactors; force-on-force, target sets, response, barriers, and other site details can be sensitive and require authorized review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.55(e)(10) (eCFR anchor p-73.55(e)(10)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.55(b)(2) (eCFR anchor p-73.55(b)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to 10 CFR 73.55(e)(10) (eCFR anchor p-73.55(e)(10)); 10 CFR 73.55(b)(2) (eCFR anchor p-73.55(b)(2)) and to observable material such as asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [10 CFR 73.55 – Nuclear power reactor physical protection](https://www.ecfr.gov/current/title-10/section-73.55) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.55 - Nuclear power reactor physical protection - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.55 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Evaluate reactor physical protection against radiological-sabotage objectives,” DSE Security, https://update.dsesecurity.com/updates/evaluate-reactor-physical-protection-against-radiological-sabotage-objectives/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Evaluate records-storage facilities as purpose-built protective environments > Use 36 CFR 1234.10 - Records storage facility requirements to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/evaluate-records-storage-facilities-as-purpose-built-protective-environments/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:32+00:00 - Modified: 2026-08-27T13:07:00+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 36 CFR 1234.10 - Records storage facility requirements to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 36 CFR 1234.10 - Records storage facility requirements ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Evaluate records-storage facilities as purpose-built protective environments. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [36 CFR 1234.10 – Records storage facility requirements](https://www.ecfr.gov/current/title-36/section-1234.10) from National Archives and Records Administration via eCFR supports the following bounded statements: - Under 36 CFR 1234, the rule requires that piping (with the exception of fire protection sprinkler piping and storm water roof drainage piping) not be run through records storage areas unless supplemental measures such as gutters or shields are used to prevent water leaks and the piping assembly is inspected for potential leaks regularly. The research record locates this support at 36 CFR 1234.10(h) (eCFR anchor p-1234.10(h)). - Under 36 CFR 1234, an agency may request a waiver of the requirement specified in paragraph (a) from NARA for an existing records storage facility with combustible building elements to continue to operate until October 1, 2009. The research record locates this support at 36 CFR 1234.10(a)(2) (eCFR anchor p-1234.10(a)(2)). The source support ends with the statements listed above. Use them to examine critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Federal records-storage regulation; record type, facility status, waivers, incorporated standards, local code, lease or contract, and later amendments require complete review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 36 CFR 1234.10(h) (eCFR anchor p-1234.10(h)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 36 CFR 1234.10(a)(2) (eCFR anchor p-1234.10(a)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from 36 CFR 1234.10(h) (eCFR anchor p-1234.10(h)); 36 CFR 1234.10(a)(2) (eCFR anchor p-1234.10(a)(2)) to the observed environment. Useful domain evidence includes facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [36 CFR 1234.10 – Records storage facility requirements](https://www.ecfr.gov/current/title-36/section-1234.10) — National Archives and Records Administration via eCFR ## Primary reference - Name: 36 CFR 1234.10 - Records storage facility requirements - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-36/section-1234.10 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Evaluate records-storage facilities as purpose-built protective environments,” DSE Security, https://update.dsesecurity.com/updates/evaluate-records-storage-facilities-as-purpose-built-protective-environments/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Evaluate RPC anonymous-client restrictions against application dependencies > What should be tested before changing RestrictRemoteClients? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-015-evaluate-rpc-anonymous-client-restrictions-against-application-dependencies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:56+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What should be tested before changing RestrictRemoteClients? ## Potentially affected Use this review when considering an RPC interface restriction on Windows Server. ## DSE recommendation Ask application owners to identify required remote operations and the identities used for them. ## Article ## Source facts Microsoft documents RestrictRemoteClients as a system-wide control that can limit anonymous remote access to RPC interfaces, subject to exceptions. Applications expecting anonymous remote RPC calls may fail when the restriction is used; Microsoft also warns that DCOM applications may be affected. The setting adds RPC security checks even for interfaces without a registered security callback. Named-pipe RPC through ncacn_np is exempt from these restrictions. Enabling the key causes RPC calls over connectionless protocols to fail. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/security/rpc-interface-restrict). ## Applicability Use this review when considering an RPC interface restriction on Windows Server. Identify the current setting, affected applications, and calling systems. Review the precise documented values and exceptions before choosing a configuration. ## DSE recommendation Ask application owners to identify required remote operations and the identities used for them. Build an approved test matrix containing legitimate workflows and the anonymous access the proposed setting is meant to restrict. Record the prior registry configuration and an authorized restoration procedure. Pilot the setting with the people who can recognize application-level failures, not solely with a server administrator. ## Verification Run the agreed remote workflows after the change and retain authentication context, timestamps, and results. Investigate DCOM or RPC errors against the prechange observations. Verify the intended restriction separately from legitimate application success. Record every required exception and owner before extending the configuration to other servers. ## Official references [Microsoft Learn: RPC Interface Restriction for Windows Server](https://learn.microsoft.com/en-us/windows-server/security/rpc-interface-restrict). Source reviewed September 8, 2026. ## Primary reference - Name: RPC Interface Restriction for Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/rpc-interface-restrict - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Evaluate RPC anonymous-client restrictions against application dependencies,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-015-evaluate-rpc-anonymous-client-restrictions-against-application-dependencies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Exclude selected redirected folders from automatic offline caching > Which redirected folders should remain outside the client’s automatic Offline Files cache? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-116-exclude-selected-redirected-folders-from-automatic-offline-caching/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:15+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which redirected folders should remain outside the client’s automatic Offline Files cache? ## Potentially affected Administrators applying Offline Files exclusions to redirected Windows folders. ## DSE recommendation Prepare a user-and-folder decision table before enabling the policy. ## Article ## Source facts Microsoft provides a Folder Redirection policy that excludes selected redirected folders from automatic offline availability. Enabling the policy allows administrators to choose the folders to exclude. Leaving it disabled or unconfigured makes all redirected folders available offline. The documented configuration uses Group Policy and selects the individual folder checkboxes in that policy’s options. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/disable-offline-files-on-folders). ## Applicability Review the supported client versions, domain membership, affected users, redirected folders, and expected disconnected work. Ask each data owner which folders users must be able to access away from the network. ## DSE recommendation Prepare a user-and-folder decision table before enabling the policy. Record why each folder is excluded and how users should work when the share is unreachable. Have the endpoint owner review the intended GPO scope and any conflicting Folder Redirection settings. ## Verification Apply the policy to a representative test user and inspect the resulting folder choices. Test access while connected and during an approved disconnected scenario, then reconnect and examine the user’s file state. Record missing offline access as either the approved result or an unexpected failure before extending the policy to other users. ## Official references [Microsoft Learn: Disable Offline Files on individual redirected folders](https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/disable-offline-files-on-folders). Source reviewed September 8, 2026. ## Primary reference - Name: Disable Offline Files on individual redirected folders - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/disable-offline-files-on-folders - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Exclude selected redirected folders from automatic offline caching,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-116-exclude-selected-redirected-folders-from-automatic-offline-caching/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Exempt Defender for Identity sensor traffic from SSL interception > Use Connect to the Defender for Identity service to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/exempt-defender-for-identity-sensor-traffic-from-ssl-interception/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:35+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Connect to the Defender for Identity service to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Connect to the Defender for Identity service ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Exempt Defender for Identity sensor traffic from SSL interception. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Connect to the Defender for Identity service](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-proxy) from Microsoft supports the following bounded statements: - Each Defender for Identity sensor requires internet connectivity to the cloud service to report data and operate. The research record locates this support at Opening overview. - SSL inspection and intercepting proxies are unsupported because they interfere with certificate-based mutual authentication; proxy traffic must pass to required service URLs without interception. The research record locates this support at Proxy and authentication explanation. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health and the conditions the source actually describes. ## What the source does not establish Allow only the documented service destinations and validate change controls; this source does not define an organization-wide proxy bypass policy. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Proxy and authentication explanation, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Opening overview; Proxy and authentication explanation to the observed environment. Useful domain evidence includes sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Connect to the Defender for Identity service](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-proxy) — Microsoft ## Primary reference - Name: Connect to the Defender for Identity service - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-proxy - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Exempt Defender for Identity sensor traffic from SSL interception,” DSE Security, https://update.dsesecurity.com/updates/exempt-defender-for-identity-sensor-traffic-from-ssl-interception/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Exercise Azure Backup soft-delete recovery before the retention clock expires > Azure Backup soft delete delays permanent deletion for a configured retention period, but workload and vault support, regional state, recovery-point limits, and restore procedure still require verification. - Canonical URL: https://update.dsesecurity.com/updates/azure-backup-soft-delete-recovery-exercise/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:57+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Azure Backup soft delete delays permanent deletion for a configured retention period, but workload and vault support, regional state, recovery-point limits, and restore procedure still require verification. ## Potentially affected Azure Recovery Services vaults and Backup vaults protecting supported Azure and hybrid workloads. ## DSE recommendation Confirm soft-delete state and retention per vault, alert on deletion, exercise undelete and restore for each critical workload, and add immutability or multiuser authorization where risk requires. ## Article Bottom line: Azure Backup soft delete keeps supported deleted backup data recoverable for a configured period instead of immediately destroying it. Microsoft documents a default retention period and optional extension, with service, vault, workload, region, API, and availability-status differences. Recovery still has to be detected, authorized, performed, and validated before time expires. ## Source fact: what Microsoft documents Microsoft’s [secure-by-default soft-delete documentation](https://learn.microsoft.com/en-us/azure/backup/secure-by-default) says deleted backup items and supported vault data remain in a soft-deleted state during the retention period. The documented default is 14 days, and the period can be extended within stated limits, with pricing implications beyond the included period. The page distinguishes Recovery Services vault and Backup vault availability by region and general-availability or preview state. It lists workload boundaries, including differences for vaulted data, operational backups, snapshots, and log recovery points for specified database workloads. Microsoft documents recovery, resume-protection, vault deletion, API and tool-version behavior, and the effect of the retention value active at the time of deletion. Secure-by-default enforcement does not have identical status for every vault and region. ## What the source does not establish Soft delete does not prove that backups are current, uncompromised, application-consistent, immutable, or restorable. It does not stop a destructive actor from waiting out the retention period, attacking source and recovery credentials, or changing future backup policy. A recovered backup item is not the same as a validated application recovery. Preview capability should not be represented as universal general availability. ## Applicability questions - Is each protected item in a Recovery Services vault or Backup vault, and in which region and availability state? - Is the workload vaulted or operational, and which soft-delete and recovery-point limitations apply? - How long could malicious deletion remain undetected, and does retention exceed that period? - Who can stop protection, delete, recover, change retention, or alter vault security features? - Are immutability, multiuser authorization, protected alerts, and independent administrative accounts required? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Inventory vault type, region, workload, soft-delete state, retention, API or tool paths, and documented support. - Set retention from realistic detection and response time, with cost review for extended periods. - Alert on stop-protection, delete, retention reduction, vault change, and recovery operations through protected channels. - Exercise deletion, undelete, restore, and resume protection for each critical workload in a safe scope. Validate the restored application or data. - Add immutability, multiuser authorization, identity separation, and independent recovery documentation according to threat and continuity requirements. ## Verification and evidence - Preserve vault configuration, security features, retention, workload support, roles, alerts, and approval. - Record deletion and recovery timestamps, recovery points, commands or portal actions, and observed state transitions. - Validate restored data and application function outside the original failure path. - Demonstrate alerts reach responders with enough time to act before retention expires. ## Official references - [Secure by default with soft delete for Azure Backup](https://learn.microsoft.com/en-us/azure/backup/secure-by-default) — Microsoft ## Primary reference - Name: Secure by default with soft delete for Azure Backup - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/backup/secure-by-default - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Exercise Azure Backup soft-delete recovery before the retention clock expires,” DSE Security, https://update.dsesecurity.com/updates/azure-backup-soft-delete-recovery-exercise/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Exercise maritime-facility security duties through drills and full exercises > Use 33 CFR 105.220 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/exercise-maritime-facility-security-duties-through-drills-and-full-exercises/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:18+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.220 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.220 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Exercise maritime-facility security duties through drills and full exercises. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.220 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.220) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that drills and exercises test the proficiency of facility personnel in assigned security duties at all MARSEC Levels and the effective implementation of the Facility Security Plan (FSP). The research record locates this support at 33 CFR 105.220(a)(1) (eCFR anchor p-105.220(a)(1)). - Under 33 CFR 105, the rule requires that exercises are a full test of the security program and include substantial and active participation of FSOs, and may include government authorities and vessels visiting the facility. The research record locates this support at 33 CFR 105.220(c)(5) (eCFR anchor p-105.220(c)(5)). Only the traced statements above are asserted as source facts. Apply the review to essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives after confirming that the source and deployed context match. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.220(a)(1) (eCFR anchor p-105.220(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.220(c)(5) (eCFR anchor p-105.220(c)(5)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to 33 CFR 105.220(a)(1) (eCFR anchor p-105.220(a)(1)); 33 CFR 105.220(c)(5) (eCFR anchor p-105.220(c)(5)) and to observable material such as business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [33 CFR 105.220 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.220) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.220 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.220 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Exercise maritime-facility security duties through drills and full exercises,” DSE Security, https://update.dsesecurity.com/updates/exercise-maritime-facility-security-duties-through-drills-and-full-exercises/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Exercise the emergency-response program and correct documented weaknesses > Use 40 CFR 68.96 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/exercise-the-emergency-response-program-and-correct-documented-weaknesses/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:46+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.96 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.96 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Exercise the emergency-response program and correct documented weaknesses. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.96 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.96) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, as part of coordination with local emergency response officials required by section 68.93, the owner or operator must consult with these officials to establish an appropriate frequency for tabletop exercises, and must conduct a tabletop exercise before December 21, 2026, and at a minimum of at least once every three years thereafter. The research record locates this support at 40 CFR 68.96(b)(2)(i) (eCFR anchor p-68.96(b)(2)(i)). - Under 40 CFR 68, at least once each calendar year, the owner or operator of a stationary source with any Program 2 or Program 3 process must conduct an exercise of the stationary source’s emergency response notification mechanisms required under section 68.90(b)(3) or section 68.95(a)(1)(i), as appropriate, before December 19, 2024, and annually thereafter. The research record locates this support at 40 CFR 68.96(a) (eCFR anchor p-68.96(a)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives and the conditions the source actually describes. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.96(b)(2)(i) (eCFR anchor p-68.96(b)(2)(i)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.96(a) (eCFR anchor p-68.96(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations 40 CFR 68.96(b)(2)(i) (eCFR anchor p-68.96(b)(2)(i)); 40 CFR 68.96(a) (eCFR anchor p-68.96(a)) adjacent to the sanitized artifacts used for comparison. Prefer business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [40 CFR 68.96 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.96) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.96 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.96 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Exercise the emergency-response program and correct documented weaknesses,” DSE Security, https://update.dsesecurity.com/updates/exercise-the-emergency-response-program-and-correct-documented-weaknesses/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Expand guest-cluster S2D storage without resizing its existing disks > How should capacity be added to a Storage Spaces Direct guest cluster? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-202-expand-guest-cluster-s2d-storage-without-resizing-its-existing-disks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:49+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know How should capacity be added to a Storage Spaces Direct guest cluster? ## Potentially affected Administrators running Storage Spaces Direct inside a VM guest cluster. ## DSE recommendation Prepare a disk inventory for every guest node with identifiers, capacity, and presentation settings. ## Article ## Source facts Microsoft documents Storage Spaces Direct guest clusters as shared virtual storage built across multiple VMs. The exposed virtual disks must keep their existing size and characteristics. Its capacity-expansion procedure adds more virtual disks to each VM and then to the pool, recommending disks with the same size and characteristics as the existing ones. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-in-vm). ## Applicability Confirm the guest-cluster platform, underlying VM placement, and current virtual-disk layout. Review the guest-cluster requirements for the actual hypervisor before making a storage change. Keep a host-level disk expansion and a guest-cluster pool expansion as separate operations. ## DSE recommendation Prepare a disk inventory for every guest node with identifiers, capacity, and presentation settings. Have the storage owner review the additional-disk plan against that inventory. Record the expected new pool capacity and the assignment of every added disk before execution. Preserve a recoverable configuration record and schedule the change with the application owner rather than resizing an existing disk as an informal shortcut. ## Verification After the approved addition, inspect the disks presented to each guest and compare their characteristics with the plan. Confirm pool membership, health, and the expected capacity increase. Exercise a representative application transaction and record any asymmetric node configuration. Resolve missing or unexpected disks before creating or extending workloads on the new space. ## Official references [Microsoft Learn: Using Storage Spaces Direct in a virtual machine](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-in-vm). Source reviewed September 8, 2026. ## Primary reference - Name: Using Storage Spaces Direct in a virtual machine - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-in-vm - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Expand guest-cluster S2D storage without resizing its existing disks,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-202-expand-guest-cluster-s2d-storage-without-resizing-its-existing-disks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Expect Ntdsutil to attempt FSMO transfer before completing a seizure > Use AD Forest Recovery - Seizing an Operations Master Role to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/expect-ntdsutil-attempt-fsmo-transfer-before-seizure/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:21+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use AD Forest Recovery - Seizing an Operations Master Role to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of AD Forest Recovery - Seizing an Operations Master Role ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Expect Ntdsutil to attempt FSMO transfer before completing a seizure. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [AD Forest Recovery – Seizing an Operations Master Role](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-seizing-operations-master-role) from Microsoft supports the following bounded statements: - After seizure is confirmed in Ntdsutil, AD DS first attempts to transfer the role and proceeds with seizure only after that transfer fails. The research record locates this support at Seize an operations master role > paragraph after the role-command table. - After seizure, Ntdsutil lists the roles and LDAP name of each current holder, and an elevated Netdom Query FSMO command provides a second holder check. The research record locates this support at Seize an operations master role > completion and verification paragraph. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps and the conditions the source actually describes. ## What the source does not establish This forest-recovery source documents the command behavior; it does not itself establish when a former holder can safely return or replace required cleanup and recovery decisions. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Seize an operations master role > paragraph after the role-command table, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Seize an operations master role > completion and verification paragraph, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Seize an operations master role > paragraph after the role-command table; Seize an operations master role > completion and verification paragraph. Favor backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [AD Forest Recovery – Seizing an Operations Master Role](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-seizing-operations-master-role) — Microsoft ## Primary reference - Name: AD Forest Recovery - Seizing an Operations Master Role - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-seizing-operations-master-role - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Expect Ntdsutil to attempt FSMO transfer before completing a seizure,” DSE Security, https://update.dsesecurity.com/updates/expect-ntdsutil-attempt-fsmo-transfer-before-seizure/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Export video evidence so another person can verify it > A defensible video export preserves the requested scene, native data and metadata, records who handled it, verifies playback and integrity, and keeps an untouched master separate from working copies. - Canonical URL: https://update.dsesecurity.com/updates/export-video-evidence-so-another-person-can-verify-it/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, Video Surveillance - Reading time: 4 minutes ## What you need to know A defensible video export preserves the requested scene, native data and metadata, records who handled it, verifies playback and integrity, and keeps an untouched master separate from working copies. ## Potentially affected Organizations that may export surveillance video for law enforcement, insurers, counsel, human resources, safety investigations, or internal incident response. ## DSE recommendation Adopt a written export worksheet, test it on each recorder platform, preserve a verified master plus documented working copies, and involve qualified legal or forensic personnel when evidence may be contested. ## Article ## Source fact: an export can lose what matters NIST found that surveillance systems use many export formats and that conversion can degrade image quality, remove metadata, and delay analysis. Its [CCTV Digital Video Export Profile](https://www.nist.gov/publications/recommendation-closed-circuit-television-cctv-digital-video-export-profile-level-0) recommends interoperable video, precise time information, source and export metadata, and support for digital signatures. The [NIST Digital Video Exchange project](https://www.nist.gov/programs-projects/digital-video-exchange-standards) still describes a fragmented export landscape. A file that plays is therefore not proof that it is the best available copy. The Scientific Working Group on Digital Evidence (SWGDE) defines chain of custody as chronological documentation of an item’s movement, location, and possession. Its [digital-evidence collection guidance](https://www.swgde.org/18-f-002/) calls for contemporaneous notes, an evidence inventory, secure preservation, and records of transfers. SWGDE also cautions that video authentication evaluates provenance, content, and integrity; no single metadata field should be trusted in isolation. These are forensic principles, not a ruling that any particular export is legally admissible. ## DSE recommendation: freeze the request before touching the recorder Give the export a unique incident or request number. Record the requester, authority, purpose, camera names and identifiers, requested start and end, local time zone, known clock offset, and whether audio is in scope. Preserve the exact wording of the request. If the recorder clock is wrong, do not silently change the requested interval; document the observed offset and export enough surrounding time to protect context. Identify the source system: recorder or cloud tenant, site, software and version when available, camera channels, operator, export workstation, storage destination, and export start and finish. Capture relevant screen views or system reports without exposing unrelated footage. Do not change retention, time, recording, or camera settings merely to make the export easier. ## Preserve the richest supported copy - Export the system’s native or proprietary form when it retains the best available video, metadata, signatures, audit information, or multi-camera relationship. Include the supported player or documented retrieval instructions when licensing and policy permit. - Create a broadly playable derivative only as a convenience copy. Label it as a derivative and record the tool, version, settings, and operator. Never replace the native master with a transcoded file simply because the derivative is easier to open. - Record filenames, sizes, camera coverage, apparent gaps, audio presence, timestamps, and every error. Compute and retain an organization-approved cryptographic hash for each master file; a later matching value supports a conclusion that the bits have not changed. - Verify the export on a separate, supported workstation. Check beginning and end, representative points throughout, correct channel order, image orientation, audio, timestamp display, playback controls, and any required player. An export job marked successful is not an end-to-end test. ## Separate integrity technology from custody A camera-origin signature or export signature can provide valuable technical evidence within its documented boundaries. DSE’s related article, [Signed video: what it proves, what must survive export, and what it does not replace](https://update.dsesecurity.com/updates/axis-signed-video-integrity-export-boundaries/), addresses one implementation. A signature does not identify every person who possessed a drive, explain why a derivative was made, establish that the right time range was requested, or supply legal authority. Maintain the human record even when cryptographic verification passes. ## Create a master, working copies, and an accountable handoff Move the verified export from temporary media into approved, access-controlled evidence storage as soon as practical. Treat that preserved set as the master; restrict changes and perform review on a working copy. The custody record should identify the item, sender, recipient or facility, date and time with zone, purpose, transfer method, and acknowledgment. Record every duplication and disposition according to policy. Before declaring completion, have a second person reconcile the worksheet, file set, hashes, playback result, and requested scope. Escalate damaged recorders, overwritten intervals, unexplained gaps, proprietary-format failures, disputed authenticity, or anticipated litigation to qualified forensic and legal personnel. DSE recommends designing this workflow with counsel and the receiving agency rather than treating this article as legal advice. ## Official sources - [NISTIR 8161 Revision 1, CCTV Digital Video Export Profile](https://doi.org/10.6028/NIST.IR.8161r1) - [Standard Practice for Data Retrieval from Digital CCTV Systems](https://www.nist.gov/document/standard-practice-data-retrieval-digital-cctv-systems) - [SWGDE Best Practices for Digital Evidence Collection](https://www.swgde.org/18-f-002/) - [SWGDE Best Practices for Digital Video Authentication](https://www.swgde.org/23-v-001/) ## Primary reference - Name: NISTIR 8161 Revision 1 — CCTV Digital Video Export Profile - Authority: Digital Object Identifier - URL: https://doi.org/10.6028/NIST.IR.8161r1 - Source publication date: 2019-04-08 ## Citation and use Preferred citation: “Export video evidence so another person can verify it,” DSE Security, https://update.dsesecurity.com/updates/export-video-evidence-so-another-person-can-verify-it/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Export-DnsServerDnsSecPublicKey: export dns server dns sec public key with before-and-after evidence > Use Export-DnsServerDnsSecPublicKey to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/export-dnsserverdnssecpublickey-export-dns-server-dns-sec-public-key-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:47+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Export-DnsServerDnsSecPublicKey to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Export-DnsServerDnsSecPublicKey ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Export-DnsServerDnsSecPublicKey: export dns server dns sec public key with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Export-DnsServerDnsSecPublicKey](https://learn.microsoft.com/en-us/powershell/module/dnsserver/export-dnsserverdnssecpublickey?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Export-DnsServerDnsSecPublicKey cmdlet exports delegation signer (DS) or Domain Name System public key (DNSKEY) information for a Domain Name System Security Extensions (DNSSEC)-signed zone.” The research record locates this support at DESCRIPTION. - At Example 1: Export a trust anchor to a file share, Microsoft states: “This command exports the trust anchor (DS record) for Contoso.com to a file share.” The research record locates this support at Example 1: Export a trust anchor to a file share. The source support ends with the statements listed above. Use them to examine Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Export a trust anchor to a file share, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to DESCRIPTION; Example 1: Export a trust anchor to a file share and to observable material such as PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-219 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Export-DnsServerDnsSecPublicKey](https://learn.microsoft.com/en-us/powershell/module/dnsserver/export-dnsserverdnssecpublickey?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Export-DnsServerDnsSecPublicKey - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/export-dnsserverdnssecpublickey?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Export-DnsServerDnsSecPublicKey: export dns server dns sec public key with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/export-dnsserverdnssecpublickey-export-dns-server-dns-sec-public-key-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Export-DnsServerZone: export dns server zone with rollback checks > Use Export-DnsServerZone to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/export-dnsserverzone-export-dns-server-zone-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:04+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Export-DnsServerZone to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Export-DnsServerZone ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Export-DnsServerZone: export dns server zone with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Export-DnsServerZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/export-dnsserverzone?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Export-DnsServerZone cmdlet creates a file containing resource records for an Active Directory-integrated zone for troubleshooting purposes.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “This file is not in the same format as a file-backed zonefile.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-262 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Export-DnsServerZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/export-dnsserverzone?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Export-DnsServerZone - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/export-dnsserverzone?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Export-DnsServerZone: export dns server zone with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/export-dnsserverzone-export-dns-server-zone-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Expose shared recovery-resource conflicts across related service-continuity plans > Use CRR Supplemental Resource Guide, Volume 6: Service Continuity to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/expose-shared-recovery-resource-conflicts-across-related-service-continuity-plans/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:18:04+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use CRR Supplemental Resource Guide, Volume 6: Service Continuity to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of CRR Supplemental Resource Guide, Volume 6: Service Continuity ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Expose shared recovery-resource conflicts across related service-continuity plans. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [CRR Supplemental Resource Guide, Volume 6: Service Continuity](https://www.cisa.gov/sites/default/files/c3vp/crr_resources_guides/CRR_Resource_Guide-SC.pdf) from Cybersecurity and Infrastructure Security Agency supports the following bounded statements: - A service-continuity plan should identify other continuity plans that affect it or are affected by it. The research record locates this support at Plan Development, suggested plan content: Related Continuity Plans. - Dependency review should include upstream and downstream services, vendors, outsourced processes, technology suppliers, and competition for recovery staff and space. The research record locates this support at Plan Development, Step C: Identify dependencies and potential resource conflicts. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives only where the source and recorded environment align. ## What the source does not establish The guide identifies dependency and resource-conflict inputs; it does not prove that a documented dependency is available during an incident or assign enterprise recovery priority. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Plan Development, suggested plan content: Related Continuity Plans, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Plan Development, Step C: Identify dependencies and potential resource conflicts, which observable configuration, record, or test can confirm applicability here? - Within essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, which versions, roles, and configuration states define the review population? - Could identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Plan Development, suggested plan content: Related Continuity Plans; Plan Development, Step C: Identify dependencies and potential resource conflicts. Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [CRR Supplemental Resource Guide, Volume 6: Service Continuity](https://www.cisa.gov/sites/default/files/c3vp/crr_resources_guides/CRR_Resource_Guide-SC.pdf) — Cybersecurity and Infrastructure Security Agency ## Primary reference - Name: CRR Supplemental Resource Guide, Volume 6: Service Continuity - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/c3vp/crr_resources_guides/CRR_Resource_Guide-SC.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Expose shared recovery-resource conflicts across related service-continuity plans,” DSE Security, https://update.dsesecurity.com/updates/expose-shared-recovery-resource-conflicts-across-related-service-continuity-plans/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Extend business impact analysis from availability to every mission-relevant loss > Use IR 8286D, Using Business Impact Analysis to Inform Risk Prioritization and Response to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/extend-business-impact-analysis-from-availability-to-every-mission-relevant-loss/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:18:03+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use IR 8286D, Using Business Impact Analysis to Inform Risk Prioritization and Response to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of IR 8286D, Using Business Impact Analysis to Inform Risk Prioritization and Response ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Extend business impact analysis from availability to every mission-relevant loss. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [IR 8286D, Using Business Impact Analysis to Inform Risk Prioritization and Response](https://csrc.nist.gov/pubs/ir/8286/d/upd1/final) from National Institute of Standards and Technology supports the following bounded statements: - NIST IR 8286D says business impact analysis can extend beyond availability to the mission impact of any type of loss. The research record locates this support at Abstract. - The described process links mission objectives to enabling assets, criticality and sensitivity factors, and risk prioritization and response. The research record locates this support at Abstract. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives only where the source and recorded environment align. ## What the source does not establish The publication does not determine an organization’s essential functions, impact values, recovery objectives, or acceptable outage durations. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Abstract, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Abstract, which observable configuration, record, or test can confirm applicability here? - Within essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, which versions, roles, and configuration states define the review population? - Could identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Abstract; Abstract. Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [IR 8286D, Using Business Impact Analysis to Inform Risk Prioritization and Response](https://csrc.nist.gov/pubs/ir/8286/d/upd1/final) — National Institute of Standards and Technology ## Primary reference - Name: IR 8286D, Using Business Impact Analysis to Inform Risk Prioritization and Response - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/ir/8286/d/upd1/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Extend business impact analysis from availability to every mission-relevant loss,” DSE Security, https://update.dsesecurity.com/updates/extend-business-impact-analysis-from-availability-to-every-mission-relevant-loss/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Extend identity threat investigations to SailPoint-managed accounts > Use How Microsoft Defender for Identity protects your SailPoint Identity Security Cloud accounts (Preview) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/extend-identity-threat-investigations-to-sailpoint-accounts/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:16+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use How Microsoft Defender for Identity protects your SailPoint Identity Security Cloud accounts (Preview) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of How Microsoft Defender for Identity protects your SailPoint Identity Security Cloud accounts (Preview) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Extend identity threat investigations to SailPoint-managed accounts. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [How Microsoft Defender for Identity protects your SailPoint Identity Security Cloud accounts (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/sail-point-overview) from Microsoft supports the following bounded statements: - Connecting SailPoint Identity Security Cloud extends detection, investigation, and response across cloud and on-premises identity infrastructure. The research record locates this support at Opening overview. - The integration adds SailPoint accounts to the identity inventory, correlates them with Active Directory and Entra identities, and exposes SailPoint data in advanced hunting. The research record locates this support at Capabilities table. Keep the evidence boundary at these traced claims. They support a review of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The integration is marked Preview and does not prove that every SailPoint account is correlated or every risk is detected. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Capabilities table, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to Opening overview; Capabilities table and to observable material such as integration configuration, connectivity tests, event timestamps, alert correlation, role assignments, and case records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [How Microsoft Defender for Identity protects your SailPoint Identity Security Cloud accounts (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/sail-point-overview) — Microsoft ## Primary reference - Name: How Microsoft Defender for Identity protects your SailPoint Identity Security Cloud accounts (Preview) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/sail-point-overview - Source publication date: 2026-03-04 ## Citation and use Preferred citation: “Extend identity threat investigations to SailPoint-managed accounts,” DSE Security, https://update.dsesecurity.com/updates/extend-identity-threat-investigations-to-sailpoint-accounts/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Extend the AD schema and delegate rights before LAPS rollout > Use Get started with Windows LAPS and Windows Server Active Directory to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/extend-ad-schema-and-delegate-rights-before-laps/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:00+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Get started with Windows LAPS and Windows Server Active Directory to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get started with Windows LAPS and Windows Server Active Directory ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Extend the AD schema and delegate rights before LAPS rollout. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get started with Windows LAPS and Windows Server Active Directory](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-windows-server-active-directory) from Microsoft supports the following bounded statements: - The AD-backed Windows LAPS workflow updates the schema and grants managed devices permission to write their passwords. The research record locates this support at Sections: Update the schema; Grant the managed device permission. - A domain functional level earlier than 2016 cannot use Windows LAPS password encryption. The research record locates this support at Section: Domain functional level and domain controller operating system version requirements. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios and the conditions the source actually describes. ## What the source does not establish Separate device write rights, password-read rights, and expiration rights during delegation. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Sections: Update the schema; Grant the managed device permission, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section: Domain functional level and domain controller operating system version requirements, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios are in and out of scope? - Which condition in Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Sections: Update the schema; Grant the managed device permission; Section: Domain functional level and domain controller operating system version requirements. Favor policy exports, directory access-control entries, sanitized client events, rotation tests, retrieval authorization, and exception records, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Get started with Windows LAPS and Windows Server Active Directory](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-windows-server-active-directory) — Microsoft ## Primary reference - Name: Get started with Windows LAPS and Windows Server Active Directory - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-windows-server-active-directory - Source publication date: 2025-04-11 ## Citation and use Preferred citation: “Extend the AD schema and delegate rights before LAPS rollout,” DSE Security, https://update.dsesecurity.com/updates/extend-ad-schema-and-delegate-rights-before-laps/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Filter private IPv4 prefixes at public routing boundaries > Use RFC 1918 — Address Allocation for Private Internets to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/filter-private-ipv4-prefixes-at-public-routing-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:30+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 1918 — Address Allocation for Private Internets to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 1918 — Address Allocation for Private Internets ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Filter private IPv4 prefixes at public routing boundaries. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 1918 — Address Allocation for Private Internets](https://www.rfc-editor.org/rfc/rfc1918.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - The private IPv4 blocks are 10/8, 172.16/12, and 192.168/16; their addresses are unique only within cooperating private networks. The research record locates this support at Section 3 (Private Address Space). - Private routing information must not cross inter-enterprise links, and packets with private sources or destinations should not be forwarded across those links. The research record locates this support at Section 3 (Private Address Space), routing boundary rules. - Enterprise border routers should filter packet and route leakage in both directions, including inbound private routes that would point private space outside the enterprise. The research record locates this support at Section 5 (Operational Considerations). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 3 (Private Address Space), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Private Address Space), routing boundary rules, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5 (Operational Considerations), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to Section 3 (Private Address Space); Section 3 (Private Address Space), routing boundary rules; Section 5 (Operational Considerations) and to observable material such as configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 1918 — Address Allocation for Private Internets](https://www.rfc-editor.org/rfc/rfc1918.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 1918 — Address Allocation for Private Internets - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc1918.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Filter private IPv4 prefixes at public routing boundaries,” DSE Security, https://update.dsesecurity.com/updates/filter-private-ipv4-prefixes-at-public-routing-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Filter Windows DNS queries only with explicit match and timeout tests > Use Use DNS Policy for Applying Filters on DNS Queries to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/filter-windows-dns-queries-only-with-explicit-match-and-timeout-tests/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:31+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Use DNS Policy for Applying Filters on DNS Queries to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Use DNS Policy for Applying Filters on DNS Queries ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Filter Windows DNS queries only with explicit match and timeout tests. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Use DNS Policy for Applying Filters on DNS Queries](https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/apply-filters-on-dns-queries) from Microsoft supports the following bounded statements: - Windows DNS Policy query filters can vary server behavior based on a query and the client that sent it. The research record locates this support at Article introduction. - Documented filter criteria include client subnet, transport, IP version, server interface, FQDN, query type, and time of day. The research record locates this support at Section ‘Query filter criteria’. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish A DNS query filter is not a complete malicious-domain control, and an IGNORE action intentionally produces no response and a client timeout. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Article introduction, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section ‘Query filter criteria’, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Article introduction; Section ‘Query filter criteria’ to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Use DNS Policy for Applying Filters on DNS Queries](https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/apply-filters-on-dns-queries) — Microsoft ## Primary reference - Name: Use DNS Policy for Applying Filters on DNS Queries - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/apply-filters-on-dns-queries - Source publication date: 2021-07-29 ## Citation and use Preferred citation: “Filter Windows DNS queries only with explicit match and timeout tests,” DSE Security, https://update.dsesecurity.com/updates/filter-windows-dns-queries-only-with-explicit-match-and-timeout-tests/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Find temporary and flexible wiring that has become permanent infrastructure > Use 29 CFR 1910.305 - Wiring methods, components, and equipment to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/find-temporary-and-flexible-wiring-that-has-become-permanent-infrastructure/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:13+00:00 - Modified: 2026-08-27T13:06:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.305 - Wiring methods, components, and equipment to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.305 - Wiring methods, components, and equipment ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Find temporary and flexible wiring that has become permanent infrastructure. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.305 – Wiring methods, components, and equipment](https://www.ecfr.gov/current/title-29/section-1910.305) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, the rule requires that flexible cords used in show windows and showcases be Type S, SE, SEO, SEOO, SJ, SJE, SJEO, SJEOO, SJO, SJOO, SJT, SJTO, SJTOO, SO, SOO, ST, STO, or STOO, except for the wiring of chain-supported lighting fixtures and supply cords for portable lamps and other merchandise being displayed or exhibited. The research record locates this support at 29 CFR 1910.305(g)(1)(v) (eCFR anchor p-1910.305(g)(1)(v)). - Under 29 CFR 1910, a conductor of a flexible cord or cable that is used as a grounded conductor or an equipment grounding conductor must be distinguishable from other conductors. The research record locates this support at 29 CFR 1910.305(g)(2)(i) (eCFR anchor p-1910.305(g)(2)(i)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths only where the source and recorded environment align. ## What the source does not establish Federal workplace rule; electrical code, listed uses, environment, load, and local requirements must be applied to each installation. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 29 CFR 1910.305(g)(1)(v) (eCFR anchor p-1910.305(g)(1)(v)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.305(g)(2)(i) (eCFR anchor p-1910.305(g)(2)(i)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and sanitize protected material before retention. ## Verification and evidence Keep the source locations 29 CFR 1910.305(g)(1)(v) (eCFR anchor p-1910.305(g)(1)(v)); 29 CFR 1910.305(g)(2)(i) (eCFR anchor p-1910.305(g)(2)(i)) adjacent to the sanitized artifacts used for comparison. Prefer facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [29 CFR 1910.305 – Wiring methods, components, and equipment](https://www.ecfr.gov/current/title-29/section-1910.305) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.305 - Wiring methods, components, and equipment - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.305 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Find temporary and flexible wiring that has become permanent infrastructure,” DSE Security, https://update.dsesecurity.com/updates/find-temporary-and-flexible-wiring-that-has-become-permanent-infrastructure/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Find unsigned LDAP binds before requiring signing > Requiring LDAP signing rejects unsigned SASL binds and cleartext simple binds; Microsoft provides summary and detailed directory events to find dependent clients before enforcement. - Canonical URL: https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:08+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Requiring LDAP signing rejects unsigned SASL binds and cleartext simple binds; Microsoft provides summary and detailed directory events to find dependent clients before enforcement. ## Potentially affected Active Directory Domain Services and AD LDS environments with applications, appliances, scripts, or identity systems that bind over LDAP. ## DSE recommendation Collect bind events across every directory server, map each client and identity to an owner, migrate to signed SASL or protected TLS as supported, and enforce only after extended clean observation. ## Article Bottom line: Requiring LDAP signing on Windows directory servers rejects SASL binds that do not request integrity and simple binds sent over an unprotected connection. Microsoft warns that dependent clients stop working. Use directory events to discover and remediate those clients before enforcement. ## Source fact: what Microsoft documents Microsoft’s [LDAP signing guide](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server) explains that unsigned LDAP traffic is susceptible to replay and man-in-the-middle modification. A directory server configured to require signing rejects unsigned SASL binds and LDAP simple binds performed over a non-SSL/TLS connection. Microsoft documents Event ID 2887 as a daily summary when such binds are detected but permitted. More detailed LDAP Interface Events logging can produce Event ID 2889 with the client IP address and attempted identity for each problem bind. When the server rejects problem binds, Event ID 2888 summarizes rejected attempts. The page recommends configuring clients to stop using the unsafe bind patterns and observing an extended period without detection before requiring signing. It includes Group Policy, AD LDS, and ldp.exe verification procedures. ## What the source does not establish One quiet domain controller does not prove the forest is ready. Rare monthly jobs, disaster-recovery systems, isolated networks, load-balanced directory clients, or applications pointed at another server may be missed. LDAP signing provides integrity; it is not the same as TLS encryption or LDAP channel binding. An IP address in an event does not identify the application owner, and a successful bind does not prove least-privilege directory access. ## Applicability questions - Which AD DS domains, read-only domain controllers, AD LDS instances, sites, and network segments receive LDAP? - Which applications, appliances, physical-security products, scripts, and service accounts bind to them? - Does each client use signed SASL, simple bind over TLS, unsigned SASL, or cleartext simple bind? - Does the observation period include month-end, certificate renewal, failover, recovery, and dormant integrations? - Is LDAP channel binding being assessed separately where TLS and applicable authentication are used? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Enable the documented discovery logging on all relevant directory servers for an approved, time-bounded period and protect the resulting identity and IP data. - Map every problem bind to an application, owner, identity, server, bind type, business purpose, and supported remediation. - Configure clients for signed SASL or an appropriately protected TLS path according to vendor support. Correct certificate trust and name validation where TLS is used. - Observe an extended clean period that covers low-frequency workloads, then stage the server requirement with rollback criteria. - Monitor rejected-bind events and application health after enforcement; do not permanently weaken the server for an unidentified client. ## Verification and evidence - Preserve discovery scope, logging level, observation dates, event exports, and client-remediation register. - Record successful vendor-supported bind tests after remediation without exposing credentials. - Use the documented negative test to prove an unsigned simple bind is rejected after enforcement. - Confirm all directory servers have the intended effective policy and no unexpected rejection events persist. ## Official references - [How to enable LDAP signing in Windows Server](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server) — Microsoft ## Primary reference - Name: How to enable LDAP signing in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Find unsigned LDAP binds before requiring signing,” DSE Security, https://update.dsesecurity.com/updates/active-directory-ldap-signing-bind-discovery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Finish authentication-method policy migration without opening a sign-in gap > Microsoft's authentication methods migration moves MFA and self-service password reset method control into one policy, with transitional states that require an exact before-and-after comparison. - Canonical URL: https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:29+00:00 - Modified: 2026-08-25T21:36:18+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Microsoft's authentication methods migration moves MFA and self-service password reset method control into one policy, with transitional states that require an exact before-and-after comparison. ## Potentially affected Microsoft Entra tenants with authentication methods still represented in legacy MFA or self-service password reset policy settings. ## DSE recommendation Inventory effective legacy and modern method scope, enter migration deliberately, test sign-in and recovery populations, and preserve evidence before selecting Migration Complete. ## Article Bottom line: Microsoft provides migration states for moving authentication-method administration from legacy multifactor authentication and self-service password reset settings to the Authentication methods policy. During transition, more than one policy can affect a user. Migration should begin with an effective-state inventory and end only after both sign-in and recovery tests prove the intended result. ## Source fact: what Microsoft documents Microsoft’s [migration guide](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage) tells administrators to capture the methods available in current legacy policies, select Migration in progress, and configure the Authentication methods policy to match the intended state. Microsoft explains that a method enabled in both legacy policies should be represented for the intended users in the modern policy, while methods disabled in both should remain disabled. The broader Microsoft documentation defines migration states. In Migration in progress, the Authentication methods policy can govern authentication and password reset while legacy settings are still respected. In Migration Complete, only the Authentication methods policy is used for supported method management and the legacy method settings are ignored. Microsoft calls out remaining legacy SSPR controls and method-specific exceptions, so administrators must read the current page rather than assuming every setting moves identically. ## What the source does not establish The guide does not know which users have registered which methods, whether those methods satisfy an organization’s authentication requirements, or whether a user can complete recovery without helpdesk intervention. It does not prove that Conditional Access, authentication strengths, registration campaigns, guest policies, or break-glass access remain correct after the method-policy change. ## Applicability questions - What methods are enabled in the legacy MFA policy, legacy SSPR policy, and Authentication methods policy, and for which populations? - Which users depend on SMS, voice, security questions, hardware tokens, certificates, passkeys, or Microsoft Authenticator? - Are administrators, guests, frontline workers, shared-device users, and emergency accounts tested separately? - Which Conditional Access and authentication-strength policies depend on a method being registered and usable? - What current Microsoft migration state and licensing apply to the tenant? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Export or document every relevant legacy and modern setting, target group, exclusion, and registered-method report before changing migration state. - Build an effective-state matrix showing whether each method is intended for authentication, SSPR, or both for each population. - Enter Migration in progress and reproduce the desired method scope in controlled groups. Avoid broad enablement merely to make the matrices look equal. - Test new registration, normal sign-in, MFA challenge, password reset, lost-device recovery, helpdesk recovery, and emergency administration. - Select Migration Complete only after discrepancies are resolved and a rollback decision has been documented. ## Verification and evidence - Preserve before-and-after policy exports or screenshots and the migration-state change record. - Record test identities, method registrations, sign-in results, SSPR results, and relevant sign-in log details. - Compare intended groups with users enabled by each method policy and investigate unexpected overlap. - Schedule a post-change review for failed registration, MFA, and SSPR events and helpdesk volume. ## Official references - [How to migrate to the Authentication methods policy](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage) — Microsoft ## Primary reference - Name: How to migrate to the Authentication methods policy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-methods-manage - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Finish authentication-method policy migration without opening a sign-in gap,” DSE Security, https://update.dsesecurity.com/updates/entra-authentication-methods-policy-migration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Finish Defender for Identity sensor settings before judging telemetry coverage > Use Configure Microsoft Defender for Identity sensor settings to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/finish-sensor-settings-before-judging-telemetry-coverage/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:32+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Configure Microsoft Defender for Identity sensor settings to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Configure Microsoft Defender for Identity sensor settings ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Finish Defender for Identity sensor settings before judging telemetry coverage. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Configure Microsoft Defender for Identity sensor settings](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-sensor-settings) from Microsoft supports the following bounded statements: - Sensor settings must be configured correctly before Defender for Identity data becomes visible. The research record locates this support at Opening overview. - Microsoft states that additional configuration and integration are needed to use the product’s full capabilities. The research record locates this support at Opening overview. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health and the conditions the source actually describes. ## What the source does not establish Visible data is not proof of complete event coverage, correct alert tuning, or healthy sensors. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from Opening overview; Opening overview to the observed environment. Useful domain evidence includes sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Configure Microsoft Defender for Identity sensor settings](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-sensor-settings) — Microsoft ## Primary reference - Name: Configure Microsoft Defender for Identity sensor settings - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-sensor-settings - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Finish Defender for Identity sensor settings before judging telemetry coverage,” DSE Security, https://update.dsesecurity.com/updates/finish-sensor-settings-before-judging-telemetry-coverage/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Finish the Windows Secure Boot trust-chain transition from 2011 certificates > Windows devices can keep booting after the 2011 Secure Boot certificates expire yet miss future early-boot protections. Inventory status, update OEM firmware, pilot by hardware family, and verify the 2023 trust chain with evidence. - Canonical URL: https://update.dsesecurity.com/updates/windows-secure-boot-2011-certificate-rotation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:06:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Windows devices can keep booting after the 2011 Secure Boot certificates expire yet miss future early-boot protections. Inventory status, update OEM firmware, pilot by hardware family, and verify the 2023 trust chain with evidence. ## Potentially affected Supported Windows client devices using UEFI Secure Boot; OEM firmware; BitLocker-protected endpoints; device-management, update, recovery, and hardware-support processes. ## DSE recommendation Inventory Secure Boot certificate state and firmware by model, remediate OEM firmware first, pilot the supported Microsoft update path across representative BitLocker-enabled devices, and reconcile every incomplete or failed result. ## Article ## Source facts: normal startup does not prove the trust chain is current Microsoft’s [Windows Secure Boot certificate guidance](https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/update-secure-boot-certificates) says some devices still use certificates issued in 2011 with an expiration in June 2026. An affected computer may continue to start and receive ordinary Windows updates after that point, but it may be unable to receive future Secure Boot protections for the boot manager and other early-boot components. Availability alone is therefore not a reliable compliance test. The documented transition is to the 2023 Secure Boot certificate authorities. Microsoft identifies estate-level signals for unfinished work: UEFICA2023Status is not set to Updated, System log event 1801 indicates an incomplete update, and event 1795 identifies a firmware error. Older or incompatible firmware raises the risk of validation errors, BitLocker recovery prompts or loops, startup hangs, and boot failure. Microsoft advises organizations to identify devices still using the old certificates, update OEM firmware first, and pilot certificate servicing on a representative group. That group should span OEMs, firmware versions, and BitLocker-enabled systems. Supported deployment routes include Microsoft Intune, registry settings, Windows configuration service provider controls, and Group Policy. These are alternative control paths into a sensitive firmware-backed change; assigning one does not by itself prove that the firmware accepted it. ## DSE recommendation: run the transition as hardware lifecycle work Build one readiness record per hardware family, not one tenant-wide “deployed” flag. Include manufacturer, exact model, UEFI version, Secure Boot state, certificate status, Windows build, BitLocker protection and recovery-key escrow, management authority, update source, warranty state, and an accountable owner. Devices that cannot report the required evidence belong in an exception queue, not in the compliant total. - Establish a recoverable baseline. Confirm that each pilot starts cleanly, reports healthy Secure Boot, has current approved OEM firmware, and has a retrievable BitLocker recovery key. Record console or hands-on recovery options for remote devices before changing the trust database. - Pilot by meaningful variation. Select multiple units from every significant model and firmware branch. Include laptops with docks, desktops, remote systems, dual-boot or specialized configurations, and devices that previously required firmware exceptions. A single new laptop does not represent the estate. - Observe the complete restart path. Apply only the documented servicing method, perform required restarts, and verify normal boot, BitLocker behavior, Windows sign-in, device health, management check-in, and the application workflows important to that device class. - Prove the resulting state. Collect UEFICA2023Status, relevant System events, firmware version, last restart, and deployment result after the change. Treat event 1801, event 1795, a missing status, or a device that never checked back in as unresolved until investigated. - Advance in controlled rings. Expand by model only after the preceding ring meets explicit success thresholds and completes an observation period. Pause a model when recovery prompts, slow boots, firmware failures, or support contacts rise above the approved limit. - Close unsupported outcomes. For equipment that cannot accept compatible firmware or the new certificates, document vendor findings, business exposure, compensating controls, replacement date, and leadership acceptance. Do not leave “temporarily excluded” without an expiration. Measure updated status by eligible device, success by model, incomplete and firmware-error events, devices missing evidence, unexpected recovery prompts, and exception age. Preserve the pre-change inventory and pilot evidence with the change record. The goal is not to force a registry value across every endpoint; it is to maintain a verifiable boot trust chain while retaining a tested way to recover devices that react badly. The closeout packet should name devices that were powered off, loaned out, unmanaged, or awaiting repair during the rollout. Give each population a deadline and an intercept control so it cannot quietly return to production without assessment. Re-sample updated models after later firmware releases and preserve vendor escalation findings for future replacements. ## Official references - Microsoft Learn, [Update Secure Boot Certificates for Windows Devices](https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/update-secure-boot-certificates), May 1, 2026; reviewed August 11, 2026. ## Primary reference - Name: Microsoft Learn: Update Secure Boot Certificates for Windows Devices - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/update-secure-boot-certificates - Source publication date: 2026-05-01 ## Citation and use Preferred citation: “Finish the Windows Secure Boot trust-chain transition from 2011 certificates,” DSE Security, https://update.dsesecurity.com/updates/windows-secure-boot-2011-certificate-rotation/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Follow the NPS dependencies after an address or name change > What must be rechecked when an NPS server or proxy is renamed or readdressed? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-222-follow-the-nps-dependencies-after-an-address-or-name-change/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:29+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know What must be rechecked when an NPS server or proxy is renamed or readdressed? ## Potentially affected Administrators changing the name or IP address of NPS RADIUS servers and proxies. ## DSE recommendation Prepare a dependency checklist with the old and new endpoint, the owner of each access device or proxy, and the corresponding update step. ## Article ## Source facts Microsoft directs administrators to verify that an address change preserves authentication, authorization, and accounting paths. For a multihomed proxy bound to a specific address, the NPS port settings must be updated with the new address. After a name change, remote RADIUS server groups configured with computer names must be updated. When certificate-based authentication is deployed, renaming NPS invalidates its server certificate and requires obtaining a new certificate. The page also calls for checking SQL logging connectivity after an address change. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-verify). ## Applicability Inventory consumers of the old server name and address before scheduling the change. Distinguish direct-IP device settings from name-based remote-server-group entries. Include accounting and logging dependencies rather than limiting acceptance to a successful sign-in. ## DSE recommendation Prepare a dependency checklist with the old and new endpoint, the owner of each access device or proxy, and the corresponding update step. Preserve current bindings and remote-server-group settings. Ask the logging owner to identify the expected post-change records and a way to detect a silent loss. Coordinate the change window so the related endpoints are not updated independently without a shared plan. ## Verification Trace an authorized test request through each relevant device or proxy after the change. Verify the selected NPS endpoint and the expected accounting or SQL logging result. Check that configuration no longer depends on the retired name or address. Record remaining exceptions and investigate each before closing the migration. ## Official references [Microsoft Learn: Verify Configuration After NPS Changes](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-verify). Source reviewed September 8, 2026. ## Primary reference - Name: Verify Configuration After NPS Changes - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-verify - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Follow the NPS dependencies after an address or name change,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-222-follow-the-nps-dependencies-after-an-address-or-name-change/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Forward Windows events to standalone identity sensors for added detection context > Use Configure Windows event forwarding to your Defender for Identity standalone sensor to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/forward-windows-events-to-standalone-identity-sensors/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:25+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Configure Windows event forwarding to your Defender for Identity standalone sensor to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Configure Windows event forwarding to your Defender for Identity standalone sensor ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Forward Windows events to standalone identity sensors for added detection context. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Configure Windows event forwarding to your Defender for Identity standalone sensor](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-event-forwarding) from Microsoft supports the following bounded statements: - Windows event forwarding can enhance standalone-sensor detections with events that are unavailable from domain-controller network traffic. The research record locates this support at Opening overview. - Standalone sensors still do not collect ETW entries used by multiple detections, and Microsoft recommends the standard sensor for full coverage. The research record locates this support at Coverage limitation paragraph. Only the traced statements above are asserted as source facts. Apply the review to Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health after confirming that the source and deployed context match. ## What the source does not establish Forward only supported audited events and do not represent WEF as equivalent to a standard sensor’s ETW collection. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Coverage limitation paragraph, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Coverage limitation paragraph through sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Configure Windows event forwarding to your Defender for Identity standalone sensor](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-event-forwarding) — Microsoft ## Primary reference - Name: Configure Windows event forwarding to your Defender for Identity standalone sensor - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-event-forwarding - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Forward Windows events to standalone identity sensors for added detection context,” DSE Security, https://update.dsesecurity.com/updates/forward-windows-events-to-standalone-identity-sensors/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Gate HTTP early data on replay-safe request semantics > Use RFC 8470 — Using Early Data in HTTP to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/gate-http-early-data-on-replay-safe-request-semantics/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:54+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8470 — Using Early Data in HTTP to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8470 — Using Early Data in HTTP ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Gate HTTP early data on replay-safe request semantics. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8470 — Using Early Data in HTTP](https://www.rfc-editor.org/rfc/rfc8470.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Without resource-specific permission, an origin server must reject early data or defer request processing until the TLS handshake completes. The research record locates this support at Section 3 (Supporting Early Data in HTTP Servers). - Clients may send known-safe methods in early data but must not send unsafe or unknown-safety methods; a 425 response requires retry without early data. The research record locates this support at Sections 4 (Using Early Data in HTTP Clients) and 5.2 (The 425 (Too Early) Status Code). - An intermediary marks replay-exposed forwarded requests with Early-Data: 1, cannot remove that field, and cannot forward early unless the previous hop did or safe retry is known. The research record locates this support at Sections 4 (Using Early Data in HTTP Clients) and 5.1 (The Early-Data Header Field). Only the traced statements above are asserted as source facts. Apply the review to clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 3 (Supporting Early Data in HTTP Servers), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 4 (Using Early Data in HTTP Clients) and 5.2 (The 425 (Too Early) Status Code), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 4 (Using Early Data in HTTP Clients) and 5.1 (The Early-Data Header Field), which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for DNS, certificates, identity providers, time, content delivery, network paths, and application ownership and sanitize protected material before retention. ## Verification and evidence Keep the source locations Section 3 (Supporting Early Data in HTTP Servers); Sections 4 (Using Early Data in HTTP Clients) and 5.2 (The 425 (Too Early) Status Code); Sections 4 (Using Early Data in HTTP Clients) and 5.1 (The Early-Data Header Field) adjacent to the sanitized artifacts used for comparison. Prefer request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 8470 — Using Early Data in HTTP](https://www.rfc-editor.org/rfc/rfc8470.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8470 — Using Early Data in HTTP - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8470.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Gate HTTP early data on replay-safe request semantics,” DSE Security, https://update.dsesecurity.com/updates/gate-http-early-data-on-replay-safe-request-semantics/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Generate and route ULAs without leaking them as global IPv6 space > Use RFC 4193 — Unique Local IPv6 Unicast Addresses to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/generate-and-route-ulas-without-leaking-them-as-global-ipv6-space/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:28+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4193 — Unique Local IPv6 Unicast Addresses to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4193 — Unique Local IPv6 Unicast Addresses ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Generate and route ULAs without leaking them as global IPv6 space. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4193 — Unique Local IPv6 Unicast Addresses](https://www.rfc-editor.org/rfc/rfc4193.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A unique local IPv6 prefix uses FC00::/7, a local-assignment bit, a 40-bit Global ID, a 16-bit subnet ID, and a 64-bit interface ID. The research record locates this support at Section 3.1 (Format). - A locally assigned Global ID must be generated with a pseudo-random algorithm to make independent /48 prefix collisions highly unlikely. The research record locates this support at Section 3.2.1 (Locally Assigned Global IDs). - Exterior routing should ignore and not advertise FC00::/7 by default, while site borders should reject local-address packets unless explicitly routed for a specific /48 or longer prefix. The research record locates this support at Section 4.1 (Routing). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 3.1 (Format), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3.2.1 (Locally Assigned Global IDs), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4.1 (Routing), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to Section 3.1 (Format); Section 3.2.1 (Locally Assigned Global IDs); Section 4.1 (Routing) and to observable material such as configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 4193 — Unique Local IPv6 Unicast Addresses](https://www.rfc-editor.org/rfc/rfc4193.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4193 — Unique Local IPv6 Unicast Addresses - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4193.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Generate and route ULAs without leaking them as global IPv6 space,” DSE Security, https://update.dsesecurity.com/updates/generate-and-route-ulas-without-leaking-them-as-global-ipv6-space/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Generate ICMPv6 errors without replying to prohibited packet classes > Use RFC 4443 — Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/generate-icmpv6-errors-without-replying-to-prohibited-packet-classes/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:29+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4443 — Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4443 — Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Generate ICMPv6 errors without replying to prohibited packet classes. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4443 — Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification](https://www.rfc-editor.org/rfc/rfc4443.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An ICMPv6 error must not be generated in response to another ICMPv6 error or to an ICMPv6 Redirect message. The research record locates this support at Section 2.4 (Message Processing Rules), rules e.1 and e.2. - An error must not answer IPv6 or link-layer multicast, except for Packet Too Big and the defined Parameter Problem Code 2 case. The research record locates this support at Section 2.4 (Message Processing Rules), rules e.3 and e.4. - An error must not be generated for a packet whose source does not uniquely identify one node, including unspecified, multicast, or known anycast sources. The research record locates this support at Section 2.4 (Message Processing Rules), rule e.6. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 2.4 (Message Processing Rules), rules e.1 and e.2, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.4 (Message Processing Rules), rules e.3 and e.4, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2.4 (Message Processing Rules), rule e.6, which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to Section 2.4 (Message Processing Rules), rules e.1 and e.2; Section 2.4 (Message Processing Rules), rules e.3 and e.4; Section 2.4 (Message Processing Rules), rule e.6 and to observable material such as configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 4443 — Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification](https://www.rfc-editor.org/rfc/rfc4443.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4443 — Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4443.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Generate ICMPv6 errors without replying to prohibited packet classes,” DSE Security, https://update.dsesecurity.com/updates/generate-icmpv6-errors-without-replying-to-prohibited-packet-classes/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Geo-steer Windows DNS only after validating client-subnet classification > Use Use DNS Policy for Application Load Balancing With Geo-Location Awareness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/geo-steer-windows-dns-only-after-validating-client-subnet-classification/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:30+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Use DNS Policy for Application Load Balancing With Geo-Location Awareness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Use DNS Policy for Application Load Balancing With Geo-Location Awareness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Geo-steer Windows DNS only after validating client-subnet classification. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Use DNS Policy for Application Load Balancing With Geo-Location Awareness](https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/app-lb-geo) from Microsoft supports the following bounded statements: - Windows DNS Policy can load-balance application answers with geo-location awareness. The research record locates this support at Article introduction. - The documented configuration groups IPv4 or IPv6 address space into DNS client subnets used by policy. The research record locates this support at Section ‘Create the DNS Client Subnets’. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The example does not guarantee Geo-IP accuracy, application health, resolver-source visibility, or equitable load distribution in another network. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Article introduction, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section ‘Create the DNS Client Subnets’, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Keep the source locations Article introduction; Section ‘Create the DNS Client Subnets’ adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Use DNS Policy for Application Load Balancing With Geo-Location Awareness](https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/app-lb-geo) — Microsoft ## Primary reference - Name: Use DNS Policy for Application Load Balancing With Geo-Location Awareness - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/app-lb-geo - Source publication date: 2021-07-29 ## Citation and use Preferred citation: “Geo-steer Windows DNS only after validating client-subnet classification,” DSE Security, https://update.dsesecurity.com/updates/geo-steer-windows-dns-only-after-validating-client-subnet-classification/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADAccountAuthorizationGroup: inventory adaccount authorization group with bounded evidence > Use Get-ADAccountAuthorizationGroup to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adaccountauthorizationgroup-inventory-adaccount-authorization-group-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:21+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADAccountAuthorizationGroup to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADAccountAuthorizationGroup ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-ADAccountAuthorizationGroup: inventory adaccount authorization group with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADAccountAuthorizationGroup](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adaccountauthorizationgroup?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADAccountAuthorizationGroup cmdlet gets the security groups from the specified user, computer, or service accounts token.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “This cmdlet requires a global catalog to perform the group search.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations DESCRIPTION; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-185 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Get-ADAccountAuthorizationGroup](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adaccountauthorizationgroup?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADAccountAuthorizationGroup - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adaccountauthorizationgroup?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADAccountAuthorizationGroup: inventory adaccount authorization group with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-adaccountauthorizationgroup-inventory-adaccount-authorization-group-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADAccountResultantPasswordReplicationPolicy: inventory adaccount resultant password replication policy > Use Get-ADAccountResultantPasswordReplicationPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adaccountresultantpasswordreplicationpolicy-inventory-adaccount-resultant-password-replication/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:33+00:00 - Modified: 2026-08-27T17:14:53+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADAccountResultantPasswordReplicationPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADAccountResultantPasswordReplicationPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Get-ADAccountResultantPasswordReplicationPolicy: inventory adaccount resultant password replication policy. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADAccountResultantPasswordReplicationPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adaccountresultantpasswordreplicationpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Gets the resultant password replication policy for an Active Directory account.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADAccountResultantPasswordReplicationPolicy cmdlet gets the resultant password replication policy for a user, computer, or service account on the specified read-only domain controller.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Within Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, which versions, roles, and configuration states define the review population? - Could Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-113 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Get-ADAccountResultantPasswordReplicationPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adaccountresultantpasswordreplicationpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADAccountResultantPasswordReplicationPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adaccountresultantpasswordreplicationpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADAccountResultantPasswordReplicationPolicy: inventory adaccount resultant password replication policy,” DSE Security, https://update.dsesecurity.com/updates/get-adaccountresultantpasswordreplicationpolicy-inventory-adaccount-resultant-password-replication/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADAuthenticationPolicySilo: inventory adauthentication policy silo against recorded identity and DNS state > Use Get-ADAuthenticationPolicySilo to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adauthenticationpolicysilo-inventory-adauthentication-policy-silo-against-recorded-identity-and/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:13+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADAuthenticationPolicySilo to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADAuthenticationPolicySilo ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Get-ADAuthenticationPolicySilo: inventory adauthentication policy silo against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADAuthenticationPolicySilo](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adauthenticationpolicysilo?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Gets one or more Active Directory Domain Services authentication policy silos.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADAuthenticationPolicySilo cmdlet gets an authentication policy silo or performs a search to get authentication policy silos.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-133 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Get-ADAuthenticationPolicySilo](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adauthenticationpolicysilo?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADAuthenticationPolicySilo - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adauthenticationpolicysilo?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADAuthenticationPolicySilo: inventory adauthentication policy silo against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/get-adauthenticationpolicysilo-inventory-adauthentication-policy-silo-against-recorded-identity-and/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADCentralAccessPolicy: inventory adcentral access policy with bounded evidence > Use Get-ADCentralAccessPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adcentralaccesspolicy-inventory-adcentral-access-policy-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:01+00:00 - Modified: 2026-08-27T17:14:55+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADCentralAccessPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADCentralAccessPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-ADCentralAccessPolicy: inventory adcentral access policy with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADCentralAccessPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcentralaccesspolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADCentralAccessPolicy cmdlet retrieves central access policies from Active Directory.” The research record locates this support at DESCRIPTION. - At Example 1: Get a list off all central access policies, Microsoft states: “This command retrieves a list of all central access policies.” The research record locates this support at Example 1: Get a list off all central access policies. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Get a list off all central access policies, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to DESCRIPTION; Example 1: Get a list off all central access policies and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-145 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Get-ADCentralAccessPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcentralaccesspolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADCentralAccessPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcentralaccesspolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADCentralAccessPolicy: inventory adcentral access policy with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-adcentralaccesspolicy-inventory-adcentral-access-policy-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADCentralAccessRule: inventory adcentral access rule with before-and-after evidence > Use Get-ADCentralAccessRule to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adcentralaccessrule-inventory-adcentral-access-rule-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:12+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADCentralAccessRule to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADCentralAccessRule ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Get-ADCentralAccessRule: inventory adcentral access rule with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADCentralAccessRule](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcentralaccessrule?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADCentralAccessRule cmdlet retrieves central access rules from Active Directory.” The research record locates this support at DESCRIPTION. - At Example 1: Get a list of all central access rules, Microsoft states: “This command retrieves a list of all central access rules.” The research record locates this support at Example 1: Get a list of all central access rules. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Get a list of all central access rules, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to DESCRIPTION; Example 1: Get a list of all central access rules and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-194 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Get-ADCentralAccessRule](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcentralaccessrule?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADCentralAccessRule - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcentralaccessrule?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADCentralAccessRule: inventory adcentral access rule with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/get-adcentralaccessrule-inventory-adcentral-access-rule-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADComputer: inventory adcomputer with rollback checks > Use Get-ADComputer to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adcomputer-inventory-adcomputer-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:09+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADComputer to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADComputer ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Get-ADComputer: inventory adcomputer with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADComputer](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputer?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADComputer cmdlet gets a computer or performs a search to retrieve multiple computers.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory computer to retrieve.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-137 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Get-ADComputer](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputer?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADComputer - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputer?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADComputer: inventory adcomputer with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/get-adcomputer-inventory-adcomputer-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADComputerServiceAccount: inventory adcomputer service account with bounded evidence > Use Get-ADComputerServiceAccount to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adcomputerserviceaccount-inventory-adcomputer-service-account-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:16+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADComputerServiceAccount to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADComputerServiceAccount ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-ADComputerServiceAccount: inventory adcomputer service account with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADComputerServiceAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputerserviceaccount?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADComputerServiceAccount cmdlet gets all of the service accounts that are hosted by the specified computer.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Computer parameter specifies the Active Directory computer that hosts the service accounts.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-190 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Get-ADComputerServiceAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputerserviceaccount?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADComputerServiceAccount - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adcomputerserviceaccount?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADComputerServiceAccount: inventory adcomputer service account with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-adcomputerserviceaccount-inventory-adcomputer-service-account-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADDCCloningExcludedApplicationList: inventory addccloning excluded application list against recorded identity and DNS state > Use Get-ADDCCloningExcludedApplicationList to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-addccloningexcludedapplicationlist-inventory-addccloning-excluded-application-list-against/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:03+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADDCCloningExcludedApplicationList to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADDCCloningExcludedApplicationList ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Get-ADDCCloningExcludedApplicationList: inventory addccloning excluded application list against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADDCCloningExcludedApplicationList](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addccloningexcludedapplicationlist?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Gets a list of installed programs and services present on this domain controller that are not in the default or user defined inclusion list.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADDCCloningExcludedApplicationList cmdlet searches the local domain controller for programs and services in the installed programs database, the services control manager that are not specified in the default and user defined inclusion list.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from SYNOPSIS; DESCRIPTION to the observed environment. Useful domain evidence includes sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-203 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-ADDCCloningExcludedApplicationList](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addccloningexcludedapplicationlist?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADDCCloningExcludedApplicationList - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addccloningexcludedapplicationlist?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADDCCloningExcludedApplicationList: inventory addccloning excluded application list against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/get-addccloningexcludedapplicationlist-inventory-addccloning-excluded-application-list-against/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADDefaultDomainPasswordPolicy: inventory addefault domain password policy under AD/DNS change control > Use Get-ADDefaultDomainPasswordPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-addefaultdomainpasswordpolicy-inventory-addefault-domain-password-policy-under-ad-dns-change/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:50+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADDefaultDomainPasswordPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADDefaultDomainPasswordPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-ADDefaultDomainPasswordPolicy: inventory addefault domain password policy under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADDefaultDomainPasswordPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addefaultdomainpasswordpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Gets the default password policy for an Active Directory domain.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADDefaultDomainPasswordPolicy cmdlet gets the default password policy for a domain.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-156 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Get-ADDefaultDomainPasswordPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addefaultdomainpasswordpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADDefaultDomainPasswordPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addefaultdomainpasswordpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADDefaultDomainPasswordPolicy: inventory addefault domain password policy under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-addefaultdomainpasswordpolicy-inventory-addefault-domain-password-policy-under-ad-dns-change/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADDomain: inventory addomain under AD/DNS change control > Use Get-ADDomain to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-addomain-inventory-addomain-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:20+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADDomain to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADDomain ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-ADDomain: inventory addomain under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADDomain](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomain?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADDomain cmdlet gets the Active Directory domain specified by the parameters.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can specify the domain by setting the Identity or Current parameters.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-186 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Get-ADDomain](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomain?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADDomain - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomain?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADDomain: inventory addomain under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-addomain-inventory-addomain-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADDomainController: inventory addomain controller with rollback checks > Use Get-ADDomainController to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-addomaincontroller-inventory-addomain-controller-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:04+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADDomainController to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADDomainController ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Get-ADDomainController: inventory addomain controller with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADDomainController](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomaincontroller?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Gets one or more Active Directory domain controllers based on discoverable services criteria, search parameters or by providing a domain controller identifier, such as the NetBIOS name.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADDomainController cmdlet gets the domain controllers specified by the parameters.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to SYNOPSIS; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-142 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Get-ADDomainController](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomaincontroller?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADDomainController - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomaincontroller?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADDomainController: inventory addomain controller with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/get-addomaincontroller-inventory-addomain-controller-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADDomainControllerPasswordReplicationPolicyUsage: inventory addomain controller password replication policy usage > Use Get-ADDomainControllerPasswordReplicationPolicyUsage to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-addomaincontrollerpasswordreplicationpolicyusage-inventory-addomain-controller-password/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:12+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADDomainControllerPasswordReplicationPolicyUsage to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADDomainControllerPasswordReplicationPolicyUsage ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Get-ADDomainControllerPasswordReplicationPolicyUsage: inventory addomain controller password replication policy usage. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADDomainControllerPasswordReplicationPolicyUsage](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomaincontrollerpasswordreplicationpolicyusage?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Gets the Active Directory accounts that are authenticated by a read-only domain controller or that are in the revealed list of the domain controller.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADDomainControllerPasswordReplicationPolicyUsage cmdlet gets the user or computer accounts that are authenticated by a read-only domain controller (RODC) or that have passwords that are stored on that RODC.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-134 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Get-ADDomainControllerPasswordReplicationPolicyUsage](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomaincontrollerpasswordreplicationpolicyusage?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADDomainControllerPasswordReplicationPolicyUsage - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomaincontrollerpasswordreplicationpolicyusage?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADDomainControllerPasswordReplicationPolicyUsage: inventory addomain controller password replication policy usage,” DSE Security, https://update.dsesecurity.com/updates/get-addomaincontrollerpasswordreplicationpolicyusage-inventory-addomain-controller-password/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADFineGrainedPasswordPolicy: inventory adfine grained password policy with rollback checks > Use Get-ADFineGrainedPasswordPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adfinegrainedpasswordpolicy-inventory-adfine-grained-password-policy-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:39+00:00 - Modified: 2026-08-27T17:14:53+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADFineGrainedPasswordPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADFineGrainedPasswordPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Get-ADFineGrainedPasswordPolicy: inventory adfine grained password policy with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADFineGrainedPasswordPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adfinegrainedpasswordpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADFineGrainedPasswordPolicy cmdlet gets a fine-grained password policy or performs a search to retrieve multiple fine-grained password policies.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory fine-grained password policy to get.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Within Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, which versions, roles, and configuration states define the review population? - Could Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from DESCRIPTION; DESCRIPTION to the observed environment. Useful domain evidence includes sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-107 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-ADFineGrainedPasswordPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adfinegrainedpasswordpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADFineGrainedPasswordPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adfinegrainedpasswordpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADFineGrainedPasswordPolicy: inventory adfine grained password policy with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/get-adfinegrainedpasswordpolicy-inventory-adfine-grained-password-policy-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADForest: inventory adforest with rollback checks > Use Get-ADForest to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adforest-inventory-adforest-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:19+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADForest to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADForest ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Get-ADForest: inventory adforest with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADForest](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adforest?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “You can specify the forest by setting the Identity or Current parameters.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory forest to get.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-187 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-ADForest](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adforest?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADForest - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adforest?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADForest: inventory adforest with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/get-adforest-inventory-adforest-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADGroup: inventory adgroup against recorded identity and DNS state > Use Get-ADGroup to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adgroup-inventory-adgroup-against-recorded-identity-and-dns-state/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:03+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADGroup to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADGroup ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Get-ADGroup: inventory adgroup against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADGroup](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adgroup?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADGroup cmdlet gets a group or performs a search to retrieve multiple groups from an Active Directory.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory group to get.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-143 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-ADGroup](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adgroup?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADGroup - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adgroup?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADGroup: inventory adgroup against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/get-adgroup-inventory-adgroup-against-recorded-identity-and-dns-state/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADGroupMember: inventory adgroup member with bounded evidence > Use Get-ADGroupMember to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adgroupmember-inventory-adgroup-member-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:26+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADGroupMember to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADGroupMember ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-ADGroupMember: inventory adgroup member with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADGroupMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adgroupmember?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADGroupMember cmdlet gets the members of an Active Directory group.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory group to access.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from DESCRIPTION; DESCRIPTION to the observed environment. Useful domain evidence includes sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-180 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Get-ADGroupMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adgroupmember?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADGroupMember - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adgroupmember?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADGroupMember: inventory adgroup member with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-adgroupmember-inventory-adgroup-member-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADObject: inventory adobject with bounded evidence > Use Get-ADObject to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adobject-inventory-adobject-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:16+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADObject to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADObject ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-ADObject: inventory adobject with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADObject](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adobject?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADObject cmdlet gets an Active Directory object or performs a search to get multiple objects.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory object to get.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from DESCRIPTION; DESCRIPTION to the observed environment. Useful domain evidence includes sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-130 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Get-ADObject](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adobject?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADObject - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adobject?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADObject: inventory adobject with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-adobject-inventory-adobject-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADOptionalFeature: inventory adoptional feature with before-and-after evidence > Use Get-ADOptionalFeature to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adoptionalfeature-inventory-adoptional-feature-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:37+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADOptionalFeature to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADOptionalFeature ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Get-ADOptionalFeature: inventory adoptional feature with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADOptionalFeature](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adoptionalfeature?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADOptionalFeature cmdlet gets an optional feature or performs a search to retrieve multiple optional features from an Active Directory.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory optional feature that you want to get.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-169 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Get-ADOptionalFeature](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adoptionalfeature?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADOptionalFeature - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adoptionalfeature?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADOptionalFeature: inventory adoptional feature with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/get-adoptionalfeature-inventory-adoptional-feature-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADOrganizationalUnit: inventory adorganizational unit with bounded evidence > Use Get-ADOrganizationalUnit to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adorganizationalunit-inventory-adorganizational-unit-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:51+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADOrganizationalUnit to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADOrganizationalUnit ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-ADOrganizationalUnit: inventory adorganizational unit with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADOrganizationalUnit](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adorganizationalunit?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADOrganizationalUnit cmdlet gets an organizational unit (OU) object or performs a search to get multiple OUs.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory OU to get.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from DESCRIPTION; DESCRIPTION to the observed environment. Useful domain evidence includes sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-155 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-ADOrganizationalUnit](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adorganizationalunit?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADOrganizationalUnit - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adorganizationalunit?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADOrganizationalUnit: inventory adorganizational unit with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-adorganizationalunit-inventory-adorganizational-unit-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADReplicationAttributeMetadata: inventory adreplication attribute metadata against recorded identity and DNS state > Use Get-ADReplicationAttributeMetadata to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adreplicationattributemetadata-inventory-adreplication-attribute-metadata-against-recorded/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:58+00:00 - Modified: 2026-08-27T17:14:55+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADReplicationAttributeMetadata to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADReplicationAttributeMetadata ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Get-ADReplicationAttributeMetadata: inventory adreplication attribute metadata against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADReplicationAttributeMetadata](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationattributemetadata?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Gets the replication metadata for one or more Active Directory replication partners.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADReplicationAttributeMetadata cmdlet gets the replication metadata for one or more attributes on a given object.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations SYNOPSIS; DESCRIPTION. Favor sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-148 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Get-ADReplicationAttributeMetadata](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationattributemetadata?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADReplicationAttributeMetadata - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationattributemetadata?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADReplicationAttributeMetadata: inventory adreplication attribute metadata against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/get-adreplicationattributemetadata-inventory-adreplication-attribute-metadata-against-recorded/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADReplicationConnection: inventory adreplication connection against recorded identity and DNS state > Use Get-ADReplicationConnection to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adreplicationconnection-inventory-adreplication-connection-against-recorded-identity-and-dns/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:48+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADReplicationConnection to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADReplicationConnection ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Get-ADReplicationConnection: inventory adreplication connection against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADReplicationConnection](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationconnection?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Returns a specific Active Directory replication connection or a set of AD replication connection objects based on a specified filter.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADReplicationConnection cmdlet returns a specific Active Directory replication connection or a set of Active Directory replication connection objects based on a specified filter.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-158 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Get-ADReplicationConnection](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationconnection?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADReplicationConnection - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationconnection?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADReplicationConnection: inventory adreplication connection against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/get-adreplicationconnection-inventory-adreplication-connection-against-recorded-identity-and-dns/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADReplicationPartnerMetadata: inventory adreplication partner metadata with before-and-after evidence > Use Get-ADReplicationPartnerMetadata to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adreplicationpartnermetadata-inventory-adreplication-partner-metadata-with-before-and-after/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:02+00:00 - Modified: 2026-08-27T17:14:55+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADReplicationPartnerMetadata to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADReplicationPartnerMetadata ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Get-ADReplicationPartnerMetadata: inventory adreplication partner metadata with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADReplicationPartnerMetadata](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationpartnermetadata?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Returns the replication metadata for a set of one or more replication partners.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADReplicationPartnerMetadata cmdlet returns an Active Directory replication partner metadata object for each of its replication partners which contains all of the relevant replication data for the partners involved.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to SYNOPSIS; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-144 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Get-ADReplicationPartnerMetadata](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationpartnermetadata?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADReplicationPartnerMetadata - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationpartnermetadata?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADReplicationPartnerMetadata: inventory adreplication partner metadata with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/get-adreplicationpartnermetadata-inventory-adreplication-partner-metadata-with-before-and-after/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADReplicationQueueOperation: inventory adreplication queue operation with bounded evidence > Use Get-ADReplicationQueueOperation to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adreplicationqueueoperation-inventory-adreplication-queue-operation-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:06+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADReplicationQueueOperation to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADReplicationQueueOperation ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-ADReplicationQueueOperation: inventory adreplication queue operation with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADReplicationQueueOperation](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationqueueoperation?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Returns the contents of the replication queue for a specified server.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADReplicationQueueOperation cmdlet returns all of the pending operations in the replication queue.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from SYNOPSIS; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-140 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Get-ADReplicationQueueOperation](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationqueueoperation?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADReplicationQueueOperation - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationqueueoperation?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADReplicationQueueOperation: inventory adreplication queue operation with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-adreplicationqueueoperation-inventory-adreplication-queue-operation-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADReplicationSiteLinkBridge: inventory adreplication site link bridge with rollback checks > Use Get-ADReplicationSiteLinkBridge to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adreplicationsitelinkbridge-inventory-adreplication-site-link-bridge-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:49+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADReplicationSiteLinkBridge to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADReplicationSiteLinkBridge ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Get-ADReplicationSiteLinkBridge: inventory adreplication site link bridge with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADReplicationSiteLinkBridge](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationsitelinkbridge?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Gets a specific Active Directory site link bridge or a set of site link bridge objects based on a specified filter.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADReplicationSiteLinkBridge cmdlet gets a specific Active Directory site link bridge or a set of site link bridge objects based on a specified filter.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-157 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Get-ADReplicationSiteLinkBridge](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationsitelinkbridge?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADReplicationSiteLinkBridge - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationsitelinkbridge?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADReplicationSiteLinkBridge: inventory adreplication site link bridge with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/get-adreplicationsitelinkbridge-inventory-adreplication-site-link-bridge-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADReplicationSubnet: inventory adreplication subnet with rollback checks > Use Get-ADReplicationSubnet to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adreplicationsubnet-inventory-adreplication-subnet-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:59+00:00 - Modified: 2026-08-27T17:14:55+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADReplicationSubnet to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADReplicationSubnet ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Get-ADReplicationSubnet: inventory adreplication subnet with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADReplicationSubnet](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationsubnet?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADReplicationSubnet cmdlet gets a specific Active Directory subnet or a set of subnets based on a specified filter.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “Subnet objects (class subnet) define network subnets in Active Directory.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; DESCRIPTION. Favor sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-147 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-ADReplicationSubnet](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationsubnet?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADReplicationSubnet - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationsubnet?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADReplicationSubnet: inventory adreplication subnet with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/get-adreplicationsubnet-inventory-adreplication-subnet-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADReplicationUpToDatenessVectorTable: inventory adreplication up to dateness vector table under AD/DNS change control > Use Get-ADReplicationUpToDatenessVectorTable to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adreplicationuptodatenessvectortable-inventory-adreplication-up-to-dateness-vector-table-under/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:10+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADReplicationUpToDatenessVectorTable to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADReplicationUpToDatenessVectorTable ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-ADReplicationUpToDatenessVectorTable: inventory adreplication up to dateness vector table under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADReplicationUpToDatenessVectorTable](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationuptodatenessvectortable?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Displays the highest Update Sequence Number (USN) for the specified domain controller.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-ADReplicationUpToDatenessVectorTable cmdlet displays the highest Update Sequence Number (USN) for the specified domain controller(s).” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from SYNOPSIS; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-136 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Get-ADReplicationUpToDatenessVectorTable](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationuptodatenessvectortable?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADReplicationUpToDatenessVectorTable - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationuptodatenessvectortable?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADReplicationUpToDatenessVectorTable: inventory adreplication up to dateness vector table under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-adreplicationuptodatenessvectortable-inventory-adreplication-up-to-dateness-vector-table-under/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADResourcePropertyList: inventory adresource property list against recorded identity and DNS state > Use Get-ADResourcePropertyList to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adresourcepropertylist-inventory-adresource-property-list-against-recorded-identity-and-dns/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:13+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADResourcePropertyList to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADResourcePropertyList ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Get-ADResourcePropertyList: inventory adresource property list against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADResourcePropertyList](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adresourcepropertylist?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADResourcePropertyList cmdlet gets resource property lists from Active Directory.” The research record locates this support at DESCRIPTION. - At Example 1: Get all resource property lists, Microsoft states: “This command gets a list of all resource property lists.” The research record locates this support at Example 1: Get all resource property lists. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Get all resource property lists, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to DESCRIPTION; Example 1: Get all resource property lists and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-193 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Get-ADResourcePropertyList](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adresourcepropertylist?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADResourcePropertyList - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adresourcepropertylist?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADResourcePropertyList: inventory adresource property list against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/get-adresourcepropertylist-inventory-adresource-property-list-against-recorded-identity-and-dns/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADResourcePropertyValueType: inventory adresource property value type under AD/DNS change control > Use Get-ADResourcePropertyValueType to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adresourcepropertyvaluetype-inventory-adresource-property-value-type-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:10+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADResourcePropertyValueType to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADResourcePropertyValueType ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-ADResourcePropertyValueType: inventory adresource property value type under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADResourcePropertyValueType](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adresourcepropertyvaluetype?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADResourcePropertyValueType cmdlet retrieves a resource property value type from Active Directory.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The resource property value type supports the following Active Directory primitives (ValueType, IsSingleValued, RestrictValues) and a Boolean indicating whether SuggestedValues are allowed.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; DESCRIPTION. Favor sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-196 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Get-ADResourcePropertyValueType](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adresourcepropertyvaluetype?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADResourcePropertyValueType - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adresourcepropertyvaluetype?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADResourcePropertyValueType: inventory adresource property value type under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-adresourcepropertyvaluetype-inventory-adresource-property-value-type-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADTrust: inventory adtrust under AD/DNS change control > Use Get-ADTrust to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-adtrust-inventory-adtrust-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:00+00:00 - Modified: 2026-08-27T17:14:55+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADTrust to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADTrust ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-ADTrust: inventory adtrust under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADTrust](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adtrust?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADTrust cmdlet returns all of the trusted domain objects in the directory.” The research record locates this support at DESCRIPTION. - At Example 1: Get all trusted domain objects in a forest, Microsoft states: “This command gets all of the trusted domain objects in the forest.” The research record locates this support at Example 1: Get all trusted domain objects in a forest. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Get all trusted domain objects in a forest, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; Example 1: Get all trusted domain objects in a forest. Favor sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-146 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Get-ADTrust](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adtrust?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADTrust - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adtrust?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADTrust: inventory adtrust under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-adtrust-inventory-adtrust-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADUser: inventory aduser with before-and-after evidence > Use Get-ADUser to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-aduser-inventory-aduser-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:07+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADUser to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADUser ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Get-ADUser: inventory aduser with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADUser](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduser?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADUser cmdlet gets a specified user object or performs a search to get multiple user objects.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory user to get.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-139 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-ADUser](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduser?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADUser - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduser?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADUser: inventory aduser with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/get-aduser-inventory-aduser-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-ADUserResultantPasswordPolicy: inventory aduser resultant password policy with bounded evidence > Use Get-ADUserResultantPasswordPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-aduserresultantpasswordpolicy-inventory-aduser-resultant-password-policy-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:26+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-ADUserResultantPasswordPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-ADUserResultantPasswordPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-ADUserResultantPasswordPolicy: inventory aduser resultant password policy with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-ADUserResultantPasswordPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduserresultantpasswordpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-ADUserResultantPasswordPolicy cmdlet gets the resultant password policy object (RSoP) for a user.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The RSoP is defined by the Active Directory attribute named msDS-ResultantPSO.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Within Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, which versions, roles, and configuration states define the review population? - Could Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-120 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-ADUserResultantPasswordPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduserresultantpasswordpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-ADUserResultantPasswordPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-aduserresultantpasswordpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-ADUserResultantPasswordPolicy: inventory aduser resultant password policy with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-aduserresultantpasswordpolicy-inventory-aduser-resultant-password-policy-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServer: inventory dns server with bounded evidence > Use Get-DnsServer to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserver-inventory-dns-server-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:51+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServer to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServer ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-DnsServer: inventory dns server with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServer](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserver?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServer cmdlet retrieves a Domain Name System (DNS) server configuration.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can pass the output of the Get-DnsServer cmdlet to the Export-Clixml cmdlet by using the pipeline operator.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from DESCRIPTION; DESCRIPTION to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-275 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Get-DnsServer](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserver?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServer - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserver?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServer: inventory dns server with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserver-inventory-dns-server-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerClientSubnet: inventory dns server client subnet under AD/DNS change control > Use Get-DnsServerClientSubnet to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverclientsubnet-inventory-dns-server-client-subnet-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:45+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerClientSubnet to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerClientSubnet ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-DnsServerClientSubnet: inventory dns server client subnet under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerClientSubnet](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverclientsubnet?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerClientSubnet cmdlet gets client subnets for a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “Specify a client subnet by name to see only that client subnet.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-281 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Get-DnsServerClientSubnet](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverclientsubnet?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerClientSubnet - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverclientsubnet?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerClientSubnet: inventory dns server client subnet under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverclientsubnet-inventory-dns-server-client-subnet-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerDiagnostics: inventory dns server diagnostics with bounded evidence > Use Get-DnsServerDiagnostics to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverdiagnostics-inventory-dns-server-diagnostics-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:36+00:00 - Modified: 2026-08-27T17:26:02+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerDiagnostics to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerDiagnostics ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-DnsServerDiagnostics: inventory dns server diagnostics with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerDiagnostics](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverdiagnostics?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerDiagnostics cmdlet retrieves Domain Name System (DNS) server diagnostic and logging parameters.” The research record locates this support at DESCRIPTION. - At Example 1: Get DNS event logging details, Microsoft states: “This command gets DNS event logging details for the local DNS server.” The research record locates this support at Example 1: Get DNS event logging details. Keep the evidence boundary at these traced claims. They support a review of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Get DNS event logging details, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to DESCRIPTION; Example 1: Get DNS event logging details and to observable material such as PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-290 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Get-DnsServerDiagnostics](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverdiagnostics?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerDiagnostics - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverdiagnostics?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerDiagnostics: inventory dns server diagnostics with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverdiagnostics-inventory-dns-server-diagnostics-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerEncryptionProtocol: inventory dns server encryption protocol under AD/DNS change control > Use Get-DnsServerEncryptionProtocol to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverencryptionprotocol-inventory-dns-server-encryption-protocol-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:20+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerEncryptionProtocol to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerEncryptionProtocol ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-DnsServerEncryptionProtocol: inventory dns server encryption protocol under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerEncryptionProtocol](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverencryptionprotocol?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Retrieves DNS server encryption protocol settings for DNS over HTTPS (DoH) on Windows Server 2025 or later.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Get-DnsServerEncryptionProtocol cmdlet can be used to verify the current DoH configuration on a DNS server.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations SYNOPSIS; DESCRIPTION. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-246 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Get-DnsServerEncryptionProtocol](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverencryptionprotocol?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerEncryptionProtocol - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverencryptionprotocol?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerEncryptionProtocol: inventory dns server encryption protocol under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverencryptionprotocol-inventory-dns-server-encryption-protocol-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerGlobalNameZone: inventory dns server global name zone against recorded identity and DNS state > Use Get-DnsServerGlobalNameZone to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverglobalnamezone-inventory-dns-server-global-name-zone-against-recorded-identity-and-dns/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:38+00:00 - Modified: 2026-08-27T17:26:02+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerGlobalNameZone to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerGlobalNameZone ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Get-DnsServerGlobalNameZone: inventory dns server global name zone against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerGlobalNameZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverglobalnamezone?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerGlobalNameZone cmdlet gets a Domain Name System (DNS) server GlobalNames zone object for the local server or a specified DNS server.” The research record locates this support at DESCRIPTION. - At -AsJob, Microsoft states: “Use this parameter to run commands that take a long time to complete.” The research record locates this support at -AsJob. Keep the evidence boundary at these traced claims. They support a review of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at -AsJob, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to DESCRIPTION; -AsJob and to observable material such as PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-288 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Get-DnsServerGlobalNameZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverglobalnamezone?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerGlobalNameZone - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverglobalnamezone?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerGlobalNameZone: inventory dns server global name zone against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverglobalnamezone-inventory-dns-server-global-name-zone-against-recorded-identity-and-dns/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerGlobalQueryBlockList: inventory dns server global query block list under AD/DNS change control > Use Get-DnsServerGlobalQueryBlockList to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverglobalqueryblocklist-inventory-dns-server-global-query-block-list-under-ad-dns-change/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:40+00:00 - Modified: 2026-08-27T17:26:02+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerGlobalQueryBlockList to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerGlobalQueryBlockList ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-DnsServerGlobalQueryBlockList: inventory dns server global query block list under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerGlobalQueryBlockList](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverglobalqueryblocklist?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerGlobalQueryBlockList cmdlet gets a global query block list on a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “DNS Server service maintains a list of servers that it does not respond to when the DNS server receives a query to resolve the name in any zone for which the server is authoritative.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-286 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Get-DnsServerGlobalQueryBlockList](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverglobalqueryblocklist?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerGlobalQueryBlockList - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverglobalqueryblocklist?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerGlobalQueryBlockList: inventory dns server global query block list under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverglobalqueryblocklist-inventory-dns-server-global-query-block-list-under-ad-dns-change/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerRecursionScope: inventory dns server recursion scope with rollback checks > Use Get-DnsServerRecursionScope to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverrecursionscope-inventory-dns-server-recursion-scope-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:44+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerRecursionScope to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerRecursionScope ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Get-DnsServerRecursionScope: inventory dns server recursion scope with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerRecursionScope](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverrecursionscope?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerRecursionScope cmdlet gets the Domain Name System (DNS) server recursion scopes.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “Specify a scope by name to get only that scope.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-282 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Get-DnsServerRecursionScope](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverrecursionscope?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerRecursionScope - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverrecursionscope?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerRecursionScope: inventory dns server recursion scope with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverrecursionscope-inventory-dns-server-recursion-scope-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerResourceRecord: inventory dns server resource record with before-and-after evidence > Use Get-DnsServerResourceRecord to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverresourcerecord-inventory-dns-server-resource-record-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:42+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerResourceRecord to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerResourceRecord ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Get-DnsServerResourceRecord: inventory dns server resource record with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerResourceRecord](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresourcerecord?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerResourceRecord cmdlet gets the following information for a specified resource record from a Domain Name System (DNS) zone:” The research record locates this support at DESCRIPTION. - At Example 1: Get all resource records in a specified zone, Microsoft states: “This command gets all DNS server resource records in a zone named contoso.com.” The research record locates this support at Example 1: Get all resource records in a specified zone. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Get all resource records in a specified zone, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; Example 1: Get all resource records in a specified zone. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-224 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-DnsServerResourceRecord](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresourcerecord?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerResourceRecord - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresourcerecord?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerResourceRecord: inventory dns server resource record with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverresourcerecord-inventory-dns-server-resource-record-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerResponseRateLimiting: inventory dns server response rate limiting against recorded identity and DNS state > Use Get-DnsServerResponseRateLimiting to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverresponseratelimiting-inventory-dns-server-response-rate-limiting-against-recorded/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:53+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerResponseRateLimiting to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerResponseRateLimiting ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Get-DnsServerResponseRateLimiting: inventory dns server response rate limiting against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerResponseRateLimiting](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresponseratelimiting?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerResponseRateLimiting cmdlet displays response rate limiting (RRL) settings on a DNS server.” The research record locates this support at DESCRIPTION. - At Example 1: Display RRL settings on a DNS server, Microsoft states: “This command displays the RRL settings on the DNS server.” The research record locates this support at Example 1: Display RRL settings on a DNS server. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Display RRL settings on a DNS server, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from DESCRIPTION; Example 1: Display RRL settings on a DNS server to the observed environment. Useful domain evidence includes PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-273 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Get-DnsServerResponseRateLimiting](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresponseratelimiting?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerResponseRateLimiting - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverresponseratelimiting?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerResponseRateLimiting: inventory dns server response rate limiting against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverresponseratelimiting-inventory-dns-server-response-rate-limiting-against-recorded/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerScavenging: inventory dns server scavenging under AD/DNS change control > Use Get-DnsServerScavenging to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverscavenging-inventory-dns-server-scavenging-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:35+00:00 - Modified: 2026-08-27T17:26:02+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerScavenging to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerScavenging ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-DnsServerScavenging: inventory dns server scavenging under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerScavenging](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverscavenging?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerScavenging cmdlet gets aging and scavenging settings on a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At Example 1: Get scavenging settings, Microsoft states: “This command gets the scavenging settings for the local DNS server.” The research record locates this support at Example 1: Get scavenging settings. The source support ends with the statements listed above. Use them to examine Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Get scavenging settings, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; Example 1: Get scavenging settings. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-291 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-DnsServerScavenging](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverscavenging?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerScavenging - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverscavenging?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerScavenging: inventory dns server scavenging under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverscavenging-inventory-dns-server-scavenging-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerStatistics: inventory dns server statistics under AD/DNS change control > Use Get-DnsServerStatistics to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverstatistics-inventory-dns-server-statistics-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:55+00:00 - Modified: 2026-08-27T17:22:19+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerStatistics to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerStatistics ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-DnsServerStatistics: inventory dns server statistics under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerStatistics](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverstatistics?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerStatistics cmdlet retrieves statistics of a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “If the ZoneName parameter is specified, this cmdlet gets statistics for the zones specified by that parameter.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-211 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-DnsServerStatistics](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverstatistics?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerStatistics - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverstatistics?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerStatistics: inventory dns server statistics under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverstatistics-inventory-dns-server-statistics-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerTrustAnchor: inventory dns server trust anchor with bounded evidence > Use Get-DnsServerTrustAnchor to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsservertrustanchor-inventory-dns-server-trust-anchor-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:41+00:00 - Modified: 2026-08-27T17:26:02+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerTrustAnchor to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerTrustAnchor ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Get-DnsServerTrustAnchor: inventory dns server trust anchor with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerTrustAnchor](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservertrustanchor?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerTrustAnchor cmdlet gets trust anchors on a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “If you do not specify the name of a trust anchor to get, the cmdlet returns all trust anchors.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-285 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Get-DnsServerTrustAnchor](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservertrustanchor?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerTrustAnchor - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservertrustanchor?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerTrustAnchor: inventory dns server trust anchor with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/get-dnsservertrustanchor-inventory-dns-server-trust-anchor-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerTrustPoint: inventory dns server trust point with rollback checks > Use Get-DnsServerTrustPoint to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsservertrustpoint-inventory-dns-server-trust-point-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:39+00:00 - Modified: 2026-08-27T17:26:02+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerTrustPoint to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerTrustPoint ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Get-DnsServerTrustPoint: inventory dns server trust point with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerTrustPoint](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservertrustpoint?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerTrustPoint cmdlet gets one or more trust points on a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “If you do not specify a trust point name, all trust points are enumerated.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-287 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-DnsServerTrustPoint](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservertrustpoint?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerTrustPoint - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservertrustpoint?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerTrustPoint: inventory dns server trust point with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/get-dnsservertrustpoint-inventory-dns-server-trust-point-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerVirtualizationInstance: inventory dns server virtualization instance against recorded identity and DNS state > Use Get-DnsServerVirtualizationInstance to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsservervirtualizationinstance-inventory-dns-server-virtualization-instance-against-recorded/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:43+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerVirtualizationInstance to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerVirtualizationInstance ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Get-DnsServerVirtualizationInstance: inventory dns server virtualization instance against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerVirtualizationInstance](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservervirtualizationinstance?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerVirtualizationInstance cmdlet gets the virtualization instances on the Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “If the Name parameter is provided then the cmdlet returns that virtualization instance.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-283 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Get-DnsServerVirtualizationInstance](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservervirtualizationinstance?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerVirtualizationInstance - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsservervirtualizationinstance?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerVirtualizationInstance: inventory dns server virtualization instance against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/get-dnsservervirtualizationinstance-inventory-dns-server-virtualization-instance-against-recorded/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerZone: inventory dns server zone with before-and-after evidence > Use Get-DnsServerZone to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverzone-inventory-dns-server-zone-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:02+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerZone to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerZone ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Get-DnsServerZone: inventory dns server zone with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzone?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerZone cmdlet gets the zones that exist on a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At Example 1: Get GlobalName zone settings, Microsoft states: “This command gets details of all zones on the local DNS server.” The research record locates this support at Example 1: Get GlobalName zone settings. Keep the evidence boundary at these traced claims. They support a review of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Get GlobalName zone settings, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to DESCRIPTION; Example 1: Get GlobalName zone settings and to observable material such as PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-264 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Get-DnsServerZone](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzone?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerZone - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzone?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerZone: inventory dns server zone with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverzone-inventory-dns-server-zone-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Get-DnsServerZoneDelegation: inventory dns server zone delegation under AD/DNS change control > Use Get-DnsServerZoneDelegation to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/get-dnsserverzonedelegation-inventory-dns-server-zone-delegation-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:15+00:00 - Modified: 2026-08-27T17:26:00+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Get-DnsServerZoneDelegation to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Get-DnsServerZoneDelegation ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Get-DnsServerZoneDelegation: inventory dns server zone delegation under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Get-DnsServerZoneDelegation](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzonedelegation?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Get-DnsServerZoneDelegation cmdlet gets the zone delegation objects for a Domain Name System (DNS) server zone.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can specify a child zone name or get all child zones of a zone.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations DESCRIPTION; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-251 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Get-DnsServerZoneDelegation](https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzonedelegation?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Get-DnsServerZoneDelegation - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/get-dnsserverzonedelegation?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Get-DnsServerZoneDelegation: inventory dns server zone delegation under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/get-dnsserverzonedelegation-inventory-dns-server-zone-delegation-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give each SDN appliance adapter an explicit management or traffic role > Which interface bindings should be reviewed when deploying a multi-adapter network virtual appliance? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-141-give-each-sdn-appliance-adapter-an-explicit-management-or-traffic-role/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:50+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which interface bindings should be reviewed when deploying a multi-adapter network virtual appliance? ## Potentially affected Administrators attaching network virtual appliances to SDN tenant networks. ## DSE recommendation Prepare an interface table showing every adapter, controller object, host binding, subnet, and intended role. ## Article ## Source facts Microsoft describes network appliances used for user-defined routing and port mirroring in tenant virtual networks. User-defined routing can place an appliance in the routing path between virtual subnets. For appliances with multiple adapters, Microsoft requires each interface to be created in Network Controller and the corresponding interface IDs assigned on the hosts. The source distinguishes a management adapter from adapters processing traffic. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Use-Network-Virtual-Appliances-on-a-VN). ## Applicability Identify the appliance’s documented adapter requirements, management network, data subnets, and forwarding purpose. Review the supported appliance deployment and the actual SDN resource identities before adapting the example. ## DSE recommendation Prepare an interface table showing every adapter, controller object, host binding, subnet, and intended role. Have the appliance and SDN owners review the table together. Explicitly identify the management path that should remain available during a forwarding or inspection test. ## Verification Verify each binding and test management separately from the intended data path. Exercise allowed and excluded routes or mirrored traffic according to the approved design. Record the actual path observed and investigate an unbound adapter or unexpected bypass before accepting the appliance deployment. ## Official references [Microsoft Learn: Use network virtual appliances on a virtual network](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Use-Network-Virtual-Appliances-on-a-VN). Source reviewed September 8, 2026. ## Primary reference - Name: Use network virtual appliances on a virtual network - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Use-Network-Virtual-Appliances-on-a-VN - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Give each SDN appliance adapter an explicit management or traffic role,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-141-give-each-sdn-appliance-adapter-an-explicit-management-or-traffic-role/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give every Azure Policy exemption an owner, scope, expiry, and review > Azure Policy exemptions preserve compliance visibility while recording a Mitigated or Waiver decision, but expiration is optional and the object remains after expiry. Treat each exemption as a governed, time-bound risk record. - Canonical URL: https://update.dsesecurity.com/updates/azure-policy-exemption-lifecycle/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:00:00+00:00 - Modified: 2026-08-11T14:48:24+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Azure Policy exemptions preserve compliance visibility while recording a Mitigated or Waiver decision, but expiration is optional and the object remains after expiry. Treat each exemption as a governed, time-bound risk record. ## Potentially affected Azure management groups, subscriptions, resource groups, and resources; Azure Policy assignments and initiatives; cloud platform, security, compliance, application, and resource-owner teams; Azure RBAC and Resource Graph reporting. ## DSE recommendation Inventory live exemptions, validate assignment and definition scope, require owner and approval metadata plus expiresOn, narrow each exception to the minimum resource and policy set, and monitor active, expired, and changing records. ## Article ## Source facts: an exemption is a resource with scope and retained state Microsoft’s [Azure Policy exemption documentation](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure) describes an exemption as a child object on the resource hierarchy or individual resource being exempted. It links to a specific policy or initiative assignment through policyAssignmentId. When an initiative is involved, policyDefinitionReferenceId can limit the exemption to selected definitions instead of bypassing the entire initiative. Two categories express different decisions. Mitigated means the policy’s intent is satisfied another way. Waiver means noncompliance is temporarily accepted, or a resource is excluded from selected definitions without excluding it from the entire initiative. The free-form metadata property can hold organization-specific fields such as requester, approver, approval date, and ticket reference. The optional expiresOn timestamp controls when the exemption stops being honored. Microsoft notes that expiry does not delete the object; it remains for recordkeeping. Applicable resources report an Exempt compliance state, and the compliance substate can show what the state would be without the exemption. Resource selectors can narrow certain exemptions by attributes such as location or resource type. Creation requires Azure RBAC permission to write exemption objects and the additional exempt/Action permission on the target assignment. That boundary is important because an exemption changes how governance evaluates resources even though it does not edit the underlying policy definition. ## DSE recommendation: make the object implement the risk decision Define a minimum record before granting any exemption: business service, resource owner, exact Azure resource scope, assignment, initiative definition references, category, technical reason, risk, compensating control, requester, approver, ticket, start, expiry, remediation plan, and validation evidence. Put durable identifiers in metadata so the Azure object and governance register can be reconciled automatically. - Choose the correct mechanism. Use an exemption when a tracked resource should remain visible but has a specific mitigation or waiver. Reconsider policy scope, effect, parameters, or an assignment exclusion when the requirement actually applies to a whole designed class rather than an exception. - Minimize scope. Attach the exemption at the lowest appropriate resource hierarchy or individual resource. For initiatives, identify only the necessary definition references. Avoid exempting a subscription from an entire initiative to solve one resource’s problem. - Make time explicit. Require expiresOn for waivers and normally for temporary mitigations. Set the review early enough to test remediation before expiry. If a permanent alternative control is proposed, require evidence and a periodic recertification date in metadata. - Separate duties. Limit who can request, approve, and create exemptions. Review assignments that grant both exemption write and exempt/Action, alert on changes, and use an emergency process that demands prompt retrospective approval. - Verify the result. Confirm the intended resource reports Exempt, inspect compliance substate, and ensure neighboring resources and unrelated initiative definitions remain evaluated. Record a query or portal view that another operator can reproduce. - Close the lifecycle. Before expiry, remediate, renew through a new approval, or accept a documented service impact. After expiry, verify enforcement and application health. Retain the object as evidence where appropriate, but distinguish expired history from active authorization. Use Azure Resource Graph or equivalent reporting to track active and expired exemptions, days to expiry, missing metadata, broad scopes, category, assignment, owner, and compliance substate. Reconcile deleted resources and moved subscriptions because hierarchy changes can affect object existence or applicability. An exemption is healthy only when a decision maker can tell what was bypassed, why, for whom, until when, and what will happen next. Hold a recurring review with policy, security, and service owners. Sample the mitigation evidence rather than accepting metadata at face value, compare waiver age with the promised remediation plan, and challenge repeated renewals. A renewal should be a new risk decision supported by current facts, not an automatic extension because the object already exists. ## Official references - Microsoft Learn, [Azure Policy exemption structure](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure), August 4, 2026. ## Primary reference - Name: Microsoft Learn: Azure Policy exemption structure - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/governance/policy/concepts/exemption-structure - Source publication date: 2026-08-04 ## Citation and use Preferred citation: “Give every Azure Policy exemption an owner, scope, expiry, and review,” DSE Security, https://update.dsesecurity.com/updates/azure-policy-exemption-lifecycle/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give every connected device a network permission envelope > Manufacturer Usage Description turns intended IoT communications into machine-readable access policy. Used carefully, MUD can shrink exposure and blast radius while keeping device exceptions visible and governed. - Canonical URL: https://update.dsesecurity.com/updates/give-every-connected-device-a-network-permission-envelope/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Networks & Infrastructure, Video Surveillance - Reading time: 4 minutes ## What you need to know Manufacturer Usage Description turns intended IoT communications into machine-readable access policy. Used carefully, MUD can shrink exposure and blast radius while keeping device exceptions visible and governed. ## Potentially affected Organizations operating purpose-built IP cameras, readers, controllers, intercoms, sensors, building systems, appliances, and other IoT products with predictable communication needs. ## DSE recommendation Ask vendors for RFC 8520 support or authoritative flow requirements, build policies in monitor mode, test every lifecycle workflow, investigate denies, and govern versioned exceptions and retirement. ## Article ## Source fact: MUD describes intended communication [IETF RFC 8520](https://www.rfc-editor.org/rfc/rfc8520.html) defines Manufacturer Usage Description (MUD) for purpose-built networked things. Its architecture has three core pieces: a URL that locates a description, the YANG-based JSON description of required access, and a mechanism for the local network to retrieve and interpret it. The initial focus is access control. The RFC says MUD primarily addresses threats to the device and may also limit how a compromised device threatens others, depending on how identity and the MUD URL are handled. [NIST SP 1800-15](https://www.nccoe.nist.gov/publication/1800-15/) demonstrates four example builds that use MUD to permit IoT devices to send and receive only the traffic required for intended operation. NIST combines that control with threat-intelligence blocking and automated secure updates. The guide explicitly presents possible solutions, not a single mandatory product architecture. ## What the policy envelope can express A MUD file can describe traffic to or from internet services identified by domain name, local networks, controllers defined by the administrator, the same model, or the same manufacturer authority, together with protocol and direction constraints. That is more maintainable than pretending every cloud service has one permanent IP address. It is also narrower than giving a device unrestricted outbound internet access because a vendor could not provide a firewall list. MUD is not application inspection, vulnerability management, device authentication, or proof that every named destination is benign. A permissive description can be valid MUD syntax and still grant more access than an organization wants. DNS compromise, stolen device identity, an overly broad controller class, or an authorized cloud service compromise remain separate risks. ## DSE recommendation: begin with an authoritative flow model Ask the manufacturer whether the exact model and firmware emit or otherwise provide an RFC 8520 MUD URL and signed MUD file. Request the support period, version-change process, signing and retrieval behavior, failure mode, and human-readable documentation. If native MUD is absent, ask for authoritative communication requirements. A locally engineered allowlist can apply the same least-communication principle, but do not advertise it as manufacturer-authored MUD. Map every supported workflow before enforcement: - device discovery, initial provisioning, certificate enrollment, DNS, DHCP, and time; - video, audio, access events, alarms, metadata, and controller communications; - VMS, access server, cloud relay, mobile application, remote support, syslog, monitoring, and backups; - software and signature updates, license checks, certificate revocation, failover, recovery, factory reset, and retirement; - local service tools and temporary commissioning access that should not remain in production. ## Stage the policy like a production change Bind policy to a trustworthy device identity or controlled network attachment, not merely an address that can be reused. Validate the MUD file’s retrieval and signature process according to the selected implementation. Translate the description into the actual enforcement points and inspect the generated rules for unsupported constructs, excessive local scope, name-resolution behavior, rule order, IPv4 and IPv6 consistency, and controller definitions. Start with monitoring or a representative pilot. Exercise normal daytime and after-hours use, update and certificate renewal, server failover, internet outage, recorder recovery, mobile access, service dispatch, and device reboot. Investigate each denied flow against packet evidence, product documentation, and an accountable owner. Do not convert every deny into a permanent allow rule. ## Govern exceptions and drift Every exception should name the device class, exact purpose, source and destination, protocol, owner, approval, evidence, review date, and retirement condition. Keep the vendor MUD version, locally enforced version, generated network policy, and test result linked. Alert on failed MUD retrieval, signature failure, unexpected URL change, devices without a matching policy, repeated blocked destinations, and rules that cannot be installed. When firmware, cloud endpoints, integrations, ownership, or product support changes, repeat the flow test. On retirement, remove the device binding, certificates, controller membership, generated policy, DNS entries, and temporary exceptions. MUD makes intended communication machine-readable; lifecycle governance keeps that intent trustworthy. DSE recommends treating MUD as a specialized extension of segmentation and the firewall-rule lifecycle, not a replacement for them. It is especially valuable where thousands of similar purpose-built devices need a reviewable, repeatable permission envelope. ## Official sources - [IETF RFC 8520, Manufacturer Usage Description Specification](https://www.rfc-editor.org/rfc/rfc8520.html) - [NIST SP 1800-15, complete practice guide](https://doi.org/10.6028/NIST.SP.1800-15) - [NIST SP 1800-15C, How-To Guides](https://www.nccoe.nist.gov/publication/1800-15/VolC/index.html) - [IETF RFC 9238, Loading MUD URLs from QR Codes](https://www.rfc-editor.org/rfc/rfc9238.html) ## Primary reference - Name: NIST SP 1800-15 — Mitigating Network-Based Attacks Using MUD - Authority: Digital Object Identifier - URL: https://doi.org/10.6028/NIST.SP.1800-15 - Source publication date: 2021-05-01 ## Citation and use Preferred citation: “Give every connected device a network permission envelope,” DSE Security, https://update.dsesecurity.com/updates/give-every-connected-device-a-network-permission-envelope/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give every cryptographic key an owner, purpose, lifetime, and recovery rule > Cryptography depends on keying material that must be created, protected, used, rotated, recovered, archived, revoked, and destroyed according to its purpose and risk. - Canonical URL: https://update.dsesecurity.com/updates/cryptographic-key-lifecycle-ownership/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:33:59+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Cryptography depends on keying material that must be created, protected, used, rotated, recovered, archived, revoked, and destroyed according to its purpose and risk. ## Potentially affected Organizations using cryptographic keys for encryption, authentication, signing, key agreement, trust anchors, certificates, devices, software, backups, and cloud services. ## DSE recommendation Create a key-management register and policy that distinguish key types and purposes, constrain custody and use, define rotation and compromise response, and test recovery without creating uncontrolled copies. ## Article Bottom line: encryption and signatures are only as operable as the key lifecycle behind them. A key needs a defined purpose, authorized users and systems, protection level, active period, rotation trigger, recovery decision, compromise response, retention rule, and destruction evidence. ## Source fact: what NIST provides [NIST SP 800-57 Part 1 Revision 5](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) provides general guidance and practices for cryptographic keying material. NIST discusses security services and key types, the protection required for different keys and related information, key-management functions, and issues that organizations should address when using cryptography. Parts 2 and 3 of the series address policy and planning for U.S. Government agencies and guidance for cryptographic features in current systems. The source supports distinguishing key purposes and lifecycles rather than managing all “secrets” as an interchangeable set. ## What the source does not establish The publication does not certify a vault, hardware module, cloud key service, certificate system, or algorithm implementation. Storing a key in a designated product does not prove correct authorization, isolation, backup, audit, or deletion. Recovery can protect availability while also creating additional copies and custodial risk. The appropriate practice depends on key type, algorithm, security service, data lifetime, system architecture, legal and contractual requirements, module validation needs, and the consequences of loss or compromise. ## Applicability questions - What security service and system use does each key support? - Is the material secret, private, public, symmetric, a trust anchor, or another type with different protection needs? - Which identities and processes can create, export, activate, use, rotate, disable, recover, or destroy it? - What data or service becomes unavailable if the key is lost, and what becomes exposed if it is copied? - How will compromise, algorithm transition, ownership change, and system retirement affect the key and protected data? ## DSE recommendation: operate a key lifecycle The following steps are DSE recommendations based on the cited source. - Maintain a register with key identifier, type, purpose, algorithm and parameters, owner, systems, custody location, creation source, state, dates, dependencies, and recovery rule. Do not record secret key values in the register. - Authorize use by purpose and system, not merely by access to a vault. Separate key administration, routine use, recovery, and audit where risk warrants it. - Define generation, activation, rotation, overlap, revocation, archival, and destruction procedures. Include dependent services, cached material, replicas, and recovery environments. - Protect and test recovery only where required. Use controlled ceremonies or multi-person actions when justified, and verify that recovered material functions without leaving untracked copies. - Monitor unusual administrative and use events. Treat suspected compromise as an incident affecting both the key and everything that relied on it. - Review cryptographic transition guidance and vendor support before changing algorithms or formats. ## Verification and evidence Sample keys of different purposes and trace approval, generation, storage, use policy, rotation, logs, recovery decision, and retirement. Test one non-production rotation and one recovery path, recording dependent-system validation and confirming that temporary copies were controlled or removed. ## Official references - [NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management: General](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) — National Institute of Standards and Technology; finalized May 4, 2020 ## Primary reference - Name: NIST SP 800-57 Part 1 Rev. 5 — Recommendation for Key Management: General - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final - Source publication date: 2020-05-04 ## Citation and use Preferred citation: “Give every cryptographic key an owner, purpose, lifetime, and recovery rule,” DSE Security, https://update.dsesecurity.com/updates/cryptographic-key-lifecycle-ownership/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give every Exchange Online connector a route owner, test, and retirement date > Most Exchange Online tenants do not need connectors for ordinary internet mail. Where hybrid servers, applications, devices, or partners do require them, document the exact route, validate both directions, monitor delivery, and remove obsolete paths. - Canonical URL: https://update.dsesecurity.com/updates/exchange-online-connector-governance-mail-flow/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:11:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Most Exchange Online tenants do not need connectors for ordinary internet mail. Where hybrid servers, applications, devices, or partners do require them, document the exact route, validate both directions, monitor delivery, and remove obsolete paths. ## Potentially affected Exchange Online mail-flow connectors; hybrid and on-premises mail servers; SMTP applications, printers, scanners, fax systems, partners, accepted domains, certificates, public IP addresses, DNS, message trace, and operational monitoring. ## DSE recommendation Export every connector, assign a business and technical owner, document the sender-to-recipient route and dependencies, validate with representative messages, monitor expected traffic and failures, and review or retire the connector on a scheduled date. ## Article ## Source facts: connectors are for specific mail-flow scenarios Microsoft’s [Exchange Online connector guidance](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/use-connectors-to-configure-mail-flow) defines connectors as instructions that customize how email moves into or out of a Microsoft 365 organization. Microsoft says most tenants do not need connectors for ordinary internet mail because Exchange Online can send and receive that mail without them. Documented connector scenarios include mail between Exchange Online and an on-premises mail organization, SMTP relay for devices or applications, and defined routes to or from a partner or service. A hybrid deployment commonly has connectors created by the Hybrid Configuration Wizard; Microsoft advises considering the hybrid model before manually duplicating that routing. All-cloud organizations with printers or applications may use an inbound connector for relay, but Microsoft also documents alternatives that should be evaluated for the specific sender. Microsoft’s interface describes connector endpoints as “From” and “To,” although the PowerShell cmdlets retain inbound and outbound terminology. Multiple connectors can apply in a scenario, so selection and scope must be understood. Accepted domains, destination domains, smart hosts, public IP addresses, certificates, DNS, and the sending system can all influence the actual path. Microsoft provides built-in validation for connectors that send from Microsoft 365 to an on-premises server or partner. Validation should be completed before a connector is turned on, and each required connector should be validated. Saving a change is an important boundary: Microsoft says the existing connector settings continue to govern mail flow until the edited configuration is saved. ## DSE recommendation: manage each connector as a production route Create a register in which each enabled or disabled connector has enough context to decide whether it is correct, broken, or obsolete: - connector identity, enabled state, creation source, last change, and tenant; - business service, business owner, technical owner, support contact, and review date; - expected sender, recipient, direction, domains, volume, and message examples; - on-premises servers, smart hosts, public addresses, certificates, accepted domains, DNS, firewall, and application dependencies; - normal success evidence, monitored failure signals, change window, rollback, and retirement trigger. Export the live connector configuration before making a change. Draw the complete route from the originating device, application, user, or server through Exchange Online to the final mailbox or external recipient, including the return path when replies or bidirectional exchange matter. Name which connector should be selected at each boundary and why. - Test representative messages. Use approved mailboxes and safe content to exercise each intended direction, recipient domain, application or device class, attachment requirement, and expected sender identity. - Validate platform and service behavior. Run Microsoft’s connector validation where available, then use message trace, message headers, application logs, on-premises queues, and recipient confirmation to prove the real route. - Exercise controlled failure. Where feasible, test a nonproduction or maintenance scenario for unavailable smart host, expired or mismatched dependency, rejected recipient, and unreachable destination. Confirm that monitoring and escalation identify the right owner. - Change one route deliberately. Record the old and proposed settings, predicted connector selection, test cases, save point, rollback, and observation period. Avoid changing DNS, firewall, certificate, application relay, and connector scope simultaneously without an integrated plan. - Retire stale paths. Correlate the register with message evidence and system ownership. Disable through an approved observation period before deletion when that approach fits the service, and preserve the configuration and reason for retirement. Review connectors after hybrid changes, datacenter moves, provider changes, certificate or address changes, application retirement, domain changes, and unexpected delivery incidents. Track unowned connectors, failed validations, routes without recent evidence, delivery failures, duplicate scopes, dependency expiration, and overdue reviews. The purpose is operational clarity. A connector should exist because a named service needs a defined route, and operations should be able to prove both that the route works and that mail does not depend on an abandoned server or undocumented exception. ## Official references - Microsoft Learn, [Configure mail flow using connectors in Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/use-connectors-to-configure-mail-flow), May 29, 2024. - Microsoft Learn, [Validate connectors in Exchange Online](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/validate-connectors), February 22, 2023. ## Primary reference - Name: Microsoft Learn: Configure mail flow using connectors in Exchange Online - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/use-connectors-to-configure-mail-flow - Source publication date: 2024-05-29 ## Citation and use Preferred citation: “Give every Exchange Online connector a route owner, test, and retirement date,” DSE Security, https://update.dsesecurity.com/updates/exchange-online-connector-governance-mail-flow/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give every microservice a security contract for identity, traffic, and failure > Microservices depend on APIs and shared architectural services. Define how each service authenticates, authorizes, discovers peers, protects traffic, limits load, records events, and fails. - Canonical URL: https://update.dsesecurity.com/updates/microservice-security-contracts/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:03+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Microservices depend on APIs and shared architectural services. Define how each service authenticates, authorizes, discovers peers, protects traffic, limits load, records events, and fails. ## Potentially affected Organizations designing or operating applications composed of independently developed and deployed services that communicate through APIs. ## DSE recommendation Document a versioned security contract for every service and enforce common controls through reviewed platform components without hiding service-specific authorization and failure behavior. ## Article Bottom line: splitting an application into smaller services also distributes trust and failure decisions. Every service needs an explicit contract describing who may call it, what may be requested, how communication is protected, how resources are bounded, what evidence is produced, and how the service behaves when dependencies fail. ## Source fact: what NIST identifies [NIST SP 800-204](https://csrc.nist.gov/pubs/sp/800/204/final) analyzes security strategies for microservices-based applications. NIST notes that microservices commonly communicate through APIs and identifies core features that include authentication and access management, service discovery, secure communications, security monitoring, availability and resiliency techniques, load balancing and throttling, integrity assurance when introducing services, and session persistence. The publication also discusses architectural frameworks such as API gateways and service meshes. The source supports treating those features as part of application security design rather than assuming service decomposition supplies them automatically. ## What the source does not establish Microservices are not inherently more secure than a monolith, and the publication does not certify a framework or deployment. A shared gateway can apply common controls, but it cannot infer every service’s business authorization rules. Encryption between services does not establish that the caller should perform the requested action. The right design depends on data classification, service criticality, transaction behavior, consistency requirements, deployment platform, dependency graph, and acceptable failure modes. ## Applicability questions - Which identities call the service, and how are human, workload, and administrative identities distinguished? - What operations and data are authorized for each caller and context? - How is the service discovered, and what prevents a caller from reaching an unintended instance or path? - What limits apply to request rate, concurrency, payload size, retries, and downstream consumption? - Which events allow an operator to reconstruct a distributed transaction without placing secrets in logs? ## DSE recommendation: write and test a service contract The following steps are DSE recommendations based on the cited source. - Record the service owner, purpose, interfaces, data handled, callers, dependencies, administrative path, deployment identity, and retirement plan. - Define authentication and authorization separately. State the accepted identity, audience, operation, resource scope, and any current business context required for the decision. - Specify communication and discovery requirements, including protected protocols, trusted endpoints, name or identity validation, certificate or key ownership, and rotation behavior. - Define resource and failure controls: timeouts, bounded retries, throttling, circuit breaking, back-pressure, and behavior when an identity, policy, or dependency is unavailable. - Assign common controls to gateways, meshes, or platform services where they can be applied consistently. Keep service-specific controls and ownership visible. - Version the contract with the interface and test both allowed and denied flows during release. ## Verification and evidence For a representative service, retain the contract, data-flow diagram, identity and authorization tests, protocol configuration, discovery and endpoint tests, resource-limit results, failure injection results, telemetry examples, and deployment record. Confirm that observed runtime flows match the approved caller and dependency list. ## Official references - [NIST SP 800-204 — Security Strategies for Microservices-based Application Systems](https://csrc.nist.gov/pubs/sp/800/204/final) — National Institute of Standards and Technology; published August 2019 - [NIST SP 800-204A — Building Secure Microservices-based Applications Using Service-Mesh Architecture](https://csrc.nist.gov/pubs/sp/800/204/a/final) — National Institute of Standards and Technology ## Primary reference - Name: NIST SP 800-204 — Security Strategies for Microservices-based Application Systems - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/204/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Give every microservice a security contract for identity, traffic, and failure,” DSE Security, https://update.dsesecurity.com/updates/microservice-security-contracts/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give every non-human Microsoft Entra identity an owner and an end date > Managed identities, service principals, and user-based service accounts can retain access without human visibility. Choose the safest type, record ownership and purpose, control permissions and credentials, monitor use, and retire dependencies safely. - Canonical URL: https://update.dsesecurity.com/updates/give-every-non-human-microsoft-entra-identity-an-owner-and-an-end-date/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 4 minutes ## What you need to know Managed identities, service principals, and user-based service accounts can retain access without human visibility. Choose the safest type, record ownership and purpose, control permissions and credentials, monitor use, and retire dependencies safely. ## Potentially affected Organizations using Microsoft Entra identities for applications, APIs, scripts, automation, Azure resources, Microsoft 365 integrations, or other unattended services. ## DSE recommendation Build one governed inventory and lifecycle for all non-human Entra identities, migrate away from user-based service accounts where possible, and require an owner, single purpose, least privilege, review date, and tested retirement plan. ## Article ## Source fact: Microsoft Entra has three service-account patterns Microsoft’s [cloud service-account guidance](https://learn.microsoft.com/en-us/entra/architecture/secure-service-accounts) identifies managed identities, service principals, and user-based service accounts. They represent applications, APIs, and other non-human services. Microsoft recommends a managed identity for an Azure-hosted service when supported, then a service principal when managed identity is unavailable. A Microsoft Entra user account is the last choice and is not recommended as a service account. A service principal is the tenant-local identity of an application instance and determines the application’s access. It can authenticate with a certificate or client secret; Microsoft recommends certificates when possible because a certificate cannot be accidentally embedded in code like a secret. A managed identity removes owner-managed credentials: Azure creates, protects, and rotates the credential used to obtain Entra tokens. ## Source fact: managed does not mean ownerless Microsoft’s [managed-identity security guidance](https://learn.microsoft.com/en-us/entra/architecture/service-accounts-managed-identities) distinguishes two lifecycles. A system-assigned identity has a one-to-one relationship with its Azure resource and is deleted with that resource. A user-assigned identity exists independently, can be attached to multiple resources, and is not automatically deleted when one of those resources disappears. Both still receive authorization through role assignments or a target service’s data-plane controls. Microsoft tells administrators to examine their privileges and ensure they are not members of privileged groups. This distinction creates different failure modes. A system-assigned identity can disappear when its resource is removed; a user-assigned identity can survive after all intended workloads are gone. Those are source-backed lifecycle properties. The requirement to map dependencies and plan removal is DSE’s operational response to them. ## DSE recommendation: use one lifecycle record across all three types DSE recommends one inventory for managed identities, service principals, and unavoidable user-based service accounts. For each identity, record its object and client identifiers as applicable, type, display name, accountable owner and backup owner, single business purpose, workload and repository, environments, resources reached, role assignments and application permissions, credential mechanism, creation date, next review, expected retirement, incident contact, and decommission evidence. Never place a secret value in that record. Make the identity request prove why a managed identity cannot be used before approving a service principal, and why neither can work before approving a user account. Give one service account one purpose so usage and impact remain understandable. For an inherited user-based account, document its actual dependencies before changing it, restrict unnecessary interactive use, apply only the permissions the service requires, and establish a migration target. ## Source fact: governance spans planning through deletion Microsoft’s [service-account governance model](https://learn.microsoft.com/en-us/entra/architecture/govern-service-accounts) calls for an owner, purpose, expected permission scopes, linked resources and scripts, risk, review period, lifetime, and standardized name. It applies least privilege, limits credential duration, monitors sign-in patterns, recertifies continuing need, and ends in permanent deletion. Microsoft specifically recommends checking for identities that no longer sign in and for changed sign-in patterns. It advises reviewing permissions regularly and avoiding non-expiring service-principal credentials. ## DSE recommendation: operate by identity type - Managed identity: review both Azure control-plane roles and target-service data access. For a user-assigned identity, enumerate attached resources and require an owner-managed retirement date. For a system-assigned identity, include identity and downstream-access effects in the resource-deletion change. - Service principal: prefer a certificate where supported, protect credential material in an approved vault, alert before expiration, and test rotation while the old credential still permits rollback. Monitor service-principal sign-ins and changes to credentials, owners, and permissions. - User-based service account: treat it as technical debt. Do not share it among services. Constrain sign-in and privilege, govern its password without creating an indefinite exception, monitor it separately from human users, and migrate to a managed identity or service principal when the workload permits. ## DSE recommendation: retire access without guessing Start retirement by confirming application, script, resource, and data-owner dependencies. Remove the workload from service, then disable the identity where that type supports disabling; otherwise isolate the workload or remove its effective assignments for a defined observation period with an approved rollback path. Check sign-in and resource logs for unexpected use. Revoke role assignments and other resource access, remove credential material and automation references, then delete the identity after owner approval and the observation window. Preserve the ticket, approvers, timestamps, dependency checks, and deletion evidence. This guide deliberately focuses on lifecycle ownership rather than duplicating detailed OAuth-consent or access-review procedures. Its central control is simpler: no non-human identity should enter production without a named owner, bounded purpose and privilege, an observable use pattern, and a planned end. ## Official sources - [Microsoft: Governing Microsoft Entra service accounts](https://learn.microsoft.com/en-us/entra/architecture/govern-service-accounts) - [Microsoft: Securing cloud-based service accounts](https://learn.microsoft.com/en-us/entra/architecture/secure-service-accounts) - [Microsoft: Securing managed identities in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/architecture/service-accounts-managed-identities) - [Microsoft: Securing service principals in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/architecture/service-accounts-principal) ## Primary reference - Name: Microsoft: Governing Microsoft Entra service accounts - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/architecture/govern-service-accounts - Source publication date: 2024-02-16 ## Citation and use Preferred citation: “Give every non-human Microsoft Entra identity an owner and an end date,” DSE Security, https://update.dsesecurity.com/updates/give-every-non-human-microsoft-entra-identity-an-owner-and-an-end-date/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give every security test written rules of engagement > A useful penetration test can also interrupt services, expose data, or resemble a real attack. Written rules of engagement turn scope, permission, safety boundaries, communications, evidence handling, and stop authority into testable controls. - Canonical URL: https://update.dsesecurity.com/updates/give-every-security-test-written-rules-of-engagement/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:38:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity - Reading time: 3 minutes ## What you need to know A useful penetration test can also interrupt services, expose data, or resemble a real attack. Written rules of engagement turn scope, permission, safety boundaries, communications, evidence handling, and stop authority into testable controls. ## Potentially affected Penetration tests, vulnerability validation, red-team exercises, external assessors, system owners, security operations, legal and privacy stakeholders, production services, and sensitive test evidence. ## DSE recommendation Approve rules of engagement before testing begins, validate every target and exclusion, establish communications and stop conditions, protect test data, and require retest evidence after remediation. ## Article ## Source facts: technical tests have different purposes and consequences NIST Special Publication 800-115 provides guidance for planning and conducting technical security tests and examinations, analyzing findings, and developing mitigation strategies. It describes techniques including review, target identification and analysis, vulnerability validation, and penetration testing. Each technique has different strengths, limitations, resource needs, and potential impact. A scan can identify a possible weakness without proving exploitability; a penetration test may demonstrate impact but can create operational risk. NIST organizes an assessment into planning, execution, and post-execution phases. Planning includes developing a policy, prioritizing and scheduling work, selecting and customizing techniques, managing logistics, identifying constraints, and establishing rules of engagement. Execution collects and validates data. Post-execution analyzes root causes, recommends mitigation, reports results, and supports remediation. Rules of engagement establish authority and boundaries for the assessment. Relevant subjects include purpose, scope, assumptions and limitations, risks, personnel, schedule, locations, equipment, communication, incident handling, target data, allowable and prohibited activities, data handling, and reporting. Because testing can look malicious, coordination with monitoring and incident-response functions must be intentional without unnecessarily defeating the exercise. ## DSE recommendation: make scope machine-verifiable and human-readable Name the sponsoring executive, system owner, test lead, provider, and person authorized to stop the work. State the objective in terms of the question the test must answer. List approved domains, addresses, applications, accounts, facilities, cloud tenants, interfaces, dates, and time zones. List exclusions just as precisely. Resolve shared hosting, supplier systems, subsidiaries, and dynamic cloud resources before execution. Confirm that the authorizing party has authority over every target and technique. Obtain separate written permission where a carrier, cloud provider, software supplier, landlord, or customer environment is involved. An internal contract cannot grant rights over someone else’s system. ## DSE recommendation: specify safety boundaries before the first packet - Control techniques. State whether social engineering, physical activity, credential attacks, persistence, malware simulation, exploitation, data access, privilege escalation, denial of service, or destructive commands are allowed, limited, or prohibited. - Define test identities and infrastructure. Register source addresses, tools, accounts, domains, callback systems, and expected artifacts so defenders can distinguish authorized work when necessary. - Protect production. Document backups, health checks, rate limits, fragile systems, prohibited hours, rollback steps, and the threshold for pausing activity. - Establish communications. Maintain primary and out-of-band contacts, check-in times, incident escalation, suspected-real-attack procedures, and a shared understanding of what defenders will and will not know. - Protect evidence. Define collection minimization, encryption, access, transfer, retention, deletion, and breach reporting for credentials, personal information, configuration, screenshots, packet captures, and exploit artifacts. ## DSE recommendation: preserve learning without preserving unnecessary risk Require testers to report critical safety or active-compromise findings immediately through the agreed channel. At completion, remove accounts, payloads, persistence, files, firewall changes, test data, and temporary infrastructure; then have the system owner verify cleanup. Record any artifact that cannot be removed. Reports should separate confirmed exploitation from inferred exposure, state the tested path and conditions, preserve evidence provenance, describe business consequence without overstating it, and identify limitations. Assign remediation owners and acceptance authority. Retest the corrected path and verify that the fix did not merely block one tool signature. Close with a joint review of unexpected effects, detection and response performance, communication failures, scope gaps, and assumptions. Retain authorization, final rules, activity logs, evidence index, findings, cleanup confirmation, and retest results under controlled access. Track the disposition of every copied credential or sensitive record and obtain written confirmation when the testing provider completes required deletion. Good rules do not make a test timid; they make its risk deliberate and its conclusions defensible. ## Official references - National Institute of Standards and Technology, [SP 800-115: Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final), September 30, 2008; reviewed August 11, 2026. ## Primary reference - Name: NIST SP 800-115: Technical Guide to Information Security Testing and Assessment - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/115/final - Source publication date: 2008-09-30 ## Citation and use Preferred citation: “Give every security test written rules of engagement,” DSE Security, https://update.dsesecurity.com/updates/give-every-security-test-written-rules-of-engagement/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give every shared mailbox an owner, sign-in boundary, and review cadence > Shared mailboxes outlive projects and teams unless someone owns membership, direct sign-in, forwarding, retention, licensing, automation, and closure. Govern each mailbox as a business service, not a permanent bucket of delegated access. - Canonical URL: https://update.dsesecurity.com/updates/give-every-shared-mailbox-owner-signin-boundary-review-cadence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:02:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Shared mailboxes outlive projects and teams unless someone owns membership, direct sign-in, forwarding, retention, licensing, automation, and closure. Govern each mailbox as a business service, not a permanent bucket of delegated access. ## Potentially affected Exchange Online shared mailboxes and associated user objects, Full Access, Send As and Send on Behalf permissions, automapping, forwarding and inbox rules, mobile access, applications, retention and holds, licenses, inactive owners, external mail, and continuity procedures. ## DSE recommendation Assign business and technical owners, block direct sign-in, document purpose and data handling, grant delegates through their own licensed identities with least privilege, review membership and configuration, monitor risky changes, and use a controlled closure or transfer process. ## Article ## Source facts: a shared mailbox is accessed through delegated user identities Microsoft’s [shared-mailbox overview](https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes?view=o365-worldwide) describes shared mailboxes for addresses used by multiple people, such as support or reception. It says delegates should access through their own licensed Exchange Online mailboxes and that the associated shared-mailbox account is not intended for direct sign-in. Microsoft instructs administrators to block that sign-in and keep it blocked. Microsoft’s [recipient-permissions documentation](https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-permissions-for-recipients) distinguishes Full Access, Send As, and Send on Behalf. These permissions produce different capabilities: opening mailbox contents is not the same as sending with the mailbox identity. Microsoft also documents licensing and feature conditions that can apply based on mailbox size, archive, hold, Defender, Purview, and other use. Licensing and service limits change, so the current Microsoft service description and tenant entitlements must be checked. Retention, litigation hold, privacy, records, labor, and industry obligations require qualified governance or legal input. Blocking direct sign-in does not remove delegated access, application access, forwarding, rules, or content already copied elsewhere. ## DSE recommendation: manage the mailbox from request through retirement Create a register for every shared mailbox: SMTP addresses, purpose, business owner, technical owner, delegates by permission, approved send behavior, applications, forwarding, data classification, retention or hold, license, expected volume, continuity use, review date, and closure trigger. A mailbox without an accountable business owner should be escalated, not automatically preserved forever. - Establish the sign-in boundary. Verify the associated user object is blocked from direct sign-in and has no known human password in use. Remove unnecessary authentication methods under the supported process. Do not distribute a shared password as a substitute for delegation. - Grant the minimum permission. Decide separately who must read and manage content, who may send as the mailbox, and who may send on behalf. Use named governed identities or approved groups as supported, avoid nested ambiguity, and require stronger review for mailboxes that authorize transactions or reset accounts. - Inspect hidden movement. Review mailbox and inbox rules, forwarding, delegates, mobile and application access, connectors, aliases, automatic replies, and approved automation. Confirm external forwarding and OAuth applications comply with policy. Preserve authorized business workflows while removing unexplained paths. - Design continuity. Define who monitors the mailbox, expected response time, out-of-hours handling, alternate owner, queue or ticket integration, and what happens during owner absence. A mailbox is not a service desk merely because several people can open it. - Review content governance. Match retention and deletion to approved records requirements, holds, privacy, and business need. Confirm license requirements for the selected features. Limit local exports and personal-folder copies that defeat central governance. - Retire deliberately. At project or function end, stop new use, communicate replacement addresses, preserve required records, remove delegates and applications, handle aliases and forwarding for a bounded period, and document final disposition. Verify the old identity cannot still receive privileged workflows. Review high-impact mailboxes more frequently and after owner, team, vendor, application, or business-process change. Monitor permission changes, sign-in enablement, forwarding, unusual sending, rule creation, and administrative modifications through the tenant’s available audit and alerting capabilities. Investigate a mailbox account that authenticates directly. The review record should distinguish business approval from technical verification. An owner approves who needs what; administrators prove the resulting permissions, sign-in state, rules, licensing, and controls. That separation turns a shared mailbox from an inherited convenience into an accountable communications service. For the review sample, use both directions: start with delegates and confirm their authorized mailbox need, then start with mailboxes and confirm every delegate and send permission. Send a controlled message only where appropriate to prove display identity and reply handling. Stop closure if a legal hold, application, regulated record, customer-facing address, or continuity process has no approved disposition; resolve ownership before changing delivery. ## Official references - Microsoft, [About shared mailboxes in Microsoft 365](https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes?view=o365-worldwide). - Microsoft, [Manage permissions for recipients in Exchange Online](https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/manage-permissions-for-recipients). ## Primary reference - Name: Microsoft Learn: About shared mailboxes in Microsoft 365 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/microsoft-365/admin/email/about-shared-mailboxes?view=o365-worldwide - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Give every shared mailbox an owner, sign-in boundary, and review cadence,” DSE Security, https://update.dsesecurity.com/updates/give-every-shared-mailbox-owner-signin-boundary-review-cadence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give the board cybersecurity metrics that support risk decisions > A board dashboard should connect cyber exposure and control evidence to enterprise objectives, risk tolerance, accountable owners, and decisions. Replace unbounded activity counts with trends, denominators, uncertainty, and asks. - Canonical URL: https://update.dsesecurity.com/updates/give-the-board-cybersecurity-metrics-that-support-risk-decisions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 4 minutes ## What you need to know A board dashboard should connect cyber exposure and control evidence to enterprise objectives, risk tolerance, accountable owners, and decisions. Replace unbounded activity counts with trends, denominators, uncertainty, and asks. ## Potentially affected Boards, audit and risk committees, executives, enterprise risk management, cybersecurity leaders, finance, business owners, internal audit, and data owners. ## DSE recommendation Organize reporting around material risk scenarios and decisions, define every metric and denominator, show uncertainty and trend, and make the required board or management action explicit. ## Article ## Source fact: cyber reporting belongs in enterprise risk decisions [NIST IR 8286 Revision 1](https://csrc.nist.gov/pubs/ir/8286/r1/final) connects cybersecurity risk management with enterprise risk management. It describes how cybersecurity risk registers can be aggregated and normalized so directors and senior leaders receive a clear view of risk posture in the context of enterprise objectives. The purpose is not to convert every cyber event into a board metric; it is to support prioritization, response, and oversight at the correct organizational level. The [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) places organizational context, risk-management strategy, roles and responsibilities, policy, oversight, and cyber supply-chain risk in its Govern function. NIST’s [Enterprise Risk Management Quick-Start Guide](https://csrc.nist.gov/pubs/sp/1303/final) describes a common language for integrating cybersecurity outcomes and monitoring across organizational units. Together, these sources support decision-oriented reporting rather than a security-team activity report. ## DSE recommendation: start each page with a risk decision DSE recommendation: organize the board packet around the enterprise risks that could change strategy, service delivery, safety, legal exposure, financial performance, or stakeholder trust. For each material scenario, show: - the enterprise objective or critical service at risk; - the scenario, relevant threat and exposure, and important dependencies; - the potential impact range, time horizon, and uncertainty; - the current response and relationship to approved risk appetite or tolerance; - the accountable business owner and control owners; - leading control evidence, lagging events, trend, and data limitations; - open exceptions, concentration risks, and corrective-action dates; and - the decision, challenge, funding, acceptance, or escalation required. The board should be able to tell what has changed, why it matters, who owns it, and what response is requested. If there is no board-level decision or oversight purpose, place the detail in management reporting and provide a summarized linkage. ## Build measures that can be interpreted Every metric needs a definition, numerator and denominator where applicable, population and exclusions, data owner, source system, collection cadence, target or tolerance owner, trend period, and known limitations. Show changes in method so a redesigned denominator does not appear to be a sudden security improvement. Distinguish measured fact from analyst estimate and state when stale or incomplete data makes a conclusion uncertain. Possible DSE-designed measures include the percentage of critical services with recovery evidence meeting the service’s approved objective; high-risk exceptions by age, owner, and business impact; strong identity-control coverage across the defined privileged population; known-exploited-vulnerability exposure linked to affected services; concentration in suppliers supporting critical services; and exercise or recovery findings closed and successfully retested. These are examples, not NIST-prescribed metrics or universal thresholds. Each organization must select evidence connected to its own objectives and tolerance. ## Avoid attractive numbers with no decision value Raw blocked-attack counts can rise because attacks increased, telemetry improved, or a control changed. Total CVEs can grow while exposure falls. Phishing click rates can change with scenario difficulty and reporting behavior. A maturity score can hide a critical exception. Present such measures only with context and a clear decision use. Do not label a risk green solely because an operational service-level target was met if the residual enterprise risk remains above tolerance. NIST’s [CSF 2.0 Organizational Profiles guide](https://csrc.nist.gov/pubs/sp/1301/final) explains how current and target profiles can reflect mission, stakeholder expectations, threats, and requirements and communicate gaps. The [CSF Tiers guide](https://www.nist.gov/publications/nist-cybersecurity-framework-20-quick-start-guide-using-csf-tiers) uses tiers to characterize the rigor of cybersecurity risk governance and management. Neither device should be presented as a universal compliance score or a substitute for the underlying risk evidence. ## Make the reporting cycle governable Assign an executive owner to approve the risk narrative and a data owner to attest to each material metric. Reconcile the board view to business-unit and enterprise risk registers. Record board decisions, challenge, accepted uncertainty, requested analysis, and due dates. When an indicator crosses an organization-approved escalation point, show the response and owner, not only a red icon. Periodically ask whether each measure changed a decision, exposed a blind spot, or confirmed that a response worked. Retire metrics that no longer serve those purposes. A smaller packet with traceable evidence and explicit asks gives the board more usable oversight than a dense dashboard of counts whose direction cannot be explained. ## Official sources - [NIST: IR 8286 Revision 1, Integrating Cybersecurity and Enterprise Risk Management](https://csrc.nist.gov/pubs/ir/8286/r1/final) - [NIST: Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) - [NIST: SP 1303, Enterprise Risk Management Quick-Start Guide](https://csrc.nist.gov/pubs/sp/1303/final) - [NIST: SP 1301, Organizational Profiles](https://csrc.nist.gov/pubs/sp/1301/final) - [NIST: SP 1302, Using the CSF Tiers](https://www.nist.gov/publications/nist-cybersecurity-framework-20-quick-start-guide-using-csf-tiers) ## Primary reference - Name: NIST IR 8286 Revision 1 - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/ir/8286/r1/final - Source publication date: 2025-12-18 ## Citation and use Preferred citation: “Give the board cybersecurity metrics that support risk decisions,” DSE Security, https://update.dsesecurity.com/updates/give-the-board-cybersecurity-metrics-that-support-risk-decisions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Give the Facility Security Officer authority, access, and continuous contact coverage > Use 33 CFR 105.205 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/give-the-facility-security-officer-authority-access-and-continuous-contact-coverage/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:21+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.205 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.205 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Give the Facility Security Officer authority, access, and continuous contact coverage. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.205 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.205) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, in addition to those responsibilities and duties specified elsewhere in this part, the FSO must, for each facility for which he or she has been designated: ensure that the Facility Security Assessment (FSA) is conducted. The research record locates this support at 33 CFR 105.205(c)(1), read with 33 CFR 105.205(c) (eCFR anchor p-105.205(c)(1)). - Under 33 CFR 105, in addition to those responsibilities and duties specified elsewhere in this part, the FSO must, for each facility for which he or she has been designated: ensure the security awareness and vigilance of the facility personnel. The research record locates this support at 33 CFR 105.205(c)(6), read with 33 CFR 105.205(c) (eCFR anchor p-105.205(c)(6)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths only where the source and recorded environment align. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.205(c)(1), read with 33 CFR 105.205(c) (eCFR anchor p-105.205(c)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.205(c)(6), read with 33 CFR 105.205(c) (eCFR anchor p-105.205(c)(6)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from 33 CFR 105.205(c)(1), read with 33 CFR 105.205(c) (eCFR anchor p-105.205(c)(1)); 33 CFR 105.205(c)(6), read with 33 CFR 105.205(c) (eCFR anchor p-105.205(c)(6)) through asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [33 CFR 105.205 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.205) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.205 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.205 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Give the Facility Security Officer authority, access, and continuous contact coverage,” DSE Security, https://update.dsesecurity.com/updates/give-the-facility-security-officer-authority-access-and-continuous-contact-coverage/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern 32-bit BGP communities as transitive routing policy tags > Use RFC 1997 — BGP Communities Attribute to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/govern-32-bit-bgp-communities-as-transitive-routing-policy-tags/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:27+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 1997 — BGP Communities Attribute to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 1997 — BGP Communities Attribute ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Govern 32-bit BGP communities as transitive routing policy tags. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 1997 — BGP Communities Attribute](https://www.rfc-editor.org/rfc/rfc1997.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - The BGP COMMUNITIES attribute is optional and transitive and contains a variable-length set of four-octet community values. The research record locates this support at Section COMMUNITIES attribute. - NO_EXPORT blocks advertisement beyond a confederation, NO_ADVERTISE blocks every peer advertisement, and NO_EXPORT_SUBCONFED blocks external peers including other member ASes inside a confederation. The research record locates this support at Section Well-known Communities. - A speaker may add or locally modify communities and use them to control which routes it accepts, prefers, or distributes. The research record locates this support at Section Operation. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section COMMUNITIES attribute, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section Well-known Communities, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section Operation, which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to Section COMMUNITIES attribute; Section Well-known Communities; Section Operation and to observable material such as configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 1997 — BGP Communities Attribute](https://www.rfc-editor.org/rfc/rfc1997.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 1997 — BGP Communities Attribute - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc1997.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Govern 32-bit BGP communities as transitive routing policy tags,” DSE Security, https://update.dsesecurity.com/updates/govern-32-bit-bgp-communities-as-transitive-routing-policy-tags/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern every Safe Links exception as a monitored bypass > Safe Links can scan and rewrite URLs and evaluate clicks in supported Microsoft 365 experiences; exclusions and do-not-rewrite entries narrow that inspection and need evidence-based ownership. - Canonical URL: https://update.dsesecurity.com/updates/defender-safe-links-exception-governance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:17+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Safe Links can scan and rewrite URLs and evaluate clicks in supported Microsoft 365 experiences; exclusions and do-not-rewrite entries narrow that inspection and need evidence-based ownership. ## Potentially affected Organizations using Microsoft Defender for Office 365 Safe Links across email, Teams, and supported Office applications. ## DSE recommendation Map effective policy precedence, minimize exclusions and do-not-rewrite entries, test each business dependency, and review click evidence and bypass use on a fixed cadence. ## Article Bottom line: Safe Links can rewrite and scan URLs in email and evaluate clicks in supported Teams and Office experiences. A recipient exception or do-not-rewrite URL creates a different protection path. Treat every bypass as a scoped, owned, tested, and expiring security decision. ## Source fact: what Microsoft documents Microsoft’s [Safe Links policy guide](https://learn.microsoft.com/en-us/defender-office-365/safe-links-policies-configure) documents separate Safe Links policies and rules. The policy holds protection behavior; the rule holds priority, recipient conditions, exclusions, and state. Portal creation combines these objects, while PowerShell exposes them separately. Microsoft documents protection settings for email, Teams, and supported Office apps, including URL scanning, rewriting, click tracking, warning-page behavior, and whether a user may continue to the original URL. The guide also documents do-not-rewrite URL entries and policy precedence. Standard and Strict preset security policies are evaluated ahead of custom policies, so a custom exclusion may not affect a recipient governed by a preset policy. Microsoft provides a propagation window and verification procedures. ## What the source does not establish Safe Links does not certify a destination as safe or prevent harm after a user reaches an allowed site. It does not cover every application, protocol, copied URL, redirect, QR code, or unsupported client. A rewrite exception does not prove that a business application needed broad bypass; the actual dependency may be narrower. Click tracking and investigation data also raise access and retention questions that the configuration page does not resolve for the organization. ## Applicability questions - Which recipients are effectively covered by Built-in, Standard, Strict, and custom policies? - Which apps and clients do users actually use to open email, Teams messages, and Office documents? - Why does each recipient exclusion or do-not-rewrite URL exist, and what exact function fails without it? - Can the exception be restricted to a full URL or domain path instead of a broader pattern? - Who may view click data, investigate warnings, and authorize bypass or release decisions? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Inventory effective policy membership, custom-rule priority, exclusions, and do-not-rewrite entries. Resolve policy overlap first. - For every requested bypass, reproduce the business failure, record the narrowest required pattern and recipients, and test a safer application fix. - Pilot policy changes with representative clients and links, including internal senders, redirected URLs, Office documents, and Teams where applicable. - Assign each exception an owner, rationale, approval, monitoring plan, and review or expiration date. - Review warnings, click events, phishing investigations, false positives, and exception use after rollout. ## Verification and evidence - Preserve policy and rule configuration, precedence, scope, and exception register. - Capture message or click evidence showing the expected policy handled each test case. - Test allowed, warned, blocked, bypassed, and user-click-through behavior without directing users to live malicious content. - Retest exceptions after the dependent application or authentication flow changes. ## Official references - [Set up Safe Links policies in Microsoft Defender for Office 365](https://learn.microsoft.com/en-us/defender-office-365/safe-links-policies-configure) — Microsoft ## Primary reference - Name: Set up Safe Links policies in Microsoft Defender for Office 365 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-office-365/safe-links-policies-configure - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Govern every Safe Links exception as a monitored bypass,” DSE Security, https://update.dsesecurity.com/updates/defender-safe-links-exception-governance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern every sensitive information exchange through its full lifecycle > Information remains exposed before, during, and after an exchange—regardless of whether it moves through an API, portal, file transfer, email, shared database, or manual process. Put protection duties and exit conditions in an owned agreement. - Canonical URL: https://update.dsesecurity.com/updates/govern-sensitive-information-exchanges-through-full-lifecycle/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:42:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Information remains exposed before, during, and after an exchange—regardless of whether it moves through an API, portal, file transfer, email, shared database, or manual process. Put protection duties and exit conditions in an owned agreement. ## Potentially affected Data exchanges with suppliers, customers, affiliates and internal units; application interfaces; shared platforms; file transfer; email; reports; contracts; privacy; incident response; retention; and relationship termination. ## DSE recommendation Inventory recurring sensitive exchanges, classify the information and participants, document protection and response duties, approve the agreement, monitor operation and changes, and rehearse orderly and emergency termination. ## Article ## Source facts: protection follows the information, not one connection type NIST Special Publication 800-47 Revision 1 addresses the security of information exchanges. Organizations exchange or provide access to information through many channels, including connections, services, files, messages, removable media, applications, and manual processes. NIST focuses on protecting information before, during, and after the exchange rather than prescribing one technology. The publication describes identifying exchanges, assessing risk, selecting protections, establishing agreements, maintaining the exchange, and ending it. The form of agreement can vary with risk and organizational need. Examples include interconnection security agreements, memoranda of understanding or agreement, service-level agreements, nondisclosure agreements, contracts, and user agreements. More than one instrument may be needed to cover technical, operational, legal, privacy, and business responsibilities. An agreement does not itself create protection. The parties must implement, operate, monitor, and periodically review the agreed safeguards. Changes in information, purpose, participants, architecture, ownership, threat, or law can alter risk. Termination also needs planning so access, credentials, routes, stored copies, and continuing obligations do not persist unnoticed. ## DSE recommendation: create an exchange register before reviewing contracts Inventory recurring exchanges of sensitive or operationally important information across external parties and internal units with separate authority. Record the business purpose, source, recipient, data elements, volume, frequency, direction, channel, locations, owners, users, decisions supported, and systems involved. Include exports, support access, shared dashboards, telemetry, backups, identity federation, reports, and informal transfers that bypass the expected interface. Classify the information and identify confidentiality, integrity, availability, privacy, safety, retention, and provenance requirements on both sides. Determine whether the recipient may combine the data, use it for another purpose, create derived information, disclose it to a subcontractor, or make automated decisions from it. ## DSE recommendation: make responsibilities executable - Name accountable parties. Identify information owners, system owners, security and privacy contacts, operational contacts, incident contacts, change approvers, and termination authority for each participant. - Define protections end to end. Cover identity, least privilege, transfer, storage, integrity, validation, logging, time, monitoring, backup, disposal, personnel access, physical protection, and subcontractors. - Specify evidence and notification. State which logs and records exist, who can obtain them, preservation and response time, incident thresholds, communication channels, investigation cooperation, and notification responsibilities. - Control change. Require review for new fields, purposes, users, endpoints, regions, service providers, interfaces, cryptographic changes, retention, and material control changes. Define emergency changes and retrospective approval. - Plan disconnection. Address normal expiration, breach, unsafe conditions, loss of authorization, emergency suspension, credential revocation, route removal, data return or deletion, residual copies, and continuity impact. ## DSE recommendation: verify operation and exit Before launch, test authorized and unauthorized transactions, data validation, error handling, duplicate or delayed messages, rate and volume limits, monitoring, incident contacts, recovery, and evidence retrieval. Confirm that both parties interpret responsibilities the same way. Approve residual risk and unresolved assumptions through the named authority. Monitor activity against the agreed purpose, population, destination, frequency, protections, and service expectations. Reconcile actual participants and flows to the register. Review agreements on a risk-based schedule and after incidents or material changes; a renewal date alone may be too late. Exercise orderly and emergency termination. Verify that exchanges stop without unsafe business consequences, access and secrets are revoked, automated jobs and cached routes are removed, retained information is handled as agreed, required evidence remains available, and downstream parties are addressed. Confirm termination from both sides; one party’s disabled job does not prove the other party deleted access or copies. Keep the register, assessment, signed instruments, test evidence, change history, reviews, incidents, approvals, and closure proof. That lifecycle record turns a data connection into an accountable information relationship. ## Official references - National Institute of Standards and Technology, [SP 800-47 Revision 1: Managing the Security of Information Exchanges](https://csrc.nist.gov/pubs/sp/800/47/r1/final), July 20, 2021; reviewed August 11, 2026. ## Primary reference - Name: NIST SP 800-47 Rev. 1: Managing the Security of Information Exchanges - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/47/r1/final - Source publication date: 2021-07-20 ## Citation and use Preferred citation: “Govern every sensitive information exchange through its full lifecycle,” DSE Security, https://update.dsesecurity.com/updates/govern-sensitive-information-exchanges-through-full-lifecycle/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern evidence locks as retention exceptions, not permanent pins > An evidence lock can preserve selected video beyond normal retention. Define who may create, extend, review, and remove each lock before storage and legal obligations collide. - Canonical URL: https://update.dsesecurity.com/updates/govern-evidence-locks-as-retention-exceptions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:36:11+00:00 - Modified: 2026-08-25T21:36:16+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, Video Surveillance - Reading time: 2 minutes ## What you need to know An evidence lock can preserve selected video beyond normal retention. Define who may create, extend, review, and remove each lock before storage and legal obligations collide. ## Potentially affected XProtect Corporate deployments using evidence locks to preserve recordings for investigations, litigation, regulatory review, or internal holds. ## DSE recommendation Require a case owner, scope, reason, expiration, access restriction, periodic review, and witnessed release for every evidence lock. ## Article Bottom line: an evidence lock is an exception to ordinary retention, not a substitute for case management. Without ownership and release controls, locks can accumulate indefinitely; if a lock is removed after ordinary retention has expired, the protected recording may become eligible for deletion. ## Source fact: evidence locks override normal retention for selected recordings Milestone’s [XProtect evidence-lock documentation](https://doc.milestonesys.com/2025r2/en-US/wp_storage_arch/evidence_lock.htm) explains that evidence locks in XProtect Corporate protect selected recordings from the normal retention process. The system supports permissions for evidence-lock operations, a configured lock duration, and status information. The documentation also warns that deleting a lock can result in deletion of recordings that are already older than the standard retention period. The important operational event is therefore not only creation. Extension, expiration, and removal can change whether the last retained copy continues to exist. ## Source boundary and applicability The page documents a Milestone feature; it does not determine legal-hold scope, evidence admissibility, chain of custody, or required retention. Availability and behavior depend on XProtect edition, version, permissions, storage configuration, and the recorded devices included. Counsel or the designated records authority should define binding hold requirements. ## Applicability questions - What event, case, request, or obligation authorizes the lock? - Which cameras and exact time interval are necessary, including pre-event and post-event context? - Who may create, extend, export, and delete locks, and are those actions logged? - What review occurs before expiration or manual removal? - Is the locked database the authoritative evidence copy, or must a verified export also be preserved? ## DSE recommendation: require a lock record and controlled release The following steps are DSE recommendations based on the cited source. Assign each lock a unique case identifier, accountable owner, approving authority, reason, camera and time scope, creation date, review date, and expected release condition. Separate permission to view video from permission to delete a lock. Use the narrowest defensible interval, while preserving enough context to avoid misleading fragments. Review open locks on a defined cadence with records, legal, security, and storage owners. Before shortening or deleting one, confirm authorization, determine whether ordinary retention has elapsed, verify any required export and hash, and record the effect on storage. Emergency deletion to recover capacity should follow the same escalation and documentation, not an undocumented administrator shortcut. ## Verification and evidence Retain the lock register, approval, XProtect status export or screenshots, audit events, storage-capacity trend, periodic review record, and release authorization. For a controlled test case, show that locked video survives normal retention and document exactly what occurs after authorized release. Never use production evidence merely to test deletion behavior. ## Official references - [XProtect evidence locks](https://doc.milestonesys.com/2025r2/en-US/wp_storage_arch/evidence_lock.htm) – Milestone Systems ## Primary reference - Name: XProtect evidence locks - Authority: doc.milestonesys.com - URL: https://doc.milestonesys.com/2025r2/en-US/wp_storage_arch/evidence_lock.htm - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Govern evidence locks as retention exceptions, not permanent pins,” DSE Security, https://update.dsesecurity.com/updates/govern-evidence-locks-as-retention-exceptions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern FTC Safeguards Rule service providers through the full relationship > For financial institutions actually covered by the FTC Safeguards Rule, service-provider oversight connects risk-based selection, tailored contract safeguards, ongoing monitoring, periodic reassessment, remediation, and secure exit. - Canonical URL: https://update.dsesecurity.com/updates/govern-ftc-safeguards-rule-service-providers-through-the-full-relationship/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 4 minutes ## What you need to know For financial institutions actually covered by the FTC Safeguards Rule, service-provider oversight connects risk-based selection, tailored contract safeguards, ongoing monitoring, periodic reassessment, remediation, and secure exit. ## Potentially affected Organizations that legal counsel determines are financial institutions subject to FTC jurisdiction under the Gramm-Leach-Bliley Act Safeguards Rule, plus personnel selecting or overseeing service providers with access to customer information. ## DSE recommendation Confirm applicability with qualified counsel, inventory in-scope service providers and customer-information access, and assemble selection, contract, monitoring, reassessment, remediation, and exit evidence for each relationship. ## Article ## Applicability boundary: confirm the regulator and the activity first Source fact: The FTC says its [Safeguards Rule](https://www.ftc.gov/legal-library/browse/rules/safeguards-rule) applies to financial institutions under FTC jurisdiction that are not subject to another regulator’s enforcement authority under section 505 of the Gramm-Leach-Bliley Act. The regulatory definition is broader than everyday use of the phrase financial institution and depends on activities, customer information, jurisdiction, and any applicable exceptions. DSE boundary: This article is operational security guidance, not legal advice and not a determination that any reader, affiliate, provider, data set, or contract is covered. Qualified counsel and the organization’s compliance function should determine applicable law, regulator, definitions, exemptions, and contractual duties. Organizations governed by another financial regulator may have different or additional requirements. ## Source fact: section 314.4(f) creates a three-part duty The current rule requires a covered financial institution to take reasonable steps to select and retain service providers capable of maintaining appropriate safeguards for the customer information at issue, require providers by contract to implement and maintain those safeguards, and periodically assess providers based on the risk they present and the continued adequacy of their safeguards. The FTC’s [official FAQ](https://www.ftc.gov/business-guidance/resources/automobile-dealers-ftcs-safeguards-rule-frequently-asked-questions) explains that exact steps depend on the institution’s size and complexity and the nature of the service. A Safeguards Rule service provider receives, maintains, processes, or otherwise is permitted access to customer information while providing services directly to a covered financial institution. Sharing information does not make every recipient a service provider in every circumstance. The FAQ also cautions that oversight does not necessarily require every provider to satisfy every safeguard that applies to the financial institution; safeguards should be appropriate to the customer information and service. ## DSE recommendation: make selection evidence match the service Before approval, identify the business owner, service, customer information, data locations and flows, access method, privileged connectivity, integrations, subcontractors, retention, availability need, incident dependency, and exit method. Assign inherent risk from those facts. Request evidence proportional to the risk and service: current independent reports where relevant, control descriptions and exceptions, architecture and data-flow answers, vulnerability and patch practices, identity and access controls, encryption and key responsibilities, logging, recovery testing, incident history and response, personnel controls, and subcontractor governance. Record who evaluated each item, its coverage period, qualifications, limitations, unresolved exceptions, and decision. A certification logo or questionnaire score is evidence with boundaries, not a legal conclusion or substitute for analysis of the actual service. ## DSE recommendation: translate risk into reviewable contract terms Work with counsel to state the information and systems in scope, required safeguards, permitted uses and locations, access limitations, incident notification and cooperation, evidence delivery, vulnerability and remediation responsibilities, business continuity, subcontractor conditions, material-change notice, monitoring or assessment rights, return or destruction of information, transition assistance, records, and consequences for unresolved failure. Tailor terms to the service rather than copying a control catalog blindly. Preserve the executed agreement, amendments, security exhibits, approvals, and accepted deviations. ## DSE recommendation: monitor the relationship, not only the renewal date - Set a risk-based review plan with accountable business, security, compliance, procurement, and legal roles. - Track evidence expiration, reported incidents, material architecture or ownership changes, new subprocessors, access or data-scope changes, service failures, audit exceptions, and remediation commitments. - Compare current evidence with the contract and prior assessment. Document changed risk, continued adequacy, gaps, compensating measures, due dates, and approval. - Trigger reassessment after material service, data, threat, incident, control, or business-arrangement change rather than waiting automatically for a calendar date. - Escalate persistent gaps through defined decision authority. Record acceptance, restriction, remediation, suspension, replacement, or termination. ## Exit is part of oversight Before termination, identify required records and dependencies, revoke provider and remote access, rotate shared secrets and certificates, transfer operational knowledge, obtain return or destruction evidence where required, preserve legal and audit records, validate replacement controls, and monitor for residual connections. Close the provider record only when technical and contractual exit evidence agree. This scope is narrower than general cyber supply-chain governance: it translates the FTC’s specific service-provider provision into an evidence lifecycle for organizations whose counsel confirms FTC Safeguards Rule coverage. ## Official sources - [16 CFR Part 314, Standards for Safeguarding Customer Information](https://www.ecfr.gov/current/title-16/chapter-I/subchapter-C/part-314) - [FTC Safeguards Rule legal-library page](https://www.ftc.gov/legal-library/browse/rules/safeguards-rule) - [FTC Safeguards Rule: What Your Business Needs to Know](https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know) - [FTC Safeguards Rule Frequently Asked Questions for Automobile Dealers](https://www.ftc.gov/business-guidance/resources/automobile-dealers-ftcs-safeguards-rule-frequently-asked-questions) ## Primary reference - Name: Federal Trade Commission — Safeguards Rule: What Your Business Needs to Know - Authority: Federal Trade Commission - URL: https://www.ftc.gov/business-guidance/resources/ftc-safeguards-rule-what-your-business-needs-know - Source publication date: 2022-04-27 ## Citation and use Preferred citation: “Govern FTC Safeguards Rule service providers through the full relationship,” DSE Security, https://update.dsesecurity.com/updates/govern-ftc-safeguards-rule-service-providers-through-the-full-relationship/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern IPv6 even when the network is called IPv4-only > IPv6 may be active on endpoints, servers, and network equipment before an organization intentionally deploys it. Unmanaged IPv6 creates a parallel path around inventories, filtering, monitoring, segmentation, and incident procedures designed only for IPv4. - Canonical URL: https://update.dsesecurity.com/updates/govern-ipv6-on-ipv4-first-networks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-11T09:47:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 4 minutes ## What you need to know IPv6 may be active on endpoints, servers, and network equipment before an organization intentionally deploys it. Unmanaged IPv6 creates a parallel path around inventories, filtering, monitoring, segmentation, and incident procedures designed only for IPv4. ## Potentially affected Windows and Linux endpoints, servers, switches, routers, firewalls, wireless networks, VPNs, hypervisors, cloud networks, monitoring platforms, IoT devices, cameras, and access-control systems. ## DSE recommendation Discover actual IPv6 use, choose an explicit operating state per segment, apply equivalent controls to both protocols, govern transition mechanisms, and test monitoring and response with IPv6 traffic. ## Article ## Source fact: IPv6 changes the network, not merely the address length NIST SP 800-119 explains that IPv6 is a distinct network-layer protocol with different addressing, discovery, configuration, routing, and transition behavior from IPv4. Secure deployment requires planning, inventory, compatible security controls, staff knowledge, and testing. During transition, many organizations operate IPv4 and IPv6 concurrently, which increases complexity and can expose paths that were not considered in an IPv4-only design. IPv6 capability can exist before a formal project begins. Modern operating systems and network products may enable an IPv6 stack, link-local communication, automatic configuration, or tunneling features. An organization that has not assigned production IPv6 addresses may therefore still have IPv6-capable systems and local traffic. NIST warns that unauthorized or unknown IPv6 assets and transition mechanisms can be difficult to detect when operations and security teams focus only on IPv4. Firewalls, intrusion detection, asset discovery, vulnerability management, flow monitoring, DNS, and incident tools must understand the protocol they are expected to control. ## Source fact: disabling one visible feature may not remove every path IPv6 traffic can be native, dual-stack, or carried through a transition or tunneling mechanism. Controls applied only to native routed traffic may miss encapsulated communication. Likewise, a perimeter firewall does not govern malicious or accidental local router advertisements, neighbor discovery behavior, or traffic exchanged inside a segment. NIST’s central lesson remains current: use an organized deployment plan, apply security controls with parity, minimize unnecessary transition mechanisms, update policies and tools, and train administrators before depending on IPv6 in production. ## DSE recommendation: choose an explicit state for every segment Classify each network as one of three states: managed IPv6 production, controlled pilot, or not authorized. “Unknown” should be a temporary finding with an owner and due date. Document who can assign prefixes, advertise routes, operate DHCPv6 or router advertisements, create tunnels, publish IPv6 DNS records, and approve firewall policy. If IPv6 is not authorized on a segment, define the supported method for suppressing it and continuously detect exceptions. Do not make broad operating-system changes without vendor review: some platforms and applications assume an IPv6 stack exists even when no routed IPv6 service is intended. The objective is a supported, tested state—not removal by an undocumented registry or interface change. ## DSE recommendation: discover the network that actually exists - Inventory IPv6 addresses, prefixes, routes, DNS AAAA records, router advertisements, DHCPv6 activity, multicast listeners, tunnels, and IPv6-capable security devices. - Compare switch, router, wireless, firewall, VPN, endpoint, hypervisor, and cloud observations. A single discovery source will miss some local or encapsulated paths. - Identify unmanaged devices advertising themselves as routers or configuration sources. - Confirm whether vulnerability scanners, EDR, network detection, SIEM parsing, and asset systems associate IPv4 and IPv6 observations with the same asset. - Record devices that support IPv6 operationally but lack equivalent logging, authentication, filtering, or software maintenance. ## DSE recommendation: require control parity For every authorized IPv4 policy, decide its IPv6 equivalent. Cover inbound and outbound filtering, inter-VLAN segmentation, management interfaces, VPN access, wireless isolation, DNS policy, egress controls, vulnerability scanning, denial-of-service protections, and logging. Avoid copying rules mechanically: IPv6 depends on specific control traffic, and indiscriminate blocking can break legitimate operation. Protect local network configuration. Use supported switch and wireless safeguards against unauthorized router advertisements and DHCPv6 services where available. Restrict infrastructure administration, authenticate routing relationships as supported, and define which devices may provide first-hop services. Review tunnels and translation mechanisms individually. Remove those without a current requirement. For approved mechanisms, document endpoints, owners, permitted traffic, monitoring, failure behavior, and how incident responders will inspect both the outer and inner protocols. ## DSE recommendation: test operations, not just connectivity A successful IPv6 ping does not prove production readiness. Test name resolution, authentication, application transactions, segmentation, firewall behavior, logging, vulnerability scanning, alerting, packet capture, failover, backup, remote support, and rollback. Validate path preference so an application does not unexpectedly select a less monitored route. Exercise an incident involving an IPv6 address that has no obvious IPv4 counterpart. Analysts should be able to identify the device, user or service, switch port or cloud interface, route, DNS history, policy decision, and containment method. Include IPv6 evidence in collection procedures and retention policies. Review the chosen state after operating-system upgrades, firewall replacements, cloud migrations, ISP changes, acquisitions, and new IoT or physical-security deployments. The safe outcome is not necessarily “IPv6 everywhere” or “IPv6 nowhere.” It is knowing where the protocol exists and proving that every permitted path is governed. ## Official references - [NIST SP 800-119: Guidelines for the Secure Deployment of IPv6](https://doi.org/10.6028/NIST.SP.800-119) - [NIST CSRC publication record for SP 800-119](https://csrc.nist.gov/pubs/sp/800/119/final) - [NIST: IPv6 Guide Provides Path to Secure Deployment](https://www.nist.gov/news-events/news/2011/01/ipv6-guide-provides-path-secure-deployment-next-generation-internet) ## Primary reference - Name: NIST SP 800-119: Guidelines for the Secure Deployment of IPv6 - Authority: Digital Object Identifier - URL: https://doi.org/10.6028/NIST.SP.800-119 - Source publication date: 2010-12-29 ## Citation and use Preferred citation: “Govern IPv6 even when the network is called IPv4-only,” DSE Security, https://update.dsesecurity.com/updates/govern-ipv6-on-ipv4-first-networks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern OAuth application consent before it becomes persistent access > OAuth consent can give an application continuing access to Microsoft 365 data without stealing a password. Govern grants, permissions, ownership, review, and revocation as an identity lifecycle. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-entra-oauth-application-consent-governance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-28T14:22:00+00:00 - Modified: 2026-07-28T14:22:00+00:00 - Last reviewed by DSE: 2026-07-28 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know OAuth consent can give an application continuing access to Microsoft 365 data without stealing a password. Govern grants, permissions, ownership, review, and revocation as an identity lifecycle. ## Potentially affected Microsoft Entra tenants, Microsoft 365 data, enterprise applications, service principals, app registrations, consent reviewers, users who can grant consent, and third-party SaaS integrations. ## DSE recommendation Inventory existing grants, restrict future user consent to an approved risk model, establish an administrator-consent workflow, assign application owners, review high-impact permissions, and rehearse illicit-consent response. ## Article ## Source fact: consent can outlast a sign-in Microsoft warns that consent phishing uses the legitimate Microsoft identity platform to persuade a person to authorize a malicious application. The application may receive delegated access to mail, files, contacts, calendars, or other resources without obtaining the user’s password. Application permissions can be broader because software acts as its own identity without an interactive user. A Microsoft-hosted prompt, a familiar application name, or a verified publisher provides context, but none proves that the requested permissions fit the business purpose. Microsoft also distinguishes consent-grant remediation from ordinary account recovery. Resetting a password or requiring multifactor authentication does not by itself remove an external application’s existing authorization. Changing the tenant’s user-consent setting governs future grants; it does not automatically revoke grants already issued. Microsoft’s current prevention and response guidance is available in [Protect against consent phishing](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/protect-against-consent-phishing). ## Build a governed application register Inventory enterprise applications, service principals, app registrations, delegated grants, and application-role assignments. For each approved application, record its application ID, publisher and tenant of origin, business purpose, service and technical owners, vendor contact, expected users, permissions, consent type, approving identity, credential expiration, data handled, connected systems, and next review date. Investigate ownerless, unused, highly privileged, tenant-wide, or unfamiliar applications first. A recognizable brand is not a substitute for reviewing the actual object and permissions. Classify which low-impact delegated permissions users may approve, which require administrator review, and which are prohibited except through a documented exception. If user consent is restricted or disabled, provide an administrator-consent request workflow so legitimate demand enters a visible queue. Workflow reviewers still need an appropriate directory role; being named a reviewer does not grant approval authority. ## DSE recommendation: approve and respond with evidence - Require a named business owner to explain why every requested permission is necessary and why a narrower permission or smaller user scope will not work. - Compare the publisher, redirect domains, privacy statement, contract, data location, and deletion terms with the vendor being evaluated. - Use least-privileged approvers, restrict user assignment where supported, and record the decision, expiration, conditions, and rollback owner. - Review existing grants on a risk-based schedule, prioritizing application permissions, broad admin consent, sensitive data, expiring credentials, dormant use, and missing owners. - For suspected illicit consent, preserve application and service-principal IDs, grant details, consent and sign-in events, and affected identities before containment. - Disable the suspicious application where appropriate, revoke the relevant grant or app-role assignment, scope accessible data and activity, review related account changes, and monitor for recurrence. Test revocation against an approved application before an incident so responders know which object to change and how service impact will be handled. Keep password reset, session revocation, authentication-method review, and mailbox or file investigation in the response when account compromise is also possible, but do not mistake those steps for removal of the application grant. ## Primary reference - Name: Microsoft Learn: Protect against consent phishing - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/protect-against-consent-phishing - Source publication date: 2025-01-08 ## Citation and use Preferred citation: “Govern OAuth application consent before it becomes persistent access,” DSE Security, https://update.dsesecurity.com/updates/microsoft-entra-oauth-application-consent-governance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern SharePoint version history as recovery capacity with a storage cost > SharePoint and OneDrive version limits can be set at organization, site, library, and account levels, but new defaults do not clean up old versions by themselves. Report first, classify recovery needs, approve exceptions, then trim deliberately. - Canonical URL: https://update.dsesecurity.com/updates/sharepoint-version-history-storage-governance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:13:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know SharePoint and OneDrive version limits can be set at organization, site, library, and account levels, but new defaults do not clean up old versions by themselves. Report first, classify recovery needs, approve exceptions, then trim deliberately. ## Potentially affected SharePoint Online document libraries, Microsoft Teams-connected sites, OneDrive accounts, site and library owners, storage quotas, version recovery, recycle bins, retention policies, records, legal holds, and audit processes. ## DSE recommendation Inventory effective version settings and inheritance, generate site storage reports, classify libraries by recovery and retention need, pilot automatic or manual limits, schedule separately approved trim jobs, and verify both recoverability and storage results. ## Article ## Source facts: settings, inheritance, and trimming are separate controls Microsoft’s [version-history limit overview](https://learn.microsoft.com/en-us/sharepoint/document-library-version-history-limits) says limits govern how versions are stored in SharePoint document libraries and OneDrive accounts. Administrators can establish defaults at the organization level, then apply or override settings at the site, library, or OneDrive account level according to the available control and ownership model. Organization defaults apply to new libraries on sites that do not have a site-level setting. A site can break inheritance for its new libraries, and an individual library can have its own limit. Changing a default is not the same operation as deleting versions that already exist. Microsoft provides version-storage reports to analyze current use and the modeled effect of a limit, and separate trim jobs for existing versions. Microsoft documents two limit approaches. Automatic limits are designed to balance recovery usefulness with storage optimization. Manual limits can combine a maximum number of major versions with an expiration period, or use a major-version count without expiration. The administration interface does not allow fewer than 100 major versions or less than 30 days; although APIs may permit smaller values, Microsoft does not recommend them because ordinary user activity can produce inadvertent data loss. Other Microsoft 365 controls affect what happens. Versions deleted by a user move to the site recycle bin for its applicable recovery period. Versions subject to a retention policy or eDiscovery hold are not governed in the same way by ordinary library limits; a trim job that encounters retained or held content stamps expiration behavior rather than simply deleting protected material. Records have additional deletion restrictions. Audit events are available for configuration changes, reports, trim jobs, and version deletion activity. ## DSE recommendation: classify before limiting and report before trimming Do not select one number by tenant size alone. Classify sites and libraries by how people work and what recovery they need. A high-change design library, accounting close library, records repository, collaborative Teams site, personal OneDrive, and low-change reference library can justify different policies. - Map effective policy. Inventory organization defaults, site overrides, library overrides, OneDrive settings, ownership, inheritance, retention, records, holds, storage quotas, and current version consumption. Include Teams-connected sites that users may not recognize as SharePoint. - Define recovery scenarios. Ask how far back users and support must recover, how frequently files change, how large they are, whether coauthoring or automated processes generate rapid versions, and which restores have actually been requested. - Generate reports. Use Microsoft’s reporting workflow on representative sites before changing limits or scheduling deletion. Preserve the report date, scope, assumptions, and modeled storage effect with the change record. - Choose a policy tier. Use automatic limits where their recovery-and-storage model fits. Use manual count or age boundaries only when the organization can explain and periodically review them. Record each exception with an owner and review date. - Pilot future behavior. Apply settings first to selected sites or libraries, confirm inheritance and stamped expiration behavior, create and recover test versions, and observe storage over a meaningful period. - Approve trimming separately. Treat a trim job as a data-deletion change. Confirm retention and hold interactions, scope, expected deletion, business approval, timing, monitoring, and the supported recovery boundary before queuing it. After implementation, verify effective settings on new and existing libraries separately. Confirm that owners cannot silently create ungoverned exceptions, that reports and jobs complete, that ordinary version recovery still works for the approved window, and that storage changes match the forecast. Watch audit events and help-desk requests for unexpected impact. Version history supports rapid recovery from ordinary edits, but it is not a complete backup, retention, records, or legal-hold strategy. Keep those services distinct in policy and user communication. The useful outcome is enough recoverable history for each workload, visible storage consumption, controlled exceptions, and no surprise deletion disguised as routine cleanup. ## Official references - Microsoft Learn, [Overview of version history limits for document libraries and OneDrive](https://learn.microsoft.com/en-us/sharepoint/document-library-version-history-limits), October 3, 2024. - Microsoft Learn, [Set version limits for a site](https://learn.microsoft.com/en-us/sharepoint/site-version-limits). ## Primary reference - Name: Microsoft Learn: Overview of version history limits for document libraries and OneDrive - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/sharepoint/document-library-version-history-limits - Source publication date: 2024-10-03 ## Citation and use Preferred citation: “Govern SharePoint version history as recovery capacity with a storage cost,” DSE Security, https://update.dsesecurity.com/updates/sharepoint-version-history-storage-governance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern storage as infrastructure—not just capacity > Block, file, object, virtualized, and cloud storage bring distinct control and recovery paths. Inventory data flows, management planes, identities, isolation, protection, restoration, and encryption as one system. - Canonical URL: https://update.dsesecurity.com/updates/storage-infrastructure-security-governance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:01+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Block, file, object, virtualized, and cloud storage bring distinct control and recovery paths. Inventory data flows, management planes, identities, isolation, protection, restoration, and encryption as one system. ## Potentially affected Organizations using direct-attached, networked, virtualized, hyper-converged, software-defined, or cloud storage for production data and backups. ## DSE recommendation Create a storage control map covering data and management paths, ownership, authorization, configuration, isolation, protection copies, restoration assurance, encryption dependencies, monitoring, and recovery. ## Article Bottom line: storage is a managed system with identities, networks, controllers, software, replication, protection copies, keys, and recovery behavior. Available capacity and successful writes do not prove that access, isolation, change control, or restoration are safe. ## Source fact: what NIST covers [NIST SP 800-209](https://csrc.nist.gov/pubs/sp/800/209/final) describes the evolution of storage from direct-attached block, file, and object services toward networked, virtualized, software-defined, hyper-converged, and cloud-based models. NIST links increasing architectural and management complexity to configuration-error and security risk. Its recommendations span common infrastructure disciplines—physical security, authentication and authorization, change and configuration control, incident response, and recovery—plus storage-specific concerns such as data protection, isolation, restoration assurance, and encryption. The source supports assessing storage as more than media. Management and recovery paths are part of the security design. ## What the source does not establish The publication does not certify a storage product, cloud tier, snapshot, replication design, or backup. Encryption does not prove separation from an attacker who controls the relevant identity or key service. Replication can copy unwanted change, and a snapshot is not automatically an independent, retained, or restorable copy. Actual controls vary by protocol, topology, service model, license, firmware and software version, tenancy, key ownership, and operational responsibility. ## Applicability questions - Which applications and data use each block, file, or object service, and what are their recovery objectives? - Which identities can administer, read, write, delete, snapshot, replicate, restore, or change retention and keys? - What data and management networks, APIs, consoles, and support channels reach the platform? - Which failures, deletions, corruption, or compromises can propagate to replicas and protection copies? - What independent evidence proves a useful restoration at the required scale? ## DSE recommendation: build a storage control map The following steps are DSE recommendations based on the cited source. - Inventory storage services, physical and logical components, data classes, applications, owners, protocols, management paths, dependencies, protection methods, and support status. - Separate data access, storage administration, backup administration, key administration, and audit access where risk justifies it. Review inherited and automation permissions. - Baseline security-relevant configuration and monitor changes to access, exports, shares, buckets, replication, retention, immutability, snapshots, deletion, and encryption. - Map failure domains. Record which credentials, control planes, regions, arrays, networks, directories, and key services are shared between production and recovery copies. - Test restoration of representative data and complete services. Include identity, permissions, application consistency, key availability, name resolution, capacity, and elapsed time. - Prepare evidence-preserving incident actions that do not erase the only useful copy or spread a destructive change. ## Verification and evidence Retain the inventory, architecture and failure-domain map, access reviews, configuration baseline and change records, key-dependency record, protection and retention configuration, monitoring events, restore test results, and exception register. A restore test should identify the exact source copy, target, date, data and application validation, and unresolved gaps. ## Official references - [NIST SP 800-209 — Security Guidelines for Storage Infrastructure](https://csrc.nist.gov/pubs/sp/800/209/final) — National Institute of Standards and Technology; finalized October 26, 2020 ## Primary reference - Name: NIST SP 800-209 — Security Guidelines for Storage Infrastructure - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/209/final - Source publication date: 2020-10-26 ## Citation and use Preferred citation: “Govern storage as infrastructure—not just capacity,” DSE Security, https://update.dsesecurity.com/updates/storage-infrastructure-security-governance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern unescorted nuclear-facility access through an authorization program > Use 10 CFR 73.56 - Nuclear power plant personnel access authorization to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/govern-unescorted-nuclear-facility-access-through-an-authorization-program/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:44+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.56 - Nuclear power plant personnel access authorization to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.56 - Nuclear power plant personnel access authorization ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Govern unescorted nuclear-facility access through an authorization program. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.56 – Nuclear power plant personnel access authorization](https://www.ecfr.gov/current/title-10/section-73.56) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, individuals who are subject to an access authorization program under this section must at a minimum, report any concerns arising from behavioral observation, including, but not limited to, concerns related to any questionable behavior patterns or activities of others to the reviewing official, his or her supervisor, or other management personnel designated in their site procedures. The research record locates this support at 10 CFR 73.56(f)(3) (eCFR anchor p-73.56(f)(3)). - Under 10 CFR 73, any individual who is applying for unescorted access or unescorted access authorization must disclose the personal history information that is required by the licensee’s or applicant’s access authorization program, including any information that may be necessary for the reviewing official to make a determination of the individual’s trustworthiness and reliability. The research record locates this support at 10 CFR 73.56(d)(2)(i) (eCFR anchor p-73.56(d)(2)(i)). Only the traced statements above are asserted as source facts. Apply the review to credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces after confirming that the source and deployed context match. ## What the source does not establish NRC regulation for covered access programs; screening, fitness-for-duty, appeals, records, privacy, insider mitigation, and license conditions require complete qualified review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.56(f)(3) (eCFR anchor p-73.56(f)(3)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.56(d)(2)(i) (eCFR anchor p-73.56(d)(2)(i)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to 10 CFR 73.56(f)(3) (eCFR anchor p-73.56(f)(3)); 10 CFR 73.56(d)(2)(i) (eCFR anchor p-73.56(d)(2)(i)) and to observable material such as approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [10 CFR 73.56 – Nuclear power plant personnel access authorization](https://www.ecfr.gov/current/title-10/section-73.56) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.56 - Nuclear power plant personnel access authorization - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.56 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Govern unescorted nuclear-facility access through an authorization program,” DSE Security, https://update.dsesecurity.com/updates/govern-unescorted-nuclear-facility-access-through-an-authorization-program/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern Windows DNS record creation, modification, and deletion as production changes > Use Manage DNS resource records using DNS server on Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/govern-windows-dns-record-creation-modification-and-deletion-as-production-changes/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:29+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Manage DNS resource records using DNS server on Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Manage DNS resource records using DNS server on Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Govern Windows DNS record creation, modification, and deletion as production changes. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Manage DNS resource records using DNS server on Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-resource-records) from Microsoft supports the following bounded statements: - Windows Server supports creating, modifying, and deleting DNS resource records through DNS Manager and PowerShell. The research record locates this support at Article introduction. - The documented record data includes record type, owner name, host address, and other record-specific information. The research record locates this support at Article introduction. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The task procedures do not prove that a requested record, TTL, owner, or target is correct for an application or delegation. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Article introduction, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Article introduction, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations Article introduction; Article introduction adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Manage DNS resource records using DNS server on Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-resource-records) — Microsoft ## Primary reference - Name: Manage DNS resource records using DNS server on Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/manage-resource-records - Source publication date: 2023-06-15 ## Citation and use Preferred citation: “Govern Windows DNS record creation, modification, and deletion as production changes,” DSE Security, https://update.dsesecurity.com/updates/govern-windows-dns-record-creation-modification-and-deletion-as-production-changes/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Govern Windows DNS scavenging as a deletion change, not routine cleanup > Windows DNS aging can identify stale dynamic records, and scavenging can delete them. Inventory timestamps and registration owners, align intervals with DHCP and client behavior, restrict scavenging servers, pilot one zone, and prove recovery before enabling automation. - Canonical URL: https://update.dsesecurity.com/updates/windows-dns-scavenging-deletion-change-governance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-11T10:43:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Windows DNS aging can identify stale dynamic records, and scavenging can delete them. Inventory timestamps and registration owners, align intervals with DHCP and client behavior, restrict scavenging servers, pilot one zone, and prove recovery before enabling automation. ## Potentially affected Windows Server DNS primary and Active Directory-integrated zones; dynamic and static records; DNS clients, DHCP servers, domain controllers, clusters, appliances, monitoring, applications, replication, and name-resolution recovery procedures. ## DSE recommendation Inventory eligible records and timestamps, map every registration path, calculate no-refresh and refresh intervals from real client and lease behavior, designate scavenging servers, pilot a low-risk zone, monitor deletions, and keep tested DNS recovery evidence. ## Article ## Source facts: scavenging is an automated delete decision Microsoft’s [Windows DNS aging and scavenging guidance](https://learn.microsoft.com/en-us/windows-server/networking/dns/aging-scavenging) describes aging as the timestamp-based process used to identify records that can become stale and scavenging as the process that removes eligible stale records. Stale records can consume storage, lengthen zone transfers, degrade DNS performance, and return outdated answers. The cleanup mechanism is disabled by default because an unsafe configuration can delete records that clients still need. Aging and scavenging must be enabled at both the DNS server and the zone. Records also need an eligible timestamp. Dynamically registered records normally receive timestamps, while records created manually or loaded from a text zone file receive a timestamp of zero and are not scavenged unless an administrator changes that behavior. Microsoft warns that using dnscmd /ageallrecords can timestamp all records in a zone, including static records that should not be removed. The no-refresh interval suppresses timestamp-only refresh writes while still allowing a substantive update, such as an address change. After that interval, the refresh interval allows a client or another service to renew the timestamp. Microsoft documents seven days as the default for each interval. A record becomes eligible for deletion only after its timestamp plus the zone’s no-refresh and refresh intervals is earlier than current server time and a scavenging cycle examines it. Automatic scavenging also has a server period, seven days by default, with a documented minimum of one hour. Administrators can restrict an Active Directory-integrated zone to designated scavenging servers. The zone’s start-scavenging time is recalculated after events such as enabling dynamic updates, changing the scavenging setting, loading the zone when the DNS service starts, or resuming a paused zone, so deletion timing is not simply the interval displayed in one console field. ## DSE recommendation: prove every registration path before enabling deletion Treat the first scavenging deployment as a controlled service change. DNS is a shared dependency; a small record set can represent domain controllers, clusters, applications, security devices, or externally configured systems whose refresh behavior differs from ordinary Windows clients. - Inventory zones and records. Export each zone’s type, replication scope, dynamic-update mode, aging settings, scavenging servers, timestamps, static records, delegations, critical service records, record owner, and the system expected to register or remove it. - Map the writers. Identify records maintained by Windows clients, DHCP, clusters, domain controllers, appliances, scripts, IP-address-management tools, and administrators. Confirm credentials and ownership for DHCP dynamic updates and distinguish a valid long-lived record from an abandoned record. - Calculate from observed behavior. Compare DHCP lease duration, client DNS registration frequency, offline and roaming periods, remote-access patterns, maintenance windows, and appliance refresh behavior with the combined no-refresh and refresh intervals. Do not shorten defaults merely to make a cleanup test finish quickly. - Protect static intent. Review zero-timestamp records and document why each is static. Do not bulk-age an established production zone until every resulting deletion candidate has an accountable owner and an approved recovery path. - Pilot with containment. Select a low-risk zone or representative controlled record set, designate the intended scavenging server, capture the start-scavenging time, monitor registrations and timestamps through a complete interval, and review the expected candidate list before automatic deletion. - Monitor and recover. Review DNS Server events, deletion counts, resolution tests, AD replication where applicable, unexpected re-registration, and service incidents. Keep current zone and directory recovery procedures, escalation ownership, and a rapid way to restore an incorrectly deleted critical record. Measure stale-record reduction alongside mistaken deletions, failed refreshes, duplicate registrations, unresolved owners, and DNS incidents. Reassess after DHCP changes, site or VPN redesign, cluster migrations, new appliances, directory changes, or altered lease durations. The safe outcome is not the smallest zone; it is a zone whose dynamic records age predictably while intentional records remain available and owned. ## Official references - Microsoft Learn, [DNS aging and scavenging](https://learn.microsoft.com/en-us/windows-server/networking/dns/aging-scavenging), March 24, 2025. - Microsoft Learn, [DNS scavenging setup](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/dns-scavenging-setup). - Microsoft Learn, [Troubleshoot DNS scavenging issues](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/troubleshoot-dns-scavenging-issues), February 12, 2026. ## Primary reference - Name: Microsoft Learn: DNS aging and scavenging - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/aging-scavenging - Source publication date: 2025-03-24 ## Citation and use Preferred citation: “Govern Windows DNS scavenging as a deletion change, not routine cleanup,” DSE Security, https://update.dsesecurity.com/updates/windows-dns-scavenging-deletion-change-governance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Grant-ADAuthenticationPolicySiloAccess: grant adauthentication policy silo access with before-and-after evidence > Use Grant-ADAuthenticationPolicySiloAccess to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/grant-adauthenticationpolicysiloaccess-grant-adauthentication-policy-silo-access-with-before-and/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:42+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Grant-ADAuthenticationPolicySiloAccess to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Grant-ADAuthenticationPolicySiloAccess ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Grant-ADAuthenticationPolicySiloAccess: grant adauthentication policy silo access with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Grant-ADAuthenticationPolicySiloAccess](https://learn.microsoft.com/en-us/powershell/module/activedirectory/grant-adauthenticationpolicysiloaccess?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Grant-ADAuthenticationPolicySiloAccess cmdlet grants permission to an account to join an authentication policy silo in Active Directory® Domain Services.” The research record locates this support at DESCRIPTION. - At Example 1: Grant access to an authentication policy silo to a user account, Microsoft states: “This command grants access to the authentication policy silo named AuthenticationPolicySilo01 to the user account named User01.” The research record locates this support at Example 1: Grant access to an authentication policy silo to a user account. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Grant access to an authentication policy silo to a user account, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; Example 1: Grant access to an authentication policy silo to a user account through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-164 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Grant-ADAuthenticationPolicySiloAccess](https://learn.microsoft.com/en-us/powershell/module/activedirectory/grant-adauthenticationpolicysiloaccess?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Grant-ADAuthenticationPolicySiloAccess - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/grant-adauthenticationpolicysiloaccess?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Grant-ADAuthenticationPolicySiloAccess: grant adauthentication policy silo access with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/grant-adauthenticationpolicysiloaccess-grant-adauthentication-policy-silo-access-with-before-and/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Ground the complete camera path before claiming surge protection > A surge protector is only one part of a camera installation. Cable routing, shielding, grounding, PoE equipment, and building practices determine the real protection path. - Canonical URL: https://update.dsesecurity.com/updates/ground-the-complete-camera-path-before-claiming-surge-protection/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:36:00+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Networks & Infrastructure, Video Surveillance - Reading time: 2 minutes ## What you need to know A surge protector is only one part of a camera installation. Cable routing, shielding, grounding, PoE equipment, and building practices determine the real protection path. ## Potentially affected Outdoor, rooftop, pole, campus, industrial, and long-cable camera installations exposed to lightning-related or equipment-generated electrical transients. ## DSE recommendation Have qualified personnel document the end-to-end bonding, grounding, routing, and surge-protection design, then inspect it against product instructions and applicable electrical rules. ## Article Bottom line: adding a surge-protection device beside a camera does not establish that transient energy has a safe path. Protection depends on the coordinated cable, shield, ground, switch or midspan, building entry, and installation environment. ## Source fact: routing and grounding are part of the surge design Axis’s [Power surges](https://whitepapers.axis.com/en-us/power-surges) paper describes transient surges that can originate from lightning or electrical machinery. Its installation guidance recommends shielded twisted-pair cabling through the path, properly grounded network switches or midspans, avoiding long parallel runs with power cables, and using appropriate surge-protection devices. The recommendations form a system. An unbonded shield, incorrect building-entry transition, long induced run, or poorly grounded PoE source can undermine a correctly purchased protective component. ## Source boundary and applicability The paper is Axis guidance, not an electrical design for a specific site and not a guarantee against lightning damage. Grounding, bonding, conductor separation, outdoor cable, listed devices, inspection, and lightning-protection requirements vary by jurisdiction, building, power system, and installation. Qualified electrical and communications professionals and the authority having jurisdiction should determine applicable requirements. ## Applicability questions - Does the cable leave a building, cross structures, run outdoors, or reach a pole or rooftop? - Where are shield, equipment ground, bonding network, and building entrance points connected? - Is the PoE switch, injector, or midspan grounded as its manufacturer requires? - Are data cables routed near feeders, motors, drives, generators, or other transient sources? - Which components and downstream equipment does each protective device cover? ## DSE recommendation: review the path as one electrical system The following steps are DSE recommendations based on the cited source. Create a route drawing from camera to endpoint showing cable type, outdoor and indoor transitions, protectors, grounds, bonds, PoE source, patch points, and nearby power equipment. Compare every component with its installation instructions and the applicable electrical, communications, and lightning-protection requirements. Correct work only through qualified personnel and approved outage/change procedures. Inspect for unapproved cable substitutions, disconnected drain wires, corrosion, loose bonds, water entry, protector end-of-life indications, and changes in adjacent power routing. Treat repeated camera or port failures as a reason for engineering review, not a cycle of equipment replacement. Where fiber can meet the operational design, ask the qualified designer whether electrical isolation is appropriate for a building-to-building or other exposed segment; do not assume it removes every power or grounding obligation. ## Verification and evidence Retain stamped or approved drawings where required, cable and protector schedules, product instructions, photographs of terminations, ground/bond inspection results, qualified-person sign-off, test records allowed by the design, change tickets, and incident history. Never improvise resistance or surge testing on connected production equipment. ## Official references - [Power surges](https://whitepapers.axis.com/en-us/power-surges) – Axis Communications ## Primary reference - Name: Power surges - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/power-surges - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Ground the complete camera path before claiming surge protection,” DSE Security, https://update.dsesecurity.com/updates/ground-the-complete-camera-path-before-claiming-surge-protection/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Group recurring FSRM reports around one approved collection scope > How should a recurring FSRM report task be scoped and its schedule maintained? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-088-group-recurring-fsrm-reports-around-one-approved-collection-scope/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:43+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How should a recurring FSRM report task be scoped and its schedule maintained? ## Potentially affected Administrators scheduling File Server Resource Manager storage reports. ## DSE recommendation Write a small task register containing each schedule, selected reports, report parameters, destination, and owner. ## Article ## Source facts An FSRM report task defines the reports, parameters, storage paths, frequency, and output formats for scheduled collection. Microsoft recommends putting multiple reports on the same schedule so collection occurs once. The bulk report-management action can change included reports and their parameters; schedules and delivery addresses must be changed within individual tasks. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/fsrm/schedule-set-of-reports). ## Applicability Identify the storage question, recurring collection window, covered paths, and recipients. Separate reports that share a collection scope from requests that need different delivery or scheduling decisions. ## DSE recommendation Write a small task register containing each schedule, selected reports, report parameters, destination, and owner. Ask the storage owner to approve the collection window. When changing several tasks, explicitly review their individual schedules and addresses rather than assuming the bulk edit covered them. ## Verification Inspect the first scheduled run and compare the produced reports with the approved register. Confirm the timestamp, included paths, output formats, and recipient list. Record processing errors or missing reports, and revisit the schedule if the measured collection window conflicts with other agreed operations. ## Official references [Microsoft Learn: Schedule a Set of Reports](https://learn.microsoft.com/en-us/windows-server/storage/fsrm/schedule-set-of-reports). Source reviewed September 8, 2026. ## Primary reference - Name: Schedule a Set of Reports - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/fsrm/schedule-set-of-reports - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Group recurring FSRM reports around one approved collection scope,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-088-group-recurring-fsrm-reports-around-one-approved-collection-scope/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Harden Active Directory Certificate Services before templates become privilege paths > AD CS can issue credentials used for authentication, signing, and encryption. Treat certification authorities, templates, enrollment rights, web endpoints, keys, revocation, and recovery as high-value identity infrastructure. - Canonical URL: https://update.dsesecurity.com/updates/harden-active-directory-certificate-services-and-templates/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:59:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know AD CS can issue credentials used for authentication, signing, and encryption. Treat certification authorities, templates, enrollment rights, web endpoints, keys, revocation, and recovery as high-value identity infrastructure. ## Potentially affected Enterprise and standalone certification authorities, root and issuing CAs, certificate templates, enrollment and autoenrollment, CA and template ACLs, web enrollment and NDES, service accounts, private keys and HSMs, CRL and AIA publication, auditing, backup, and disaster recovery. ## DSE recommendation Inventory the PKI and every published template, identify authentication-capable and high-impact paths, restrict administration and enrollment, remove unsafe web or relay exposure, protect keys, validate revocation and audit, test backup and recovery, and stage every change with certificate-impact analysis. ## Article ## Source facts: AD CS is identity and cryptographic infrastructure Microsoft’s [AD CS PKI design guidance](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/pki-design-considerations) calls for deliberate decisions about CA hierarchy, request approval, cryptography, names, validity, database, revocation, and Authority Information Access and Certificate Revocation List distribution points. It describes hardware security modules as a way to provide a protected hardware store for CA keys where the design calls for one. Microsoft’s [certificate-template management documentation](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/manage-certificate-templates) explains that templates are stored in Active Directory, can be published to enterprise CAs, and include permissions and configuration that control enrollment and certificate purpose. Changes and deletion can affect all enterprise CAs or future issuance, which makes casual cleanup dangerous. CISA’s [joint guidance on living-off-the-land techniques](https://www.cisa.gov/sites/default/files/2025-03/Joint-Guidance-Identifying-and-Mitigating-LOTL508.pdf) identifies AD CS among high-value Microsoft identity infrastructure that should receive appropriate hardening. None of these sources makes one checklist safe for every PKI. Certificate use, application dependencies, offline roots, cryptographic policy, legal requirements, and supported Windows versions vary; qualified PKI expertise is required. ## DSE recommendation: treat issuance paths like privileged code Begin with a read-only PKI map: every CA and hierarchy relationship, operating system and role service, database and key location, HSM, service account, administrative group, enrollment endpoint, template and publishing CA, CRL and AIA URL, OCSP responder, trust distribution, backup, recovery owner, and dependent application. Protect the inventory because it reveals identity infrastructure. - Identify privilege-bearing templates. Review purposes and enhanced key usages, subject and subject-alternative-name construction, requester-supplied values, manager approval, authorized signatures, enrollment and autoenrollment permissions, private-key export, validity, renewal, and which CAs publish the template. Prioritize certificates usable for authentication or powerful signing. - Restrict control planes. Limit who can administer CAs, templates, configuration, service accounts, HSMs, backups, and enrollment agents. Review inherited and delegated ACLs. Separate routine certificate operations from domain-wide administration where the supported design permits. - Reduce exposed services. Inventory web enrollment, certificate enrollment web services, policy web services, NDES, RPC, SMB, HTTP, and relay-relevant paths. Remove services not required; for required endpoints, apply current Microsoft mitigations, channel protections, segmentation, and monitoring without breaking enrollment clients. - Protect signing keys and availability. Verify key protection, backup custody, offline components, database backup, configuration, CA certificates, key recovery where applicable, power, time, name resolution, and revocation publication. Test restoration in an isolated authorized environment rather than assuming a file copy is sufficient. - Monitor issuance and change. Enable supported auditing, centralize protected logs, and review template publication, ACL changes, CA configuration, enrollment-agent activity, unusual requesters, unexpected subject names, failed issuance, revocation, and service installation. Correlate with directory and endpoint telemetry. - Change with certificate impact analysis. Before disabling a template, service, algorithm, endpoint, or CA, identify issued certificates, renewal behavior, autoenrollment, applications, devices, and outage consequences. Pilot replacements, preserve rollback where safe, and verify revocation and trust paths from representative clients. Do not publish a copied template merely because it has a safer-looking name; its effective permissions and fields matter. Do not assume an offline root protects an issuing CA or template with excessive authority. Conversely, do not revoke or remove certificates in bulk without understanding authentication, encryption, signature validation, and recovery impact. The assessment should produce ranked issuance paths, owners, approved remediation, compensating controls, and retest evidence. AD CS hardening is complete only when the organization can explain who may cause which certificate to be issued, how that action is observed, and how trust and revocation continue through failure and recovery. Stop a change if representative clients cannot build the chain, locate revocation information, renew before expiry, or use the certificate for its approved purpose. Preserve the prior template or endpoint only when the rollback is safe and authorized. A security improvement that silently breaks authentication, decryption, or signature validation needs controlled redesign—not an undocumented emergency exception. ## Official references - Microsoft, [PKI design considerations using Active Directory Certificate Services](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/pki-design-considerations). - Microsoft, [Manage certificate templates in Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/manage-certificate-templates). - Cybersecurity and Infrastructure Security Agency, [Identifying and Mitigating Living Off the Land Techniques](https://www.cisa.gov/sites/default/files/2025-03/Joint-Guidance-Identifying-and-Mitigating-LOTL508.pdf). ## Primary reference - Name: Microsoft Learn: PKI design considerations using Active Directory Certificate Services - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/pki-design-considerations - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Harden Active Directory Certificate Services before templates become privilege paths,” DSE Security, https://update.dsesecurity.com/updates/harden-active-directory-certificate-services-and-templates/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Harden network infrastructure with isolated management and verifiable configuration > Current joint guidance prioritizes centralized intended configuration, isolated management, least privilege, secure protocols, protected telemetry, integrity checks, and lifecycle maintenance. - Canonical URL: https://update.dsesecurity.com/updates/network-infrastructure-isolated-management-hardening/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:10+00:00 - Modified: 2026-07-19T21:27:10+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Current joint guidance prioritizes centralized intended configuration, isolated management, least privilege, secure protocols, protected telemetry, integrity checks, and lifecycle maintenance. ## Potentially affected Organizations operating routers, switches, firewalls, VPN gateways, network controllers, AAA services, management networks, or other on-premises enterprise network equipment. ## DSE recommendation Inventory devices and listeners, centralize configuration, isolate management, secure administrator access, remove obsolete services, protect logs, and validate patch and integrity processes. ## Article Network devices control trust boundaries and administrative paths. When intended configuration exists only on the device, management is reachable from production or the internet, and logs disappear with the appliance, defenders have little independent evidence of change or compromise. ## Visibility and hardening priorities Source fact: CISA, NSA, FBI, and international partners produced this guidance for communications-infrastructure defenders and state that it may also apply to organizations with on-premises enterprise equipment. They recommend centrally storing, tracking, and auditing configurations instead of treating each device as the sole trusted source of its intended state. Source fact: The publication recommends isolated out-of-band management where feasible, no internet-based device administration, default-deny access control, segmentation, secure centralized authentication, authorization, and accounting, and phishing-resistant multifactor authentication for administrative access. It also recommends centralized protected logging, network-flow visibility, configuration-change alerting, and off-device or off-site copies. Source fact: Unnecessary, unused, exploitable, or plaintext protocols should be disabled. The agencies also call for current inventories, end-of-life monitoring, software-image integrity validation, controlled configuration, and routine and emergency patch management with testing. ## Establish an intended and observable state DSE recommendation: inventory devices, models, serials, operating software, firmware, roles, locations, owners, configurations, exposed listeners, management paths, accounts, protocols, dependencies, licenses, support, and end-of-life dates. Identify equipment or software that cannot meet required controls and assign a treatment decision. - Store intended configurations in a controlled central location and compare devices against them on a defined schedule. - Isolate management from user and production traffic and prevent unnecessary lateral device-to-device administration. - Use centralized named administration, least privilege, strong authentication, protected AAA records, and controlled emergency accounts. - Disable unneeded discovery, web, file-transfer, remote-shell, and management services; use secure versions supported by the vendor. - Centralize device, authentication, configuration, and flow telemetry and alert on out-of-process changes or stopped logging. - Verify software images using authenticated vendor information and manage routine and emergency changes with tested rollback. ## Validate from the outside DSE recommendation: scan approved network boundaries and management zones to confirm actual listeners and exposure. Test administrative access, configuration backup and restore, AAA outage, log delivery, alerting, emergency access, software upgrade, and recovery. Protect exported configurations because they may contain sensitive addresses, credentials, or security design. ## Applicability and limits The guidance’s threat context and some technical examples are tailored to telecommunications and late-2024 observations. Apply protocol and cryptographic details only when supported by current vendor documentation and interoperability testing. Legacy and OT systems may require compensating isolation and a planned lifecycle decision rather than an unsafe configuration change. ## Official reference [Enhanced Visibility and Hardening Guidance for Communications Infrastructure](https://www.cisa.gov/resources-tools/resources/enhanced-visibility-and-hardening-guidance-communications-infrastructure) — joint network-device monitoring and hardening practices. ## Primary reference - Name: CISA and partners: Enhanced Visibility and Hardening Guidance for Communications Infrastructure - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/resources-tools/resources/enhanced-visibility-and-hardening-guidance-communications-infrastructure - Source publication date: 2024-12-04 ## Citation and use Preferred citation: “Harden network infrastructure with isolated management and verifiable configuration,” DSE Security, https://update.dsesecurity.com/updates/network-infrastructure-isolated-management-hardening/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Honor HSTS only after a valid HTTPS response establishes policy > Use RFC 6797 — HTTP Strict Transport Security (HSTS) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/honor-hsts-only-after-a-valid-https-response-establishes-policy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:53+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6797 — HTTP Strict Transport Security (HSTS) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6797 — HTTP Strict Transport Security (HSTS) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Honor HSTS only after a valid HTTPS response establishes policy. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6797 — HTTP Strict Transport Security (HSTS)](https://www.rfc-editor.org/rfc/rfc6797.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A user agent establishes or updates dynamic HSTS state only from a valid Strict-Transport-Security field received over error-free secure transport and ignores the field over insecure HTTP. The research record locates this support at Sections 7.1 (HTTP-over-Secure-Transport Request Type) and 8.1 (Strict-Transport-Security Response Header Field Processing). - Before loading HTTP for a known HSTS name, the user agent changes the scheme to HTTPS, maps explicit port 80 to 443, and preserves any other explicit port. The research record locates this support at Section 8.3 (URI Loading and Port Mapping). - A connection to a known HSTS host must terminate on any secure-transport error, including certificate validation or server-identity failure. The research record locates this support at Section 8.4 (Errors in Secure Transport Establishment). Only the traced statements above are asserted as source facts. Apply the review to clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Sections 7.1 (HTTP-over-Secure-Transport Request Type) and 8.1 (Strict-Transport-Security Response Header Field Processing), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 8.3 (URI Loading and Port Mapping), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 8.4 (Errors in Secure Transport Establishment), which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include DNS, certificates, identity providers, time, content delivery, network paths, and application ownership, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations Sections 7.1 (HTTP-over-Secure-Transport Request Type) and 8.1 (Strict-Transport-Security Response Header Field Processing); Section 8.3 (URI Loading and Port Mapping); Section 8.4 (Errors in Secure Transport Establishment) adjacent to the sanitized artifacts used for comparison. Prefer request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 6797 — HTTP Strict Transport Security (HSTS)](https://www.rfc-editor.org/rfc/rfc6797.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6797 — HTTP Strict Transport Security (HSTS) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6797.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Honor HSTS only after a valid HTTPS response establishes policy,” DSE Security, https://update.dsesecurity.com/updates/honor-hsts-only-after-a-valid-https-response-establishes-policy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # How DSE Updates researches, reviews, and maintains public guidance > The DSE Updates editorial method favors exact primary sources, bounded claims, visible review metadata, applicability checks, and clear separation between source facts and DSE recommendations. This article defines the publication standard readers should expect. - Canonical URL: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:09+00:00 - Modified: 2026-07-19T19:03:09+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Explainer - DSE priority: Information - Topics: DSE World - Reading time: 3 minutes ## What you need to know The DSE Updates editorial method favors exact primary sources, bounded claims, visible review metadata, applicability checks, and clear separation between source facts and DSE recommendations. This article defines the publication standard readers should expect. ## Potentially affected Readers, customers, DSE reviewers, and contributors who use or prepare public DSE Updates content. ## DSE recommendation Check the source, review date, affected audience, requested action, and environment-specific limits before applying an article. ## Article Useful security guidance must be understandable and traceable. It must also show where a fact ends and an operational recommendation begins. This article establishes the editorial standard for material published through DSE Updates. ## Start with the most authoritative available source DSE editorial policy: factual technical, regulatory, and vulnerability claims should point to the exact primary source whenever practical. Preferred sources include a government agency, standards body, official product documentation, vendor security advisory, or manufacturer lifecycle notice. A search-result page, unsourced summary, forum comment, marketing repost, or AI-generated answer is not sufficient evidence for a production advisory. The source field should lead to the page that supports the central claim, not merely to an organization’s home page. Dated publications should include the publication or revision date. Living pages may leave that date blank, but the DSE review date must show when the page was actually checked. ## Separate evidence from recommendation Source fact identifies what the cited organization publishes. DSE recommendation explains a cautious way to evaluate or act on that information. Recommendations must account for testing, backups, dependencies, change control, rollback, safety, licensing, contractual scope, and the customer’s actual environment. DSE should not convert a vendor possibility into a universal fact. “A product may be affected” is different from “your system is affected.” The second statement requires an inventory match, version or configuration evidence, and any prerequisites identified by the source. ## Use restrained priority labels - Info: durable education, definitions, or planning context. - Advisory: a recommended review or action whose timing depends on exposure and business risk. - Important or Critical: reserved for current, dated situations supported by direct evidence and a clearly affected scope. Priority describes the published situation, not an automatic instruction to make an immediate production change. Readers should use the affected statement, action, source, and their own inventory to decide applicability. ## Protect customers and correct the record Public articles must not expose customer names, incidents, tickets, credentials, IP addresses, topology, screenshots, attachments, or private support procedures. Examples should be generic or explicitly fictional. Product and partner references must not imply an unverified certification, authorization, deployment, performance level, or endorsement. DSE editorial policy: material changes require a new review date and a clear correction or revision when the earlier statement could mislead readers. Superseded urgent notices should be archived or redirected rather than silently left as current guidance. ## How readers should use an article Read the source, affected audience, requested action, and limitations together. Do not treat public education as customer-specific engineering, legal advice, an active support instruction, or proof of compliance. When the environment, contract, or safe change sequence matters, use the DSE helpdesk or contact path for a documented review. ## Primary reference - Name: DSE Security Updates - Authority: DSE Security editorial guidance - URL: https://update.dsesecurity.com/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “How DSE Updates researches, reviews, and maintains public guidance,” DSE Security, https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Identify a new disk conclusively before initializing it > What evidence should establish that a disk is safe to initialize? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-019-identify-a-new-disk-conclusively-before-initializing-it/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:52+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What evidence should establish that a disk is safe to initialize? ## Potentially affected Use this review when preparing a genuinely new storage device. ## DSE recommendation Compare the physical inventory with the disk shown by the management tool, including capacity and the available identifying information. ## Article ## Source facts Microsoft explains that a newly added disk must be initialized before it is prepared for file storage in Windows; formatting and any required drive-letter assignment follow. Its procedure warns that initializing an in-use disk erases its data and calls for backing up existing files first. The procedure is intended for a new disk without existing data; some USB devices support formatting rather than initialization. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/disk-management/initialize-new-disks). ## Applicability Use this review when preparing a genuinely new storage device. Treat an unexpectedly missing or uninitialized existing disk as a separate troubleshooting case. Establish the device identity and data ownership before selecting an operation. ## DSE recommendation Compare the physical inventory with the disk shown by the management tool, including capacity and the available identifying information. Have a second administrator confirm the selected target and the owner’s statement about existing data. Record the intended partitioning and destination workload. If the device identity or data history is uncertain, return the decision to the storage owner before proceeding. ## Verification After an approved initialization, record the selected disk and resulting state. Verify the intended volume and access path before allowing application writes. Retain the prechange identity evidence alongside the completed configuration. If the observed capacity or device association differs from the approved plan, pause allocation and investigate the discrepancy. ## Official references [Microsoft Learn: Initialize New Disks](https://learn.microsoft.com/en-us/windows-server/storage/disk-management/initialize-new-disks). Source reviewed September 8, 2026. ## Primary reference - Name: Initialize New Disks - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/disk-management/initialize-new-disks - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Identify a new disk conclusively before initializing it,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-019-identify-a-new-disk-conclusively-before-initializing-it/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Identify devices, data, applications, and vulnerabilities before a destructive data event > Use SP 1800-25, Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/identify-devices-data-applications-and-vulnerabilities-before-a-destructive-data-event/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:18:02+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use SP 1800-25, Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of SP 1800-25, Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Identify devices, data, applications, and vulnerabilities before a destructive data event. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [SP 1800-25, Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events](https://csrc.nist.gov/pubs/sp/1800/25/final) from National Institute of Standards and Technology supports the following bounded statements: - NIST SP 1800-25 treats devices, data, and applications as assets that can become targets of data-integrity attacks. The research record locates this support at Abstract. - Its example solution combines asset identification and protection methods including backups, secure storage, integrity checks, logs, and vulnerability management. The research record locates this support at Abstract. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives only where the source and recorded environment align. ## What the source does not establish The NCCoE example implementation is not a product mandate, complete architecture, or guarantee that any listed technology combination meets a particular recovery objective. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Abstract, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Abstract, which observable configuration, record, or test can confirm applicability here? - Within essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, which versions, roles, and configuration states define the review population? - Could identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Abstract; Abstract. Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [SP 1800-25, Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events](https://csrc.nist.gov/pubs/sp/1800/25/final) — National Institute of Standards and Technology ## Primary reference - Name: SP 1800-25, Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/1800/25/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Identify devices, data, applications, and vulnerabilities before a destructive data event,” DSE Security, https://update.dsesecurity.com/updates/identify-devices-data-applications-and-vulnerabilities-before-a-destructive-data-event/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Identify environmental receptors within the modeled accidental-release endpoint > Use 40 CFR 68.33 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/identify-environmental-receptors-within-the-modeled-accidental-release-endpoint/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:14+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.33 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.33 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Identify environmental receptors within the modeled accidental-release endpoint. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.33 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.33) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the owner or operator list in the RMP environmental receptors within a circle with its center at the point of the release and a radius determined by the distance to the endpoint defined in section 68.22(a) of this part. The research record locates this support at 40 CFR 68.33(a) (eCFR anchor p-68.33(a)). - Under 40 CFR 68, the owner or operator may rely on information provided on local U.S. Geological Survey maps or on any data source containing U.S.G.S. data to identify environmental receptors. The research record locates this support at 40 CFR 68.33(b) (eCFR anchor p-68.33(b)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths and the conditions the source actually describes. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 40 CFR 68.33(a) (eCFR anchor p-68.33(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.33(b) (eCFR anchor p-68.33(b)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations 40 CFR 68.33(a) (eCFR anchor p-68.33(a)); 40 CFR 68.33(b) (eCFR anchor p-68.33(b)) adjacent to the sanitized artifacts used for comparison. Prefer facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [40 CFR 68.33 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.33) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.33 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.33 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Identify environmental receptors within the modeled accidental-release endpoint,” DSE Security, https://update.dsesecurity.com/updates/identify-environmental-receptors-within-the-modeled-accidental-release-endpoint/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Identify the answering server instance behind a shared DNS address > Use RFC 4892 — Requirements for a Mechanism Identifying a Name Server Instance to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/identify-the-answering-server-instance-behind-a-shared-dns-address/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:41+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4892 — Requirements for a Mechanism Identifying a Name Server Instance to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4892 — Requirements for a Mechanism Identifying a Name Server Instance ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Identify the answering server instance behind a shared DNS address. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4892 — Requirements for a Mechanism Identifying a Name Server Instance](https://www.rfc-editor.org/rfc/rfc4892.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A server-instance identification mechanism should work in-band with normal DNS queries and also permit a dedicated identification query. The research record locates this support at Section 3 (Characteristics of an Implementation Neutral Convention), guideline 1. - The identifier should distinguish a server instance without forcing disclosure of a private hostname or administrative unicast address. The research record locates this support at Section 3 (Characteristics of an Implementation Neutral Convention), guideline 4. - The mechanism should be implementation-neutral, easy to disable, subject to query access controls, and capable of authenticating returned identification data. The research record locates this support at Section 3 (Characteristics of an Implementation Neutral Convention), guidelines 3, 5, and 6. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 3 (Characteristics of an Implementation Neutral Convention), guideline 1, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Characteristics of an Implementation Neutral Convention), guideline 4, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 3 (Characteristics of an Implementation Neutral Convention), guidelines 3, 5, and 6, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to Section 3 (Characteristics of an Implementation Neutral Convention), guideline 1; Section 3 (Characteristics of an Implementation Neutral Convention), guideline 4; Section 3 (Characteristics of an Implementation Neutral Convention), guidelines 3, 5, and 6 and to observable material such as zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 4892 — Requirements for a Mechanism Identifying a Name Server Instance](https://www.rfc-editor.org/rfc/rfc4892.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4892 — Requirements for a Mechanism Identifying a Name Server Instance - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4892.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Identify the answering server instance behind a shared DNS address,” DSE Security, https://update.dsesecurity.com/updates/identify-the-answering-server-instance-behind-a-shared-dns-address/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Identify the physical GPU before assigning it to a standalone VM > What evidence is needed before assigning an entire graphics device through Hyper-V DDA? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-180-identify-the-physical-gpu-before-assigning-it-to-a-standalone-vm/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:11+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What evidence is needed before assigning an entire graphics device through Hyper-V DDA? ## Potentially affected Administrators assigning graphics devices to VMs on standalone Hyper-V hosts. ## DSE recommendation Run the documented hardware survey in the approved assessment environment and review the result with the hardware owner. ## Article ## Source facts Microsoft documents Discrete Device Assignment as passing a whole PCIe device to a VM on a standalone, nonclustered Hyper-V host. The device location path identifies the hardware for host dismount and mount operations. A vendor-supplied mitigation driver is separate from the guest device driver and, when provided, should be installed before the device is dismounted from the host. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/Deploying-graphics-devices-using-dda). ## Applicability Confirm that the intended deployment is standalone rather than clustered. Identify the server, VM, physical adapter, and vendor guidance before choosing the device. Keep full-device assignment distinct from GPU partitioning and from clustered VM GPU support. ## DSE recommendation Run the documented hardware survey in the approved assessment environment and review the result with the hardware owner. Record the device location path against the physical inventory, then have a second operator verify the match. Resolve the vendor mitigation-driver decision before planning the host change. Document the intended guest driver and a procedure for returning the device to host use. ## Verification During the controlled pilot, verify that the intended device is assigned to the intended VM and that the guest reports the expected hardware. Exercise the required graphics workload and record actual results. Confirm the planned removal and return path in the test environment before assigning additional devices. ## Official references [Microsoft Learn: Deploy graphics devices by using Discrete Device Assignment](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/Deploying-graphics-devices-using-dda). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy graphics devices by using Discrete Device Assignment - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/Deploying-graphics-devices-using-dda - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Identify the physical GPU before assigning it to a standalone VM,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-180-identify-the-physical-gpu-before-assigning-it-to-a-standalone-vm/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Identify the VPN Server application before scoping Conditional Access > Which cloud application receives the VPN Conditional Access policy? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-243-identify-the-vpn-server-application-before-scoping-conditional-access/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:08+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Which cloud application receives the VPN Conditional Access policy? ## Potentially affected Administrators configuring the documented Microsoft Entra Conditional Access integration for Always On VPN. ## DSE recommendation Have the identity owner locate the VPN Server application and establish whether the one-time consent step has been completed. ## Article ## Source facts Microsoft documents a VPN Server cloud application used by the VPN Conditional Access integration. Creating the first VPN root certificate automatically creates that application in the tenant. The initial consent step requires a Global Administrator and is performed once per tenant; subsequent certificate operations do not require consent again. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/remote/remote-access/how-to-aovpn-conditional-access). ## Applicability This check belongs to the documented Always On VPN integration, not every VPN product connected to a tenant. Confirm that its infrastructure and management prerequisites apply. Identify the actual tenant and application before planning policy scope or interpreting an access result. ## DSE recommendation Have the identity owner locate the VPN Server application and establish whether the one-time consent step has been completed. Record the tenant and application identifiers in the change record without including secrets or private keys. Build the proposed policy around a small, named test population and its expected access conditions. Keep policy targeting review separate from the certificate-upload procedure. ## Verification Inspect the saved policy target and confirm it is the intended VPN application, not a similarly named enterprise application. Perform an allowed and a disallowed sign-in under the approved test conditions. Correlate the resulting identity records with the selected policy and resolve unexpected targeting before expanding the population. ## Official references [Microsoft Learn: Configure Conditional Access for VPN connectivity using Microsoft Entra ID](https://learn.microsoft.com/en-us/windows-server/remote/remote-access/how-to-aovpn-conditional-access). Source reviewed September 8, 2026. ## Primary reference - Name: Configure Conditional Access for VPN connectivity using Microsoft Entra ID - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-access/how-to-aovpn-conditional-access - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Identify the VPN Server application before scoping Conditional Access,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-243-identify-the-vpn-server-application-before-scoping-conditional-access/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Identify whether a Hyper-V backup product uses host VSS or the WMI path > Which Hyper-V backup interface and change-tracking model is a backup implementation using? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-135-identify-whether-a-hyper-v-backup-product-uses-host-vss-or-the-wmi-path/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:56+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which Hyper-V backup interface and change-tracking model is a backup implementation using? ## Potentially affected Administrators and developers reviewing Hyper-V backup implementations. ## DSE recommendation Ask the backup owner or vendor to document the interface, reference-point lifecycle, and supported restore workflow. ## Article ## Source facts Hyper-V supports host-side VM backup without requiring custom backup software inside each VM. Microsoft describes the host VSS writer as a small-scale approach that backs up the server’s VMs together. From Windows Server 2016, the Hyper-V WMI backup API uses reference points and resilient change tracking instead of host VSS, while still using VSS inside the guest for backup purposes. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/backup-approaches). ## Applicability Identify the host release, backup product version, protected guests, and vendor-supported interface. Review the product’s guest consistency and data-reading behavior instead of inferring it from a generic statement that Hyper-V backup is supported. ## DSE recommendation Ask the backup owner or vendor to document the interface, reference-point lifecycle, and supported restore workflow. Record how failures and stale tracking state are investigated. Keep the implementation decision separate from retention policy and the business recovery objective. ## Verification Run a controlled backup and restore of a representative VM and verify the application’s recovered state. Preserve job and guest consistency evidence and compare the observed behavior with the product’s documented method. Resolve missing application data or uncertain tracking behavior before depending on the implementation for that workload. ## Official references [Microsoft Learn: Hyper-V Backup Approaches](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/backup-approaches). Source reviewed September 8, 2026. ## Primary reference - Name: Hyper-V Backup Approaches - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/backup-approaches - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Identify whether a Hyper-V backup product uses host VSS or the WMI path,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-135-identify-whether-a-hyper-v-backup-product-uses-host-vss-or-the-wmi-path/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Identify which drive tier supplies the Storage Spaces Direct cache > How does a mixed-drive Storage Spaces Direct deployment choose and use its cache? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-089-identify-which-drive-tier-supplies-the-storage-spaces-direct-cache/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:42+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How does a mixed-drive Storage Spaces Direct deployment choose and use its cache? ## Potentially affected Administrators reviewing cache behavior in mixed-drive Storage Spaces Direct clusters. ## DSE recommendation Prepare a drive-role inventory that identifies cache media, capacity media, and the intended workload. ## Article ## Source facts Storage Spaces Direct automatically allocates the fastest drive type to caching when a deployment contains different drive types; the remaining drives supply capacity. Cache behavior depends on the capacity media. Flash capacity receives write caching, while rotating-disk capacity receives both read and write caching. Microsoft describes this server-side cache as persistent and configured automatically during deployment, with little manual management normally required. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/cache). ## Applicability Record the actual drive types and roles on each server. Distinguish this persistent storage-pool cache from the separate CSV memory read cache and from the standalone Storage bus cache feature. ## DSE recommendation Prepare a drive-role inventory that identifies cache media, capacity media, and the intended workload. Have the storage owner review whether the observed roles match the hardware design. Before changing media or cache settings, record the current configuration and define a workload-specific evaluation plan. ## Verification Compare the reported cache and capacity assignments with the approved inventory. Measure the chosen workload under controlled conditions and keep the test duration and input load with the results. Investigate uneven device assignments or unexpected latency without assuming that the presence of a cache proves an application performance target. ## Official references [Microsoft Learn: Understanding the storage pool cache in Azure Local and Windows Server clusters](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/cache). Source reviewed September 8, 2026. ## Primary reference - Name: Understanding the storage pool cache in Azure Local and Windows Server clusters - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/cache - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Identify which drive tier supplies the Storage Spaces Direct cache,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-089-identify-which-drive-tier-supplies-the-storage-spaces-direct-cache/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Ignore ICMP Source Quench as a congestion-control signal > Use RFC 6633 — Deprecation of ICMP Source Quench Messages to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/ignore-icmp-source-quench-as-a-congestion-control-signal/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:26+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6633 — Deprecation of ICMP Source Quench Messages to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6633 — Deprecation of ICMP Source Quench Messages ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Ignore ICMP Source Quench as a congestion-control signal. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6633 — Deprecation of ICMP Source Quench Messages](https://www.rfc-editor.org/rfc/rfc6633.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A host must not send ICMP Source Quench, and TCP must silently discard any Source Quench it receives. The research record locates this support at Section 3 (Updating RFC 1122). - A router must ignore every received ICMP Source Quench message. The research record locates this support at Section 4 (Updating RFC 1812). - UDP, SCTP, DCCP, and any other transport instance must silently ignore or discard a received Source Quench. The research record locates this support at Sections 5 (Clarification for UDP, SCTP, and DCCP) and 6 (General Advice to Transport Protocols). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Section 3 (Updating RFC 1122), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4 (Updating RFC 1812), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 5 (Clarification for UDP, SCTP, and DCCP) and 6 (General Advice to Transport Protocols), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to Section 3 (Updating RFC 1122); Section 4 (Updating RFC 1812); Sections 5 (Clarification for UDP, SCTP, and DCCP) and 6 (General Advice to Transport Protocols) and to observable material such as configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 6633 — Deprecation of ICMP Source Quench Messages](https://www.rfc-editor.org/rfc/rfc6633.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6633 — Deprecation of ICMP Source Quench Messages - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6633.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Ignore ICMP Source Quench as a congestion-control signal,” DSE Security, https://update.dsesecurity.com/updates/ignore-icmp-source-quench-as-a-congestion-control-signal/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Import-DnsServerRootHint: import dns server root hint with bounded evidence > Use Import-DnsServerRootHint to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/import-dnsserverroothint-import-dns-server-root-hint-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:56+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Import-DnsServerRootHint to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Import-DnsServerRootHint ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Import-DnsServerRootHint: import dns server root hint with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Import-DnsServerRootHint](https://learn.microsoft.com/en-us/powershell/module/dnsserver/import-dnsserverroothint?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Import-DnsServerRootHint cmdlet copies root hints from a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The root hints that you copy will not overwrite any existing root hints.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; DESCRIPTION. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-270 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Import-DnsServerRootHint](https://learn.microsoft.com/en-us/powershell/module/dnsserver/import-dnsserverroothint?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Import-DnsServerRootHint - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/import-dnsserverroothint?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Import-DnsServerRootHint: import dns server root hint with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/import-dnsserverroothint-import-dns-server-root-hint-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Import-DnsServerTrustAnchor: import dns server trust anchor with before-and-after evidence > Use Import-DnsServerTrustAnchor to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/import-dnsservertrustanchor-import-dns-server-trust-anchor-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:17+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Import-DnsServerTrustAnchor to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Import-DnsServerTrustAnchor ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Import-DnsServerTrustAnchor: import dns server trust anchor with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Import-DnsServerTrustAnchor](https://learn.microsoft.com/en-us/powershell/module/dnsserver/import-dnsservertrustanchor?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Import-DnsServerTrustAnchor cmdlet imports a trust anchor from a specified file for a Domain Name System (DNS) server.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “If you specify a key set file, the cmdlet imports the DNS public key (DNSKEY) record set from the input key set file.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; DESCRIPTION. Favor PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-249 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Import-DnsServerTrustAnchor](https://learn.microsoft.com/en-us/powershell/module/dnsserver/import-dnsservertrustanchor?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Import-DnsServerTrustAnchor - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/import-dnsservertrustanchor?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Import-DnsServerTrustAnchor: import dns server trust anchor with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/import-dnsservertrustanchor-import-dns-server-trust-anchor-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Improve software assurance as a measured program with OWASP SAMM > OWASP SAMM organizes software assurance across governance, design, implementation, verification, and operations. Assess current practice, choose a justified target, and improve with observable evidence. - Canonical URL: https://update.dsesecurity.com/updates/owasp-samm-measured-software-assurance-program/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:33:47+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know OWASP SAMM organizes software assurance across governance, design, implementation, verification, and operations. Assess current practice, choose a justified target, and improve with observable evidence. ## Potentially affected Organizations that need to assess and improve software security practices across teams, products, acquired services, and the full development and operating lifecycle. ## DSE recommendation Use a consistent SAMM assessment scope and evidence standard, prioritize a small set of risk-linked improvements, assign owners and measures, and reassess outcomes instead of optimizing a maturity score alone. ## Article Bottom line: sustainable software assurance is a management system, not a collection of disconnected tools. Measure current practices across the lifecycle, choose improvements that address actual risk and delivery constraints, and verify that the new practices change observable work. ## Source fact: what OWASP SAMM organizes The official [OWASP SAMM model](https://owaspsamm.org/model/) defines five business functions and fifteen security practices for assessing and improving software security posture. The functions are Governance, Design, Implementation, Verification, and Operations. The practices cover areas such as strategy and metrics, policy, education, threat assessment, security requirements and architecture, secure build and deployment, defect management, assessment and testing, incident management, and environment and operational management. The model page identifies version 2.0 and describes SAMM as an OWASP community project. Its structured breadth supports reviewing how practices connect across a software lifecycle. ## What the source does not establish SAMM does not certify a product or guarantee secure software. A maturity score is not a direct measure of vulnerability count, exploitation likelihood, business loss, or customer assurance. Comparing scores is unreliable if organizations use different scope, evidence, interpretation, or assessor independence. The model also does not require every team to pursue the same target at the same time. Product criticality, delivery model, staffing, supplier role, technology, regulation, and threat exposure influence priority. ## Applicability questions - Which organization, portfolio, product, team, or lifecycle is in scope? - What evidence is required to distinguish an established practice from an aspiration or isolated example? - Which software risks and business objectives justify the target state? - Which upstream and downstream practices must change together for an improvement to work? - Who owns the improvement, how will progress be observed, and when will it be reassessed? ## DSE recommendation: improve the operating system, not the score The following steps are DSE recommendations based on the cited source. - Define assessment scope, model version, evidence rules, assessor roles, sampling, and date. Preserve the criteria so later assessments are comparable. - Collect evidence from policy, workflow, repositories, pipelines, defects, releases, incidents, interviews, and observed practice. Record uneven adoption rather than averaging it away. - Link findings to software and business risk. Choose a small number of improvements that remove a bottleneck or strengthen a weak lifecycle connection. - Give each improvement an owner, resources, milestones, leading indicator, outcome indicator, and evidence artifact. Include operational and supplier dependencies. - Pilot the practice with representative teams. Capture friction, exceptions, escaped defects, delivery effects, and operator feedback before scaling. - Reassess with the same scope and evidence standard. Report both improvement and regression without presenting maturity as a guarantee. ## Verification and evidence Retain the assessment basis, evidence samples, scoring rationale, gaps, risk linkage, improvement plan, ownership, pilot results, measures, exceptions, and reassessment. Confirm that a claimed improvement can be observed in recent work products and not only in a new policy document. ## Official references - [OWASP SAMM model](https://owaspsamm.org/model/) — OWASP Foundation; official living model page - [OWASP SAMM assessment guidance](https://owaspsamm.org/assessment/) — OWASP Foundation; official project guidance ## Primary reference - Name: OWASP Software Assurance Maturity Model - Authority: owaspsamm.org - URL: https://owaspsamm.org/model/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Improve software assurance as a measured program with OWASP SAMM,” DSE Security, https://update.dsesecurity.com/updates/owasp-samm-measured-software-assurance-program/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Include bare-metal backups in the forest-recovery evidence set > Use AD Forest Recovery - Backing up a full server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/include-bare-metal-backups-in-forest-recovery-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:30+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use AD Forest Recovery - Backing up a full server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of AD Forest Recovery - Backing up a full server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Include bare-metal backups in the forest-recovery evidence set. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [AD Forest Recovery – Backing up a full server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-backing-up-a-full-server) from Microsoft supports the following bounded statements: - Microsoft recommends bare-metal recovery backup preparation for forest recovery. The research record locates this support at Opening overview. - A BMR backup can be restored to different hardware or a different operating-system instance. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Confirm backup-solution support and perform an isolated full-server restore test. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [AD Forest Recovery – Backing up a full server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-backing-up-a-full-server) — Microsoft ## Primary reference - Name: AD Forest Recovery - Backing up a full server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-backing-up-a-full-server - Source publication date: 2023-06-21 ## Citation and use Preferred citation: “Include bare-metal backups in the forest-recovery evidence set,” DSE Security, https://update.dsesecurity.com/updates/include-bare-metal-backups-in-forest-recovery-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Include learning periods and complete attack stories in Defender for Identity tests > Use Best Practices before Offensive Security Testing for Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/include-learning-periods-complete-attack-stories-identity-tests/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:06+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Best Practices before Offensive Security Testing for Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Best Practices before Offensive Security Testing for Microsoft Defender for Identity ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Include learning periods and complete attack stories in Defender for Identity tests. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Best Practices before Offensive Security Testing for Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/security-testing-best-practices) from Microsoft supports the following bounded statements: - Defender for Identity alert learning periods tune detections, and testing without the needed learning period reduces detection accuracy. The research record locates this support at Common issues that affect testing > Detection accuracy issues > Insufficient learning period. - Microsoft recommends testing actual attack scenarios instead of single TTPs because detections focus on complete attack stories and one kill-chain segment produces incomplete results. The research record locates this support at Common issues that affect testing > Configuration issues > Incomplete attack simulation. - Some penetration-testing tools can return false results, so Microsoft directs testers to cross-check the relevant audit logs to confirm that an attack succeeded. The research record locates this support at Common issues that affect testing > Configuration issues > Incompatible penetration testing tools. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows only where the source and recorded environment align. ## What the source does not establish Run only authorized, controlled testing; the guidance does not guarantee a specific alert, validate every tool, or replace attack-specific learning-period checks. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Common issues that affect testing > Detection accuracy issues > Insufficient learning period, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Common issues that affect testing > Configuration issues > Incomplete attack simulation, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Common issues that affect testing > Configuration issues > Incompatible penetration testing tools, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows are in and out of scope? - Which condition in Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Common issues that affect testing > Detection accuracy issues > Insufficient learning period; Common issues that affect testing > Configuration issues > Incomplete attack simulation; Common issues that affect testing > Configuration issues > Incompatible penetration testing tools to the observed environment. Useful domain evidence includes alert records, investigation timelines, analyst actions, tuning or exclusion approvals, remediation results, and case closure; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Best Practices before Offensive Security Testing for Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/security-testing-best-practices) — Microsoft ## Primary reference - Name: Best Practices before Offensive Security Testing for Microsoft Defender for Identity - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/security-testing-best-practices - Source publication date: 2026-01-26 ## Citation and use Preferred citation: “Include learning periods and complete attack stories in Defender for Identity tests,” DSE Security, https://update.dsesecurity.com/updates/include-learning-periods-complete-attack-stories-identity-tests/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Include non-domain and non-Windows devices in Defender for Identity monitoring scope > Use Microsoft Defender for Identity frequently asked questions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/include-non-domain-non-windows-devices-defender-identity-scope/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:31+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Microsoft Defender for Identity frequently asked questions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft Defender for Identity frequently asked questions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Include non-domain and non-Windows devices in Defender for Identity monitoring scope. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft Defender for Identity frequently asked questions](https://learn.microsoft.com/en-us/defender-for-identity/technical-faq) from Microsoft supports the following bounded statements: - Devices enter Defender for Identity’s monitoring scope when they authenticate or request authorization from Active Directory; this includes mobile and non-Windows endpoints. The research record locates this support at What is Defender for Identity? > Does Defender for Identity monitor only domain-joined devices?. - Defender for Identity monitors the behavior of all computer accounts and other entities because those entities can be used for malicious activity. The research record locates this support at What is Defender for Identity? > Does Defender for Identity monitor computer accounts and user accounts?. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows and the conditions the source actually describes. ## What the source does not establish The documented scope is authentication and authorization activity against Active Directory; it does not imply endpoint telemetry, complete network visibility, or detection of every malicious action. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at What is Defender for Identity? > Does Defender for Identity monitor only domain-joined devices?, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at What is Defender for Identity? > Does Defender for Identity monitor computer accounts and user accounts?, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from What is Defender for Identity? > Does Defender for Identity monitor only domain-joined devices?; What is Defender for Identity? > Does Defender for Identity monitor computer accounts and user accounts? to the observed environment. Useful domain evidence includes alert records, investigation timelines, analyst actions, tuning or exclusion approvals, remediation results, and case closure; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Microsoft Defender for Identity frequently asked questions](https://learn.microsoft.com/en-us/defender-for-identity/technical-faq) — Microsoft ## Primary reference - Name: Microsoft Defender for Identity frequently asked questions - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/technical-faq - Source publication date: 2024-06-10 ## Citation and use Preferred citation: “Include non-domain and non-Windows devices in Defender for Identity monitoring scope,” DSE Security, https://update.dsesecurity.com/updates/include-non-domain-non-windows-devices-defender-identity-scope/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Include rarely connected clients in each DirectAccess migration ring > How should DirectAccess-to-Always-On-VPN migration rings account for remote clients? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-106-include-rarely-connected-clients-in-each-directaccess-migration-ring/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:25+00:00 - Modified: 2026-09-08T18:23:26+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How should DirectAccess-to-Always-On-VPN migration rings account for remote clients? ## Potentially affected Administrators planning a phased DirectAccess migration to Always On VPN. ## DSE recommendation Build each ring from both regularly connected and infrequently connected devices. ## Article ## Source facts Microsoft recommends running DirectAccess and Always On VPN alongside one another during a planned migration. An incorrect task order can leave remote users without access to organizational resources. Migration rings divide the work into successive phases. Microsoft recommends including users who visit the office frequently and those who do not in each phase. Remote clients can take longer to receive the migration update. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-access/da-always-on-vpn-migration/da-always-on-migration-planning). ## Applicability Identify the remote-user groups, device update paths, application access requirements, and support contacts. Review the complete migration sequence before changing the existing remote-access configuration. ## DSE recommendation Build each ring from both regularly connected and infrequently connected devices. Define how completion will be observed for each group and who can assist a user who cannot reconnect. Ask the service owner to approve the criteria for progressing to the next ring and for pausing the migration. ## Verification Track actual update receipt and test the required remote applications from each participating group. Include a device that has been away from the office for a representative period. Reconcile missing devices and user feedback before expanding a ring or withdrawing their former access route. ## Official references [Microsoft Learn: Remote Access Always On VPN migration planning](https://learn.microsoft.com/en-us/windows-server/remote/remote-access/da-always-on-vpn-migration/da-always-on-migration-planning). Source reviewed September 8, 2026. ## Primary reference - Name: Remote Access Always On VPN migration planning - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-access/da-always-on-vpn-migration/da-always-on-migration-planning - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Include rarely connected clients in each DirectAccess migration ring,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-106-include-rarely-connected-clients-in-each-directaccess-migration-ring/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Include RDS component and template handling in a Site Recovery plan > What RDS-specific actions should be included in an Azure Site Recovery recovery plan? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-136-include-rds-component-and-template-handling-in-a-site-recovery-plan/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:55+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What RDS-specific actions should be included in an Azure Site Recovery recovery plan? ## Potentially affected Administrators planning disaster recovery for Remote Desktop Services components. ## DSE recommendation Create an ordered recovery worksheet that distinguishes component startup from template handling and host registration. ## Article ## Source facts Microsoft’s RDS guidance places all component VMs into an Azure Site Recovery recovery plan to automate failover. The plan identifies its source and target, which can be another RDS site or Azure. In the pooled-VM example, a recovered generalized template is shut down because RDS requires a stopped template to create the pooled configuration. The example identifies the template by VM ID when names are shared between sites. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-disaster-recovery-plan). ## Applicability Inventory the actual RDS deployment type, component VMs, templates, target site, and dependent services. Review which example actions apply to the deployment before incorporating them into the plan. ## DSE recommendation Create an ordered recovery worksheet that distinguishes component startup from template handling and host registration. Ask the RDS owner to identify the template and workload instances unambiguously. Review script assumptions, pending restarts, and the expected management endpoint at the target site. ## Verification Exercise the plan in the approved recovery-test environment and verify both service access and the intended template state. Test the relevant desktop creation or reconnection workflow after recovery. Record component failures and identity mismatches separately, and reconcile them before calling the RDS recovery plan complete. ## Official references [Microsoft Learn: Create your disaster recovery plan](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-disaster-recovery-plan). Source reviewed September 8, 2026. ## Primary reference - Name: Create your disaster recovery plan - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-disaster-recovery-plan - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Include RDS component and template handling in a Site Recovery plan,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-136-include-rds-component-and-template-handling-in-a-site-recovery-plan/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Include resynchronization time in S2D per-server capacity planning > How should per-server capacity be reviewed before expanding an S2D cluster? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:05+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should per-server capacity be reviewed before expanding an S2D cluster? ## Potentially affected Administrators planning drive capacity for Azure Local or Windows Server storage clusters. ## DSE recommendation Prepare a per-node capacity inventory and a separate pool total. ## Article ## Source facts Microsoft recommends limiting the total storage capacity on an individual server to about 400 terabytes. The source connects greater capacity per server with longer data-resynchronization time after an outage or reboot. It lists a four-petabyte maximum storage-pool size, with a one-petabyte limit for Windows Server 2016. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/choose-drives). ## Applicability Identify the server version and distinguish capacity on one server from capacity across the whole pool. Review the current platform limits before applying the numbers. Ask the workload owner what recovery and maintenance duration is acceptable for the proposed expansion. ## DSE recommendation Prepare a per-node capacity inventory and a separate pool total. Pair the expansion request with an observed or tested resynchronization-time estimate appropriate to the actual hardware and workload. Have the storage owner explain how the larger node affects the maintenance plan. Avoid presenting a supported maximum as the preferred design target without considering operational recovery. ## Verification Measure a representative approved node-return and resynchronization exercise before accepting the expanded design. Record data volume, workload, hardware, elapsed time, and health at completion. Compare the result with the maintenance and recovery expectations. Retain the measured conditions so future capacity additions trigger another review rather than inheriting an unrelated timing assumption. ## Official references [Microsoft Learn: Choose drives for Azure Local and Windows Server clusters](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/choose-drives). Source reviewed September 8, 2026. ## Primary reference - Name: Choose drives for Azure Local and Windows Server clusters - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/choose-drives - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Include resynchronization time in S2D per-server capacity planning,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-186-include-resynchronization-time-in-s2d-per-server-capacity-planning/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Include sanitation and potable-water dependencies in outage plans > Use 29 CFR 1910.141 - Sanitation to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/include-sanitation-and-potable-water-dependencies-in-outage-plans/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:24+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.141 - Sanitation to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.141 - Sanitation ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Include sanitation and potable-water dependencies in outage plans. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.141 – Sanitation](https://www.ecfr.gov/current/title-29/section-1910.141) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, the rule requires that nonpotable water not be used for washing any portion of the person, cooking or eating utensils, or clothing. The research record locates this support at 29 CFR 1910.141(b)(2)(iii) (eCFR anchor p-1910.141(b)(2)(iii)). - Under 29 CFR 1910, the rule requires that potable water be provided in all places of employment, for drinking, washing of the person, cooking, washing of foods, washing of cooking or eating utensils, washing of food preparation or processing premises, and personal service rooms. The research record locates this support at 29 CFR 1910.141(b)(1)(i) (eCFR anchor p-1910.141(b)(1)(i)). The source support ends with the statements listed above. Use them to examine essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Federal workplace rule; public-health, plumbing, food-service, and local requirements may impose additional or more specific controls. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.141(b)(2)(iii) (eCFR anchor p-1910.141(b)(2)(iii)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.141(b)(1)(i) (eCFR anchor p-1910.141(b)(1)(i)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 29 CFR 1910.141(b)(2)(iii) (eCFR anchor p-1910.141(b)(2)(iii)); 29 CFR 1910.141(b)(1)(i) (eCFR anchor p-1910.141(b)(1)(i)). Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [29 CFR 1910.141 – Sanitation](https://www.ecfr.gov/current/title-29/section-1910.141) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.141 - Sanitation - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.141 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Include sanitation and potable-water dependencies in outage plans,” DSE Security, https://update.dsesecurity.com/updates/include-sanitation-and-potable-water-dependencies-in-outage-plans/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inspect and maintain Program 2 process equipment under written procedures > Use 40 CFR 68.56 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/inspect-and-maintain-program-2-process-equipment-under-written-procedures/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:06+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.56 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.56 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Inspect and maintain Program 2 process equipment under written procedures. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.56 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.56) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the owner or operator prepare and implement procedures to maintain the on-going mechanical integrity of the process equipment. The research record locates this support at 40 CFR 68.56(a) (eCFR anchor p-68.56(a)). - Under 40 CFR 68, the rule requires that the owner or operator perform or cause to be performed inspections and tests on process equipment. The research record locates this support at 40 CFR 68.56(d) (eCFR anchor p-68.56(d)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths only where the source and recorded environment align. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.56(a) (eCFR anchor p-68.56(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.56(d) (eCFR anchor p-68.56(d)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from 40 CFR 68.56(a) (eCFR anchor p-68.56(a)); 40 CFR 68.56(d) (eCFR anchor p-68.56(d)) through facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [40 CFR 68.56 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.56) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.56 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.56 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Inspect and maintain Program 2 process equipment under written procedures,” DSE Security, https://update.dsesecurity.com/updates/inspect-and-maintain-program-2-process-equipment-under-written-procedures/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inspect exported EAP profiles before distributing authentication settings > How can an exported EAP profile be used to review the settings selected in Windows? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-084-inspect-exported-eap-profiles-before-distributing-authentication-settings/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:47+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How can an exported EAP profile be used to review the settings selected in Windows? ## Potentially affected Administrators reviewing Windows Wi-Fi, Ethernet, or VPN EAP connection profiles. ## DSE recommendation Create a representative profile through the approved interface, then examine its exported configuration with the network authentication owner. ## Article ## Source facts Microsoft documents XML connection profiles for Wi-Fi, Ethernet, and VPN. The files contain connection settings and can be exported, imported, and edited. Selecting options through the Windows interface changes the corresponding XML configuration; an export makes those choices available for inspection. Microsoft describes command-line profile transfer as an option when Group Policy or MDM cannot be used. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/configure-eap-profiles). ## Applicability Identify the connection type, Windows release, intended authentication method, and deployment channel. Use the source section for that particular profile type; review interface differences before copying a procedure between operating-system releases. ## DSE recommendation Create a representative profile through the approved interface, then examine its exported configuration with the network authentication owner. Annotate the intended settings and record any differences from the existing profile. Approve the distribution mechanism and target devices before importing the file more broadly. ## Verification On a test device, import the reviewed profile and compare the resulting settings with the approved configuration. Exercise the intended network connection and an explicitly rejected authentication case. Keep sanitized configuration differences and connection results together, and investigate any setting that changes during export or import. ## Official references [Microsoft Learn: Configure EAP Profiles and Settings in Windows](https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/configure-eap-profiles). Source reviewed September 8, 2026. ## Primary reference - Name: Configure EAP Profiles and Settings in Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/extensible-authentication-protocol/configure-eap-profiles - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Inspect exported EAP profiles before distributing authentication settings,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-084-inspect-exported-eap-profiles-before-distributing-authentication-settings/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inspect fire doors as complete assemblies, then control every repair > A labeled leaf is only one part of a fire-door assembly. Inspect the label, frame, glazing, hinges, clearances, closing and latching, coordinators, seals, hardware, signage, and field changes as one opening, then document qualified repairs. - Canonical URL: https://update.dsesecurity.com/updates/inspect-fire-doors-complete-assemblies-control-repairs/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:15:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: Access Control, Business Continuity - Reading time: 3 minutes ## What you need to know A labeled leaf is only one part of a fire-door assembly. Inspect the label, frame, glazing, hinges, clearances, closing and latching, coordinators, seals, hardware, signage, and field changes as one opening, then document qualified repairs. ## Potentially affected Rated corridor, stair, occupancy-separation, service, and equipment-room openings; fire doors combined with access control; frames, glazing, closers, latches, coordinators, gasketing, signage, and maintenance records. ## DSE recommendation Create a verified fire-opening inventory, engage qualified inspectors, test each complete assembly from both sides, control holes and hardware changes, repair listed components correctly, and retain deficiency and retest evidence. ## Article ## Source facts: the rated opening performs as an assembly [NFPA 80, 2025 edition](https://link.nfpa.org/all-publications/80/2025), covers fire doors and other opening protectives, including installation, inspection, testing, and maintenance. Its inspection provisions treat the door leaf, frame, glazing, hardware, closing and latching functions, clearances, and other required elements as an assembly. An inspection is not satisfied by finding a label on the hinge edge. For swinging fire doors, the standard’s minimum verification items include visible and legible labels; no open holes or breaks in the door or frame; intact and secured glazing; secured, aligned, working components without visible damage; no missing or broken parts; acceptable clearances; operational self-closing; correct closing order where a coordinator is installed; positive latching; no auxiliary hardware that interferes; no field modification that voids the label; required edge protection, gasketing, and seals; and compliant signage. Inspection and testing requirements vary by assembly type. NFPA 80 is applied through the adopted code, approved design, listing, and authority having jurisdiction. The edition in force may differ from the linked edition. Inspection frequency, inspector qualifications, acceptance of repairs or field labeling, and record requirements must be confirmed for the property. This article does not determine whether a particular opening is required to be rated. ## DSE recommendation: manage each opening by identity and evidence Begin with a fire-opening register, not a stack of tags. Assign each opening a stable identifier and record building, floor, room or barrier, door type, rating and label information, leaf count, frame, glazing, hardware, hold-open or automatic-closing arrangement, access-control functions, drawing reference, installed modifications, and responsible owner. Reconcile the list to approved life-safety documents and a field walk. - Prepare the opening. Remove ordinary obstructions only when safe, identify known deficiencies, and coordinate alarm releases, security monitoring, elevator or smoke-control interfaces, and occupant impacts. Do not disable a life-safety function merely to make the inspection convenient. - Inspect from both sides. Look at the entire leaf and frame, labels, penetrations, fasteners, hinges, glazing, clearances, threshold condition, seals, protection plates, signs, auxiliary locks, wedges, hooks, floor mats, cables, and decorations. Photograph the opening identifier and each deficiency without obscuring labels. - Exercise the real motion. Open and release the door through the approved test positions. Verify smooth travel, complete closing, correct coordinator sequence, and secure latching without someone pushing the leaf. Test automatic-closing or hold-open release only under the authorized life-safety procedure. - Separate security from egress and rating. Confirm that electrified locks, strikes, contacts, transfer hinges, request-to-exit hardware, door position switches, and added cabling do not introduce an unapproved hole, binding, altered latch, or interference. A security event showing “closed” does not prove the fire latch engaged. - Control every correction. Route adjustment, repair, glazing, drilling, fastening, signage, hardware replacement, and field modification to qualified parties using listed or approved methods. Preserve product instructions, parts, field-evaluation documentation, and authority approvals where required. - Close the deficiency. Record the defect, risk handling, responsible party, due date, repair, and functional retest. Do not mark an opening complete because a work order was closed; verify the assembly after the work. Between formal inspections, teach facilities and security teams to report propped doors, damaged closers, objects in the swing, loose hardware, blocked latches, removed labels, new holes, or repeated access-control faults. Do not ask unqualified staff to certify the assembly; ask them to recognize change and protect the condition until a qualified evaluation occurs. Trend defects by type and contractor. Repeated clearance, closer, strike-alignment, or unauthorized-attachment issues often reveal a maintenance or change-control problem larger than one door. Preserve the accepted inspection, repair, and retest record with the opening history. The goal is a door that closes and latches as its approved assembly was designed—not a checklist that says a leaf was present. ## Official references - National Fire Protection Association, [NFPA 80, Standard for Fire Doors and Other Opening Protectives, 2025 edition](https://link.nfpa.org/all-publications/80/2025). - NFPA Technical Committee on Fire Doors and Windows, [Second Draft Report supporting the 2025 edition](https://docinfofiles.nfpa.org/files/AboutTheCodes/80/80_A2024_FDW_AAA_SRReport.pdf), including inspection criteria. ## Primary reference - Name: NFPA 80: Standard for Fire Doors and Other Opening Protectives, 2025 edition - Authority: National Fire Protection Association - URL: https://link.nfpa.org/all-publications/80/2025 - Source publication date: 2025-01-01 ## Citation and use Preferred citation: “Inspect fire doors as complete assemblies, then control every repair,” DSE Security, https://update.dsesecurity.com/updates/inspect-fire-doors-complete-assemblies-control-repairs/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inspect inherited DFS visibility permissions before relying on access-based enumeration > Why can DFS folders remain visible after access-based enumeration is enabled? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-053-inspect-inherited-dfs-visibility-permissions-before-relying-on-access-based/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:18+00:00 - Modified: 2026-09-08T18:20:21+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know Why can DFS folders remain visible after access-based enumeration is enabled? ## Potentially affected Use this review when DFS namespace visibility differs from the intended user experience. ## DSE recommendation Write a visibility matrix for representative users and folders. ## Article ## Source facts Microsoft explains that DFS folder visibility permissions can inherit from the namespace server’s filesystem. The documented defaults grant domain users read access, so enabling access-based enumeration alone can leave every folder visible. Inherited permissions can be applied across many folders and can cover namespace roots and folders without targets. Microsoft describes changing the parent permissions or choosing explicit permissions as configuration approaches. Changes to inherited permissions do not replicate between namespace servers. Microsoft limits their use to stand-alone namespaces or environments with separate third-party ACL synchronization. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/using-inherited-permissions-with-access-based-enumeration). ## Applicability Use this review when DFS namespace visibility differs from the intended user experience. Identify the namespace type, servers, permission-synchronization arrangement, and parent filesystem permissions before selecting a correction. ## DSE recommendation Write a visibility matrix for representative users and folders. Have the namespace owner review the inheritance source and the scope of any proposed parent change. Keep the decision about displayed namespace entries separate from the underlying file-access authorization review. Pilot the chosen adjustment on an appropriate limited scope and preserve the original permissions. ## Verification Inspect the resulting permission source and test the namespace view with permitted and nonpermitted users. Check neighboring folders that may share the same parent inheritance. Separately test the underlying resource access specified in the plan. Record unexpected visibility or access results and resolve them before expanding a parent-level permission change. ## Official references [Microsoft Learn: Using Inherited Permissions with Access-based Enumeration](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/using-inherited-permissions-with-access-based-enumeration). Source reviewed September 8, 2026. ## Primary reference - Name: Using Inherited Permissions with Access-based Enumeration - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/using-inherited-permissions-with-access-based-enumeration - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Inspect inherited DFS visibility permissions before relying on access-based enumeration,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-053-inspect-inherited-dfs-visibility-permissions-before-relying-on-access-based/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inspect LPG installations as systems, not isolated tanks > Use 29 CFR 1910.110 - Storage and handling of liquefied petroleum gases to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/inspect-lpg-installations-as-systems-not-isolated-tanks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:29+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.110 - Storage and handling of liquefied petroleum gases to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.110 - Storage and handling of liquefied petroleum gases ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Inspect LPG installations as systems, not isolated tanks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.110 – Storage and handling of liquefied petroleum gases](https://www.ecfr.gov/current/title-29/section-1910.110) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, the filling connection and the vent from the liquid level gages in containers, filled at point of installation, must not be less than 10 feet in any direction from air openings into sealed combustion system appliances or mechanical ventilation air intakes. The research record locates this support at 29 CFR 1910.110(b)(14)(vii) (eCFR anchor p-1910.110(b)(14)(vii)). - Under 29 CFR 1910, the rule requires that valves in the assembly of multiple container systems be arranged so that replacement of containers can be made without shutting off the flow of gas in the system. The research record locates this support at 29 CFR 1910.110(c)(6)(i) (eCFR anchor p-1910.110(c)(6)(i)). Keep the evidence boundary at these traced claims. They support a review of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Federal workplace rule; container type, use, location, fire code, supplier instructions, and incorporated standards affect applicability. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.110(b)(14)(vii) (eCFR anchor p-1910.110(b)(14)(vii)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.110(c)(6)(i) (eCFR anchor p-1910.110(c)(6)(i)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to 29 CFR 1910.110(b)(14)(vii) (eCFR anchor p-1910.110(b)(14)(vii)); 29 CFR 1910.110(c)(6)(i) (eCFR anchor p-1910.110(c)(6)(i)) and to observable material such as facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [29 CFR 1910.110 – Storage and handling of liquefied petroleum gases](https://www.ecfr.gov/current/title-29/section-1910.110) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.110 - Storage and handling of liquefied petroleum gases - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.110 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Inspect LPG installations as systems, not isolated tanks,” DSE Security, https://update.dsesecurity.com/updates/inspect-lpg-installations-as-systems-not-isolated-tanks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inspect PowerShell module-path changes when Windows Admin Center setup will not load > What configuration should be checked when the Windows Admin Center installer fails to load? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-083-inspect-powershell-module-path-changes-when-windows-admin-center-setup-will-not/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:48+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What configuration should be checked when the Windows Admin Center installer fails to load? ## Potentially affected Use this review for an installer-loading failure with an identified Windows Admin Center version. ## DSE recommendation Capture the original installer error and the current module-path value before changing it. ## Article ## Source facts Microsoft’s troubleshooting reference separates general Windows Admin Center issues from known issues affecting individual tools. It identifies a modified or missing default PowerShell module path as one cause of an installer that will not load. The documented correction places the Windows PowerShell Modules directory first in PSModulePath. For a browser-side failure, Microsoft separately recommends checking whether Windows Admin Center is running. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/support/troubleshooting). ## Applicability Use this review for an installer-loading failure with an identified Windows Admin Center version. Distinguish that symptom from a gateway that installed but will not open or a tool that fails inside an otherwise working session. ## DSE recommendation Capture the original installer error and the current module-path value before changing it. Ask the server owner to identify any intentional customization and review the source’s correction against that configuration. Preserve the original value through the approved change record. Keep browser and service-status checks separate so evidence from a different failure stage does not drive the fix. ## Verification Retry the installer only after the approved path correction and record whether the original loading failure recurs. If installation completes, verify that the intended Windows Admin Center instance opens. Retain the before-and-after module path and outcome. Escalate a continuing failure with the exact stage and version instead of repeatedly applying unrelated troubleshooting steps. ## Official references [Microsoft Learn: Windows Admin Center common troubleshooting steps](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/support/troubleshooting). Source reviewed September 8, 2026. ## Primary reference - Name: Windows Admin Center common troubleshooting steps - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/support/troubleshooting - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Inspect PowerShell module-path changes when Windows Admin Center setup will not load,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-083-inspect-powershell-module-path-changes-when-windows-admin-center-setup-will-not/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inspect the fence line as one continuous perimeter—including the openings below it > A perimeter fails at transitions: washed-out grade, loose fabric, a culvert, utility opening, wall junction, temporary repair, unsecured gate edge, climbable object, corrosion, or vegetation that hides damage. - Canonical URL: https://update.dsesecurity.com/updates/inspect-fence-line-continuous-perimeter-openings-below/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:27:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control - Reading time: 3 minutes ## What you need to know A perimeter fails at transitions: washed-out grade, loose fabric, a culvert, utility opening, wall junction, temporary repair, unsecured gate edge, climbable object, corrosion, or vegetation that hides damage. ## Potentially affected Security fencing, posts, fabric or panels, foundations, anti-climb features, gates and hinges, wall and building transitions, culverts, drains, utility openings, clear zones, vegetation, lighting coordination, locks, repairs, and patrol records. ## DSE recommendation Give the entire perimeter stable segment identifiers, document its design basis, inspect each segment and transition from both sides, control openings and climb aids, prioritize defects by exposure, and verify permanent repairs against approved details. ## Article ## Source facts: perimeter design extends beyond the visible fence fabric The Department of Defense’s [UFC 4-022-03, Security Fences and Gates](https://www.wbdg.org/FFC/DOD/UFC/ufc_4_022_03_2013.pdf) provides a unified approach to selecting, designing, and installing security fences and gates. It describes fences as measures used to define protected perimeters, deter entry, and support access control. The guidance connects the selected fence with risk assessment, site conditions, clear zones, gates, terrain, drainage, utilities, lighting, and other security measures. The UFC specifically addresses openings that cross or pass through a perimeter. Culverts, storm drains, sewers, tunnels, and utility openings can require protective measures based on their dimensions and location. It also addresses changes in grade, bottom clearance, fence attachments, intersections, corrosion, and access for maintenance. A visually intact straight run does not prove that the perimeter is continuous. This UFC is mandatory only in its defined DoD scope. Its drawings are notional or minimum military details that must be adapted for local constraints. A commercial property should use its own risk assessment, approved design, land and utility rights, accessibility obligations, safety rules, environmental conditions, code, and insurer or authority requirements. The article does not prescribe military dimensions or anti-climb features for private sites. ## DSE recommendation: inspect by segment, transition, and function Create a perimeter register and map. Assign a durable identifier to every run, corner, gate, building or wall tie-in, elevation change, water crossing, culvert, drain, utility penetration, temporary section, and adjacent area outside the organization’s control. Record the approved design, material, height, bottom condition, clear-zone assumptions, ownership, and inspection access. - Walk both sides where lawful and safe. View the perimeter in each direction and at ground level. Look for cut, spread, lifted, loose, missing, or deformed fabric or panels; unstable posts; cracked foundations; loose fasteners; failed ties; damaged caps; exposed sharp edges; corrosion; rot; erosion; undermining; animal burrows; and debris. - Challenge every transition. Examine corners, changes in fence type or height, gate-to-fence gaps, hinges, latch edges, wall attachments, roof or canopy approaches, retaining walls, ditches, steep slopes, and locations where snow or soil changes bottom clearance. Temporary patches need an owner and replacement date. - Account for openings. Inventory drains, culverts, streams, conduits, pipe racks, cable trenches, ventilation openings, and shared utility routes. Verify their approved protective treatment remains secured, serviceable, hydraulically safe, and accessible for authorized maintenance. Do not obstruct drainage or emergency function with an improvised grille. - Preserve observation and delay. Remove or manage vegetation, stored materials, dumpsters, pallets, vehicles, construction equipment, and site furnishings that provide concealment, bridge the clear zone, support climbing, or prevent inspection. Coordinate environmental, neighbor, and property-line restrictions. - Exercise gates as part of the line. Check leaves, rollers, tracks, hinges, stops, locks, drop rods, guides, ground gaps, protective devices, emergency access, and closed alignment. Follow the separate approved safety procedure for powered gates; do not defeat entrapment protection to tighten security. - Escalate by exposure. Treat a person-passable breach, failed critical gate, or uncontrolled opening as an active security condition. Establish a guard, alternate barrier, access restriction, or other approved interim control, notify the owner, and document repair and verification. Inspect after storms, flooding, freeze-thaw cycles, vehicle impact, excavation, utility work, construction, vegetation clearing, reported trespass, or unexplained alarm activity—not only on a calendar. Compare repeated observations by segment to identify corrosion, movement, or erosion before a visible breach develops. Measure completion by restored function, not a closed work order. Photograph the identified defect, approved temporary control, permanent repair, and verification from consistent viewpoints. A credible perimeter record shows that each line, transition, opening, and gate still provides the delay and channeling assumed by the site security plan. ## Official references - U.S. Department of Defense, [UFC 4-022-03, Security Fences and Gates](https://www.wbdg.org/FFC/DOD/UFC/ufc_4_022_03_2013.pdf), October 1, 2013. - Whole Building Design Guide, [Corrosion Prevention and Control: Fencing Knowledge Area](https://www.wbdg.org/dod/cpc-source/fencing-knowledge-area). ## Primary reference - Name: DoD UFC 4-022-03: Security Fences and Gates - Authority: www.wbdg.org - URL: https://www.wbdg.org/FFC/DOD/UFC/ufc_4_022_03_2013.pdf - Source publication date: 2013-10-01 ## Citation and use Preferred citation: “Inspect the fence line as one continuous perimeter—including the openings below it,” DSE Security, https://update.dsesecurity.com/updates/inspect-fence-line-continuous-perimeter-openings-below/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inspect, test, calibrate, and repair maritime-security systems on schedule > Use 33 CFR 105.250 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/inspect-test-calibrate-and-repair-maritime-security-systems-on-schedule/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:12+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.250 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.250 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Inspect, test, calibrate, and repair maritime-security systems on schedule. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.250 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.250) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that security systems and equipment be in good working order and inspected, tested, calibrated, and maintained according to manufacturers’ recommendations. The research record locates this support at 33 CFR 105.250(a) (eCFR anchor p-105.250(a)). - Under 33 CFR 105, the rule requires that security systems be regularly tested in accordance with the manufacturers’ recommendations; noted deficiencies corrected promptly; and the results recorded as required in section 105.225 of this subpart. The research record locates this support at 33 CFR 105.250(b) (eCFR anchor p-105.250(b)). Keep the evidence boundary at these traced claims. They support a review of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.250(a) (eCFR anchor p-105.250(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.250(b) (eCFR anchor p-105.250(b)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 33 CFR 105.250(a) (eCFR anchor p-105.250(a)); 33 CFR 105.250(b) (eCFR anchor p-105.250(b)). Favor facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [33 CFR 105.250 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.250) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.250 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.250 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Inspect, test, calibrate, and repair maritime-security systems on schedule,” DSE Security, https://update.dsesecurity.com/updates/inspect-test-calibrate-and-repair-maritime-security-systems-on-schedule/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Install the DHCP relay role on the intended remote subnet > Which Windows Server role supplies DHCP relay, and what must exist on the server side? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-101-install-the-dhcp-relay-role-on-the-intended-remote-subnet/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:30+00:00 - Modified: 2026-09-08T18:23:26+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which Windows Server role supplies DHCP relay, and what must exist on the server side? ## Potentially affected Administrators deploying a Windows Server DHCP relay agent between subnets. ## DSE recommendation Prepare a diagram linking one client subnet to its relay and intended DHCP scope. ## Article ## Source facts A DHCP relay forwards client broadcasts toward a DHCP server on another subnet, allowing that server to supply addresses and configuration. Microsoft’s prerequisites include a Windows Server computer in the remote subnet and a DHCP server with a scope for that subnet. The relay belongs to the Remote Access role. Installing the DHCP Server role does not install this relay feature. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-deploy-relay-agent). ## Applicability Identify the client subnet, relay interfaces, destination DHCP servers, and scope configuration. Review any existing relay devices and the intended network path before adding another forwarding point. ## DSE recommendation Prepare a diagram linking one client subnet to its relay and intended DHCP scope. Have the routing and address-management owners approve the interface and destination choices. Record the role installation and Routing and Remote Access configuration separately so another administrator can reproduce the intended forwarding path. ## Verification Use a controlled client lease request on the remote subnet and inspect the resulting address and options. Correlate client, relay, and server observations for that request. Repeat for each configured subnet and preserve timeouts or an unexpected scope assignment as failures requiring investigation before broader use. ## Official references [Microsoft Learn: Install DHCP relay agent for Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-deploy-relay-agent). Source reviewed September 8, 2026. ## Primary reference - Name: Install DHCP relay agent for Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-deploy-relay-agent - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Install the DHCP relay role on the intended remote subnet,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-101-install-the-dhcp-relay-role-on-the-intended-remote-subnet/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Install-ADServiceAccount: install adservice account against recorded identity and DNS state > Use Install-ADServiceAccount to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/install-adserviceaccount-install-adservice-account-against-recorded-identity-and-dns-state/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:18+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Install-ADServiceAccount to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Install-ADServiceAccount ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Install-ADServiceAccount: install adservice account against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Install-ADServiceAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/install-adserviceaccount?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Installs an Active Directory managed service account on a computer or caches a group managed service account on a computer.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Install-ADServiceAccount cmdlet installs an existing Active Directory managed service account on the computer on which the cmdlet is run.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from SYNOPSIS; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-188 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Install-ADServiceAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/install-adserviceaccount?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Install-ADServiceAccount - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/install-adserviceaccount?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Install-ADServiceAccount: install adservice account against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/install-adserviceaccount-install-adservice-account-against-recorded-identity-and-dns-state/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Integrate fingerprint-based criminal-history checks into nuclear access decisions > Use 10 CFR 73.57 - Criminal history records checks to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/integrate-fingerprint-based-criminal-history-checks-into-nuclear-access-decisions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:43+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.57 - Criminal history records checks to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.57 - Criminal history records checks ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Integrate fingerprint-based criminal-history checks into nuclear access decisions. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.57 – Criminal history records checks](https://www.ecfr.gov/current/title-10/section-73.57) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, the rule requires that the licensee retain all fingerprint and criminal history records received from the FBI, or a copy if the individual’s file has been transferred, on an individual (including data indicating no record) for one year after termination or denial of unescorted access to the nuclear power facility, the non-power reactor facility, or access to Safeguards Information. The research record locates this support at 10 CFR 73.57(f)(5) (eCFR anchor p-73.57(f)(5)). - Under 10 CFR 73, except those listed in paragraph (b)(2) of this section, each licensee subject to the provisions of this section must fingerprint each individual who is permitted unescorted access to the nuclear power facility, the non-power reactor facility in accordance with paragraph (g) of this section, or access to Safeguards Information. The research record locates this support at 10 CFR 73.57(b)(1) (eCFR anchor p-73.57(b)(1)). Only the traced statements above are asserted as source facts. Apply the review to credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces after confirming that the source and deployed context match. ## What the source does not establish NRC regulation with defined covered populations and procedures; privacy, notices, record handling, exceptions, appeals, and other authorization factors require full-rule review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.57(f)(5) (eCFR anchor p-73.57(f)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.57(b)(1) (eCFR anchor p-73.57(b)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to 10 CFR 73.57(f)(5) (eCFR anchor p-73.57(f)(5)); 10 CFR 73.57(b)(1) (eCFR anchor p-73.57(b)(1)) and to observable material such as approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [10 CFR 73.57 – Criminal history records checks](https://www.ecfr.gov/current/title-10/section-73.57) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.57 - Criminal history records checks - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.57 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Integrate fingerprint-based criminal-history checks into nuclear access decisions,” DSE Security, https://update.dsesecurity.com/updates/integrate-fingerprint-based-criminal-history-checks-into-nuclear-access-decisions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Integrate hospital emergency planning with patient care, utilities, and exercises > Use 42 CFR 482.15 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/integrate-hospital-emergency-planning-with-patient-care-utilities-and-exercises/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:05+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 482.15 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 482.15 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Integrate hospital emergency planning with patient care, utilities, and exercises. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 482.15 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-482.15) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 482, the rule requires that if elected, the unified and integrated emergency preparedness program include integrated policies and procedures that meet the requirements set forth in paragraph (b) of this section, a coordinated communication plan and training and testing programs that meet the requirements of paragraphs (c) and (d) of this section, respectively. The research record locates this support at 42 CFR 482.15(f)(5), read with 42 CFR 482.15(f) (eCFR anchor p-482.15(f)(5)). - Under 42 CFR 482, the rule requires that the hospital develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 482.15(d) (eCFR anchor p-482.15(d)). Keep the evidence boundary at these traced claims. They support a review of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Hospital-specific federal condition of participation; emergency power, patient care, staffing, accreditation, state law, waivers, and survey guidance require complete-section review. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 482.15(f)(5), read with 42 CFR 482.15(f) (eCFR anchor p-482.15(f)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 482.15(d) (eCFR anchor p-482.15(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to 42 CFR 482.15(f)(5), read with 42 CFR 482.15(f) (eCFR anchor p-482.15(f)(5)); 42 CFR 482.15(d) (eCFR anchor p-482.15(d)) and to observable material such as business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [42 CFR 482.15 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-482.15) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 482.15 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-482.15 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Integrate hospital emergency planning with patient care, utilities, and exercises,” DSE Security, https://update.dsesecurity.com/updates/integrate-hospital-emergency-planning-with-patient-care-utilities-and-exercises/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Interpret Content-Disposition separately from media type and filename safety > Use RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:01+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Interpret Content-Disposition separately from media type and filename safety. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field](https://www.rfc-editor.org/rfc/rfc2183.html) from RFC Editor supports the following bounded statements: - Content-Disposition says whether a MIME body part is intended for automatic inline presentation or for user-initiated attachment handling; it does not define the media format. The research record locates this support at Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type). - A filename parameter is only a suggestion: the receiver checks local syntax and safety, avoids overwrites, and ignores any directory path in the supplied value. The research record locates this support at Section 2.3 (The Filename Parameter). - A receiver ignores unknown disposition parameters and treats an unknown disposition type as attachment rather than displaying it inline. The research record locates this support at Section 2.8 (Future Extensions and Unrecognized Disposition Types). Keep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.3 (The Filename Parameter), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2.8 (Future Extensions and Unrecognized Disposition Types), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and sanitize protected material before retention. ## Verification and evidence Keep the source locations Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type); Section 2.3 (The Filename Parameter); Section 2.8 (Future Extensions and Unrecognized Disposition Types) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field](https://www.rfc-editor.org/rfc/rfc2183.html) — RFC Editor ## Primary reference - Name: RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2183.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Interpret Content-Disposition separately from media type and filename safety,” DSE Security, https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Interpret Defender for Identity detections as correlated behavioral signals > Use Microsoft Defender for Identity overview to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/interpret-defender-identity-detections-correlated-behavioral-signals/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:08+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Microsoft Defender for Identity overview to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft Defender for Identity overview ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Interpret Defender for Identity detections as correlated behavioral signals. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft Defender for Identity overview](https://learn.microsoft.com/en-us/defender-for-identity/what-is) from Microsoft supports the following bounded statements: - Defender for Identity monitors signals from on-premises Active Directory, Microsoft Entra ID, and other IAM systems such as Okta, analyzing them with behavioral analytics, threat intelligence, and known attack patterns. The research record locates this support at In this article > opening overview. - The product evaluates human and non-human identities by correlating signals and applying behavioral analysis instead of judging one event in isolation. The research record locates this support at Defender for Identity capabilities > Detect identity-based threats. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows and the conditions the source actually describes. ## What the source does not establish Signal correlation does not prove an alert is malicious, guarantee coverage, or replace investigation of the identities, telemetry, timing, and product integrations involved. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at In this article > opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Defender for Identity capabilities > Detect identity-based threats, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from In this article > opening overview; Defender for Identity capabilities > Detect identity-based threats to the observed environment. Useful domain evidence includes alert records, investigation timelines, analyst actions, tuning or exclusion approvals, remediation results, and case closure; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Microsoft Defender for Identity overview](https://learn.microsoft.com/en-us/defender-for-identity/what-is) — Microsoft ## Primary reference - Name: Microsoft Defender for Identity overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/what-is - Source publication date: 2026-07-23 ## Citation and use Preferred citation: “Interpret Defender for Identity detections as correlated behavioral signals,” DSE Security, https://update.dsesecurity.com/updates/interpret-defender-identity-detections-correlated-behavioral-signals/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Interpret Hyper-V extended ACL direction from the VM perspective > How should an extended virtual-switch ACL define traffic direction and scope? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-217-interpret-hyper-v-extended-acl-direction-from-the-vm-perspective/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:34+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know How should an extended virtual-switch ACL define traffic direction and scope? ## Potentially affected Administrators configuring extended port ACLs on Hyper-V VM network adapters. ## DSE recommendation Write the intended allowed and denied flows in a small matrix and have a second reviewer translate each into the documented direction convention. ## Article ## Source facts Microsoft documents extended ACLs applied to individual VM network adapters on a Hyper-V virtual switch. The rules can match source and destination addresses, protocol, and source and destination ports. In the documented direction convention, inbound means traffic received by the VM and outbound means traffic sent from it. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/create-security-policies-extended-port-access-control-lists). ## Applicability Identify the precise VM adapter and application flow before writing a rule. Review source, destination, protocol, and both port roles from that VM’s perspective. Keep an ACL on the virtual adapter distinct from a host firewall rule or a physical-network filter. ## DSE recommendation Write the intended allowed and denied flows in a small matrix and have a second reviewer translate each into the documented direction convention. Preserve the existing adapter ACLs and name the rollback owner. Pilot one application path, including the reply traffic and a deliberately prohibited source. Avoid broadening a rule simply because its first test was written in the wrong direction. ## Verification Generate the approved test flows from both sides of the VM boundary and record the effective rule and result. Confirm an excluded flow remains blocked while the required transaction works. Recheck the exact adapter association after configuration and document any other filter that affected the observed outcome. ## Official references [Microsoft Learn: Create Security Policies with Extended Port Access Control Lists](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/create-security-policies-extended-port-access-control-lists). Source reviewed September 8, 2026. ## Primary reference - Name: Create Security Policies with Extended Port Access Control Lists - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/create-security-policies-extended-port-access-control-lists - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Interpret Hyper-V extended ACL direction from the VM perspective,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-217-interpret-hyper-v-extended-acl-direction-from-the-vm-perspective/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Interpret Link relation types without dereferencing every target > Use RFC 8288 — Web Linking to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/interpret-link-relation-types-without-dereferencing-every-target/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:52+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8288 — Web Linking to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8288 — Web Linking ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Interpret Link relation types without dereferencing every target. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8288 — Web Linking](https://www.rfc-editor.org/rfc/rfc8288.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A Web link consists of a context IRI, relation type, target IRI, and optional target attributes; serialized link ordering carries no inherent significance. The research record locates this support at Section 2 (Links). - Registered relation names are case-insensitive tokens and cannot constrain context or target representation media types. The research record locates this support at Section 2.1.1 (Registered Relation Types). - An extension relation uses a URI as its identifier, but a client should not automatically dereference that URI merely to learn the relation’s definition. The research record locates this support at Section 2.1.2 (Extension Relation Types). Only the traced statements above are asserted as source facts. Apply the review to clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2 (Links), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.1.1 (Registered Relation Types), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2.1.2 (Extension Relation Types), which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate DNS, certificates, identity providers, time, content delivery, network paths, and application ownership before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations Section 2 (Links); Section 2.1.1 (Registered Relation Types); Section 2.1.2 (Extension Relation Types) adjacent to the sanitized artifacts used for comparison. Prefer request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 8288 — Web Linking](https://www.rfc-editor.org/rfc/rfc8288.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8288 — Web Linking - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8288.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Interpret Link relation types without dereferencing every target,” DSE Security, https://update.dsesecurity.com/updates/interpret-link-relation-types-without-dereferencing-every-target/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Interpret RDS User Input Delay as the slowest queued input in the interval > What does an RDS User Input Delay counter value represent? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-132-interpret-rds-user-input-delay-as-the-slowest-queued-input-in-the-interval/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:59+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What does an RDS User Input Delay counter value represent? ## Potentially affected Administrators diagnosing input responsiveness on supported Windows session hosts. ## DSE recommendation Choose the process or session scope that matches the complaint and record its identity. ## Article ## Source facts The User Input Delay counter measures the time an input waits in a queue before a process handles it, and it applies to both local and remote sessions. Microsoft specifies that the reported value is the maximum delay within the configured interval, rather than the average of all inputs. The tool offers process-level and session-level counters. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-rdsh-performance-counters). ## Applicability Check the source’s counter-specific platform requirements and configuration notes. Identify the affected user session, application, observed time, and collection interval before comparing a reported value with a user complaint. ## DSE recommendation Choose the process or session scope that matches the complaint and record its identity. Ask the application owner to provide a repeatable interaction and a description of acceptable response. Retain the input-delay series alongside resource measurements from the same window. ## Verification Reproduce the interaction and correlate its timing with the maximum delay reported for the selected scope. Compare a normal and degraded run under known conditions. Preserve the interval and instance identifiers, and investigate the association without treating one delay spike as proof of a particular resource bottleneck. ## Official references [Microsoft Learn: Use performance counters to diagnose application responsiveness problems on Remote Desktop session hosts](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-rdsh-performance-counters). Source reviewed September 8, 2026. ## Primary reference - Name: Use performance counters to diagnose application responsiveness problems on Remote Desktop session hosts - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-rdsh-performance-counters - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Interpret RDS User Input Delay as the slowest queued input in the interval,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-132-interpret-rds-user-input-delay-as-the-slowest-queued-input-in-the-interval/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Interpret Remote Access historical reports as sessions > Why should a Remote Access report not be read as a count of distinct people? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-246-interpret-remote-access-historical-reports-as-sessions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:05+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Why should a Remote Access report not be read as a count of distinct people? ## Potentially affected Operators reviewing historical Remote Access usage reports after accounting is enabled. ## DSE recommendation Write the reporting question and time range before exporting results. ## Article ## Source facts Microsoft requires Remote Access accounting to be configured before historical usage reports can be generated. The reporting view supports a selected time period and presents user activity and load statistics. Remote Access accounting identifies a session by the combination of the remote client address and user name, rather than treating it simply as a connection. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/remote/remote-access/ras/monitoring-and-accounting/Generate-a-usage-report-for-remote-clients-using-historical-data). ## Applicability Use the report for the interval and accounting configuration that actually produced it. State whether the question concerns session activity, client addresses, identities, or business users. Avoid silently substituting one of those populations for another in an operational summary. ## DSE recommendation Write the reporting question and time range before exporting results. Have the Remote Access owner explain how session records will be grouped for that question and how machine and user activity will be distinguished where relevant. Restrict access to the identity and address data. Include the report filters and interpretation rules with the output so recipients do not mistake a raw session total for a personnel measure. ## Verification Compare a small, authorized sample of known activity with the corresponding session records. Check the interval boundaries, identity values, and remote addresses used in the comparison. Note missing accounting coverage or ambiguous identity grouping in the report, and resolve those limitations before making a capacity or usage conclusion. ## Official references [Microsoft Learn: Generate a usage report for remote clients using historical data](https://learn.microsoft.com/en-us/windows-server/remote/remote-access/ras/monitoring-and-accounting/Generate-a-usage-report-for-remote-clients-using-historical-data). Source reviewed September 8, 2026. ## Primary reference - Name: Generate a usage report for remote clients using historical data - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-access/ras/monitoring-and-accounting/Generate-a-usage-report-for-remote-clients-using-historical-data - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Interpret Remote Access historical reports as sessions,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-246-interpret-remote-access-historical-reports-as-sessions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Interpret S2D drive history at the device measurement boundary > Which parts of the I/O path are represented by Storage Spaces Direct drive-history counters? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-195-interpret-s2d-drive-history-at-the-device-measurement-boundary/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:56+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which parts of the I/O path are represented by Storage Spaces Direct drive-history counters? ## Potentially affected Administrators interpreting physical-drive performance history in Storage Spaces Direct. ## DSE recommendation Record the drive identity and measurement boundary alongside each performance finding. ## Article ## Source facts Microsoft provides drive history for devices in the cluster storage subsystem, excluding operating-system boot drives. The IOPS, throughput, and latency series come from the connected server’s Physical Disk counters, measured by partmgr.sys. They exclude much of the Windows software stack and network traversal. The values cover the whole interval: Microsoft’s example averages thirty operations in a ten-second interval as three operations per second. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/performance-history-for-drives). ## Applicability Identify the physical drive, connected server, metric, time interval, and application event. Distinguish the device-level observation from an end-to-end application response measurement before attributing a delay. ## DSE recommendation Record the drive identity and measurement boundary alongside each performance finding. Correlate device observations with workload and network evidence from the same period. Ask the investigator to state whether a value is an interval average or another aggregation before comparing it with a threshold. ## Verification Check the requested drive’s series and timestamps and compare them with the planned measurement interval. Investigate a high device latency alongside the remaining I/O path rather than assigning the whole application delay to that drive. Preserve missing history or an excluded boot device as a scope limitation. ## Official references [Microsoft Learn: Performance history for drives](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/performance-history-for-drives). Source reviewed September 8, 2026. ## Primary reference - Name: Performance history for drives - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/performance-history-for-drives - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Interpret S2D drive history at the device measurement boundary,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-195-interpret-s2d-drive-history-at-the-device-measurement-boundary/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Invalidate a domain controller's RID pool and verify the renewal behavior > Use AD Forest Recovery - Invalidating the RID Pool to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/invalidate-domain-controller-rid-pool-verify-renewal/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:25+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use AD Forest Recovery - Invalidating the RID Pool to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of AD Forest Recovery - Invalidating the RID Pool ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Invalidate a domain controller’s RID pool and verify the renewal behavior. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [AD Forest Recovery – Invalidating the RID Pool](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-invaildate-rid-pool) from Microsoft supports the following bounded statements: - Microsoft provides a PowerShell procedure that invalidates the current RID pool on one domain controller. The research record locates this support at Invalidate the current RID pool > PowerShell procedure. - Directory-Services-SAM event 16654 in the System log verifies completion on Windows Server 2012; Microsoft notes that earlier Windows versions do not log this event. The research record locates this support at Invalidate the current RID pool > verification paragraph. - After invalidation, the first security-principal creation attempt fails and requests a new RID pool; retrying succeeds after the new pool is allocated. The research record locates this support at Invalidate the current RID pool > Note. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps and the conditions the source actually describes. ## What the source does not establish The page is a forest-recovery procedure and does not establish that every restored controller requires this action; apply it only to the controller selected by the recovery plan. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Invalidate the current RID pool > PowerShell procedure, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Invalidate the current RID pool > verification paragraph, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Invalidate the current RID pool > Note, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Invalidate the current RID pool > PowerShell procedure; Invalidate the current RID pool > verification paragraph; Invalidate the current RID pool > Note. Favor backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [AD Forest Recovery – Invalidating the RID Pool](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-invaildate-rid-pool) — Microsoft ## Primary reference - Name: AD Forest Recovery - Invalidating the RID Pool - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-invaildate-rid-pool - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Invalidate a domain controller's RID pool and verify the renewal behavior,” DSE Security, https://update.dsesecurity.com/updates/invalidate-domain-controller-rid-pool-verify-renewal/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inventory cryptography before long-lived systems trap it > Post-quantum migration starts with visibility: find where certificates, keys, algorithms, protocols, libraries, firmware, hardware, vendors, data lifetimes, and trust relationships are embedded across IT and physical security. - Canonical URL: https://update.dsesecurity.com/updates/inventory-cryptography-before-long-lived-systems-trap-it/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Guide - DSE priority: Important - Topics: Access Control, Cybersecurity, IT, Networks & Infrastructure, Video Surveillance - Reading time: 4 minutes ## What you need to know Post-quantum migration starts with visibility: find where certificates, keys, algorithms, protocols, libraries, firmware, hardware, vendors, data lifetimes, and trust relationships are embedded across IT and physical security. ## Potentially affected Organizations operating long-lived cameras, recorders, controllers, credentials, PKI, VPNs, remote access, servers, appliances, software, cloud integrations, signed updates, and protected archives. ## DSE recommendation Create an owner-linked cryptographic inventory, prioritize long confidentiality and service lifetimes, require vendor roadmaps and crypto-agility evidence, and test supported migrations without self-designed cryptography. ## Article ## Source fact: standardized post-quantum algorithms are available NIST finalized [FIPS 203](https://csrc.nist.gov/pubs/fips/203/final) for ML-KEM, [FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) for ML-DSA, and [FIPS 205](https://csrc.nist.gov/pubs/fips/205/final) for SLH-DSA in August 2024. NIST says organizations can begin transitioning to these standards now. That does not mean an administrator should manually substitute algorithms in a camera, access panel, VPN, certificate authority, or application; protocols, implementations, interoperability, hardware, and vendor support must be ready. NIST [CSWP 39 Update 1](https://csrc.nist.gov/pubs/cswp/39/upd1/considerations-for-achieving-crypto-agility/final) defines crypto agility as capabilities to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. The NCCoE [Migration to Post-Quantum Cryptography project](https://www.nccoe.nist.gov/applied-cryptography/migration-to-pqc) places cryptographic discovery and inventory at the center of risk management and prioritization. ## Why physical-security estates deserve early attention Security systems often mix long asset lives with embedded firmware, proprietary protocols, appliance operating systems, certificates, smart credentials, signed updates, remote access, cloud services, archived evidence, and integrations that may be difficult to change independently. A product can remain mechanically useful after its cryptographic dependencies become unsupported. Replacing an algorithm may require new firmware, silicon, certificates, readers, credentials, server software, licensing, bandwidth, storage, or an entire integration path. Quantum risk is not the only reason to build visibility. Certificates expire, trust stores age, algorithms are deprecated, libraries reach end of support, keys are exposed, and vendors change services. An inventory built for post-quantum planning also makes ordinary cryptographic transitions less disruptive. ## DSE recommendation: inventory the use, not just the algorithm name For each system and data flow, record: - business service, owner, site, data classification, availability need, confidentiality lifetime, evidence-retention period, and asset replacement horizon; - product, model, hardware revision, firmware or software, library or crypto module, vendor, support end, and management interface; - cryptographic purpose: key establishment, encryption, digital signature, authentication, code signing, credential protection, storage, backup, or audit integrity; - protocol and version, algorithm and parameters where observable, certificate issuer and profile, key location, trust anchor, renewal process, revocation, and recovery; - peer or dependency: camera to recorder, reader to controller, client to server, appliance to cloud, VPN to remote user, update service to device, backup to repository, or exported evidence to verifier; - discovery source, confidence, last verified date, migration option, test environment, vendor commitment, and unresolved exception. Do not collect private keys into the inventory. Record their managed location and custody. Protect the inventory because it maps sensitive trust relationships. ## Prioritize by exposure and time Start with public-key cryptography used to protect data that must remain confidential for many years, internet-facing and remote-access paths, central identity and certificate services, signed software and firmware, high-impact services, hard-to-replace embedded products, and systems with long procurement cycles. Include stored captures and backups: information intercepted today may still be sensitive when future capabilities change the threat. NISTIR 8547 is an initial public draft describing an expected transition approach, not a final universal deadline for every private system. DSE recommends tracking final NIST and sector guidance and mapping it to the organization’s own data lifetimes, products, obligations, and risk tolerance. ## Make vendors show their migration boundary Ask which product versions and cryptographic modules are affected; whether algorithms and certificates can change without hardware replacement; which PQC standards and protocol profiles are planned or supported; whether hybrid or dual-stack modes are available; how rollback and downgrade are controlled; what performance, packet-size, storage, and interoperability testing has been completed; and how long classical and post-quantum modes will coexist. Require dated, product-specific evidence instead of a corporate quantum-ready slogan. ## Test transition as an operational change Use vendor-supported implementations in a representative lab. Validate enrollment, certificate issuance and renewal, mutual authentication, video and access latency, failover, signed update verification, export verification, backup and restore, monitoring, rollback, and mixed-version interoperability. Record capacity and availability effects. Never invent a hybrid construction or deploy a draft algorithm merely to claim readiness. Turn findings into a roadmap: quick configuration changes, software upgrades, certificate-service work, vendor-dependent items, contract requirements, and hardware replacement. Assign owners and decision dates. Crypto agility is achieved when the organization can execute a tested change while preserving security and service—not when a spreadsheet merely lists algorithms. ## Official sources - [NIST CSWP 39 Update 1, Considerations for Achieving Crypto Agility](https://doi.org/10.6028/NIST.CSWP.39-upd1) - [NCCoE Migration to Post-Quantum Cryptography](https://www.nccoe.nist.gov/applied-cryptography/migration-to-pqc) - [NIST PQC Migration FAQ, updated June 30, 2026](https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/) - [Draft NISTIR 8547, Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd) - [NIST Post-Quantum Cryptography program and finalized standards](https://www.nist.gov/pqc) ## Primary reference - Name: NIST CSWP 39 Update 1 — Considerations for Achieving Crypto Agility - Authority: Digital Object Identifier - URL: https://doi.org/10.6028/NIST.CSWP.39-upd1 - Source publication date: 2025-12-19 ## Citation and use Preferred citation: “Inventory cryptography before long-lived systems trap it,” DSE Security, https://update.dsesecurity.com/updates/inventory-cryptography-before-long-lived-systems-trap-it/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inventory default domain-controller accounts before changing them > Use Active Directory Accounts to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/inventory-default-dc-accounts-before-change/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:54+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Active Directory Accounts to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Active Directory Accounts ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Inventory default domain-controller accounts before changing them. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Active Directory Accounts](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts) from Microsoft supports the following bounded statements: - Windows Server installs default accounts and organizations can create additional accounts for their requirements. The research record locates this support at Opening overview. - The reference covers default local accounts stored on domain controllers for Active Directory use, not member-server or client local accounts. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Do not rename, disable, or delegate a default account without checking its documented purpose and dependencies. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Active Directory Accounts](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts) — Microsoft ## Primary reference - Name: Active Directory Accounts - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-default-user-accounts - Source publication date: 2025-06-30 ## Citation and use Preferred citation: “Inventory default domain-controller accounts before changing them,” DSE Security, https://update.dsesecurity.com/updates/inventory-default-dc-accounts-before-change/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inventory service accounts with their recent authentication context > Use Investigate and protect Service Accounts to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/inventory-service-accounts-with-recent-authentication-context/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:12+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Investigate and protect Service Accounts to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Investigate and protect Service Accounts ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Inventory service accounts with their recent authentication context. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Investigate and protect Service Accounts](https://learn.microsoft.com/en-us/defender-for-identity/service-account-discovery) from Microsoft supports the following bounded statements: - Service accounts often have elevated privileges but generally cannot use modern authentication protections such as MFA in the same way as human accounts. The research record locates this support at Opening risk overview. - Automatic discovery identifies gMSA and sMSA accounts and user accounts meeting criteria such as an SPN plus password-never-expires, and presents recent authentication sources and destinations. The research record locates this support at Auto-discovery section. The source support ends with the statements listed above. Use them to examine identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Classification criteria identify candidates, not confirmed business purpose, ownership, necessity, or compromise. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening risk overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Auto-discovery section, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening risk overview; Auto-discovery section. Favor alert records, investigation timelines, analyst actions, tuning or exclusion approvals, remediation results, and case closure, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Investigate and protect Service Accounts](https://learn.microsoft.com/en-us/defender-for-identity/service-account-discovery) — Microsoft ## Primary reference - Name: Investigate and protect Service Accounts - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/service-account-discovery - Source publication date: 2025-03-25 ## Citation and use Preferred citation: “Inventory service accounts with their recent authentication context,” DSE Security, https://update.dsesecurity.com/updates/inventory-service-accounts-with-recent-authentication-context/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Inventory trusted RDP publishers before restricting which files can open > Which RDP files and launch paths would a trusted-publisher-only policy block? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-142-inventory-trusted-rdp-publishers-before-restricting-which-files-can-open/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:49+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which RDP files and launch paths would a trusted-publisher-only policy block? ## Potentially affected Administrators reviewing Group Policy controls for Remote Desktop Connection RDP files. ## DSE recommendation Build an inventory of approved signed files and their publisher identities. ## Article ## Source facts RDP file policies control which configuration files the Remote Desktop Connection client can open. One configuration documented by Microsoft permits only files signed by publishers that are explicitly trusted. It also blocks valid signatures from untrusted publishers and connections started directly through the client’s interface. The settings are available under the Remote Desktop Connection Client policy branch, with configuration details in each policy’s Help text. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/manage-rdp-file-security-settings-with-group-policy). ## Applicability Identify the installed client updates, actual policy definitions, RDP publishers, unsigned files, and support workflows. Review which users connect through files and which use the client interface before selecting a restriction. ## DSE recommendation Build an inventory of approved signed files and their publisher identities. Ask service owners to identify legitimate unsigned or interface-launched connections that require a migration decision. Pilot the proposed policy with clear support instructions and retain the existing policy settings. ## Verification Test a trusted file, a validly signed file from an untrusted publisher, an unsigned file, and a direct client launch. Record the observed acceptance or rejection for each. Resolve any required workflow that is blocked unexpectedly before applying the setting across managed endpoints. ## Official references [Microsoft Learn: RDP file security in Group Policy on Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/manage-rdp-file-security-settings-with-group-policy). Source reviewed September 8, 2026. ## Primary reference - Name: RDP file security in Group Policy on Windows and Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/manage-rdp-file-security-settings-with-group-policy - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Inventory trusted RDP publishers before restricting which files can open,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-142-inventory-trusted-rdp-publishers-before-restricting-which-files-can-open/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Investigate Active Directory accounts with no logon in 90 days > Use Accounts security posture assessments to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/investigate-active-directory-accounts-with-no-logon-in-90-days/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:03+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Accounts security posture assessments to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Accounts security posture assessments ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Investigate Active Directory accounts with no logon in 90 days. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Accounts security posture assessments](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/accounts) from Microsoft supports the following bounded statements: - The stale-account recommendation lists Active Directory user accounts that have not logged in during the previous 90 days. The research record locates this support at Stale account recommendation description. - The page says impacted entities can update within minutes after remediation while assessment scores and statuses update every 24 hours. The research record locates this support at Opening update-cadence note. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking only where the source and recorded environment align. ## What the source does not establish A 90-day threshold is a detection criterion, not proof that an account lacks a valid owner, seasonal purpose, or recovery dependency. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Stale account recommendation description, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening update-cadence note, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations Stale account recommendation description; Opening update-cadence note adjacent to the sanitized artifacts used for comparison. Prefer affected-entity lists, directory attributes, relationship paths, assessment timestamps, remediation tests, and accepted exceptions, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Accounts security posture assessments](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/accounts) — Microsoft ## Primary reference - Name: Accounts security posture assessments - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/accounts - Source publication date: 2026-08-18 ## Citation and use Preferred citation: “Investigate Active Directory accounts with no logon in 90 days,” DSE Security, https://update.dsesecurity.com/updates/investigate-active-directory-accounts-with-no-logon-in-90-days/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Investigate an NCSI connectivity indicator using the network transition that triggered it > How should administrators investigate a Windows connectivity indicator after a network change? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-005-investigate-an-ncsi-connectivity-indicator-using-the-network-transition-that/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:17:06+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How should administrators investigate a Windows connectivity indicator after a network change? ## Potentially affected Use this review for an unexpected Windows connectivity indication after connecting or changing networks. ## DSE recommendation Build a timeline from the actual transition: connection establishment, portal interaction, and the indicator shown to the user. ## Article ## Source facts NCSI sends active connectivity probes when a network interface becomes usable after changed conditions, including wired, wireless, and VPN connections. After a successful probe without a proxy, NCSI records that condition and updates the connectivity indicator. A captive portal that still requires input can leave the interface classified as local connectivity. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-frequently-asked-questions). ## Applicability Use this review for an unexpected Windows connectivity indication after connecting or changing networks. Record the interface, connection method, portal state, and any proxy involvement before selecting a troubleshooting step. ## DSE recommendation Build a timeline from the actual transition: connection establishment, portal interaction, and the indicator shown to the user. Compare the indicator with access to the particular business application being investigated. Preserve the network conditions during reproduction and change one approved variable at a time. Ask the network owner to review any proposed probe or proxy policy change. ## Verification Repeat the connection in an approved test and record when the indicator changes. For portal networks, record the state before and after completing the required interaction. Retain evidence for both the probe path and the business application path. If they disagree, describe the disagreement precisely instead of closing the incident solely because one test succeeds. ## Official references [Microsoft Learn: Network Connectivity Status Indicator FAQ for Windows](https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-frequently-asked-questions). Source reviewed September 8, 2026. ## Primary reference - Name: Network Connectivity Status Indicator FAQ for Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-frequently-asked-questions - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Investigate an NCSI connectivity indicator using the network transition that triggered it,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-005-investigate-an-ncsi-connectivity-indicator-using-the-network-transition-that/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Investigate and remediate risky Microsoft Entra users with evidence > Microsoft Entra ID Protection can support automatic and manual risk remediation, but each action must follow investigation and preserve the distinction between password change, account recovery, and risk dismissal. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:53+00:00 - Modified: 2026-07-19T21:27:53+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 2 minutes ## What you need to know Microsoft Entra ID Protection can support automatic and manual risk remediation, but each action must follow investigation and preserve the distinction between password change, account recovery, and risk dismissal. ## Potentially affected Microsoft Entra tenants using ID Protection risk detections, risk-based Conditional Access, self-service password reset, password hash synchronization, or hybrid identities. ## DSE recommendation Collect the risk and session evidence, validate the user independently, contain suspected compromise, choose the documented remediation path, and record why risk was remediated, dismissed, or left under investigation. ## Article ## Source fact: what Microsoft documents Microsoft Entra ID Protection calculates user risk from active detections and supports both policy-based self-remediation and administrator action. A sign-in-risk policy can require multifactor authentication; successful completion can remediate that sign-in risk. A user-risk policy can require multifactor authentication followed by a secure password change. Microsoft distinguishes that password-change flow from self-service password reset, which is an account-recovery flow for a user who does not know the current password. If the user cannot satisfy the policy requirement, the sign-in can be blocked and an administrator must investigate and unblock the user. Some detections do not reach the configured threshold or are not automatically remediated, so manual handling remains necessary. Microsoft documents User Administrator as the least-privileged role for password reset, Security Operator for dismissing risk, Security Administrator for risk policies, and Conditional Access Administrator for Conditional Access policies. ## Licensing and hybrid boundaries Full ID Protection capability requires Microsoft Entra ID P2 or Microsoft Entra Suite licensing. Hybrid users have additional dependencies. Microsoft documents on-premises password-change remediation when password hash synchronization is enabled and the tenant explicitly enables the applicable setting. That behavior must be tested before relying on it. Risk data is a security signal, not proof by itself that an account is compromised or safe. ## DSE recommendation: production-safe operational steps - Capture the detection type, risk level and state, user, time, IP address, location, client, device, application, correlation or request identifiers, and related sign-ins before changing the record. - Validate the user’s activity through an independent trusted channel. Do not ask the user to confirm a suspicious session through that same session. - If compromise is plausible, block access as appropriate, revoke sessions, protect privileged or sensitive resources, and preserve relevant logs before credential remediation. - Use secure password change for the documented user-risk self-remediation flow. Use SSPR or an administrator reset when the user requires account recovery. Review registered authentication methods in either case. - Dismiss risk only when the evidence supports a false positive or safe event and record the reviewer, evidence, and reason. A dismissal is an administrative assertion, not containment. - Review role assignments, consent grants, mailbox rules, device registrations, authentication methods, and other activity appropriate to the suspected compromise. - Close the event only after access, session, credential, and monitoring actions are verified. DSE recommends testing risk policies with pilot users, emergency-access exclusions, and help-desk procedures before broad enforcement. If telemetry is incomplete, preserve uncertainty in the ticket and escalate; do not convert a lack of evidence into a claim that no compromise occurred. ## Official reference [Remediate risks and unblock users](https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-remediate-unblock) — licensing, least-privileged roles, self-remediation, password flows, hybrid behavior, and manual actions. ## Primary reference - Name: Microsoft Learn: Remediate risks and unblock users - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-remediate-unblock - Source publication date: 2026-05-27 ## Citation and use Preferred citation: “Investigate and remediate risky Microsoft Entra users with evidence,” DSE Security, https://update.dsesecurity.com/updates/microsoft-entra-risky-user-remediation-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Investigate detached Storage Spaces Direct volumes beyond physical-disk health > Why should a detached virtual disk be investigated even when physical disks report healthy? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-071-investigate-detached-storage-spaces-direct-volumes-beyond-physical-disk-health/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:00+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Why should a detached virtual disk be investigated even when physical disks report healthy? ## Potentially affected Use this review when virtual-disk availability and physical-disk health appear inconsistent. ## DSE recommendation Preserve both virtual-disk and physical-disk observations before attempting repair. ## Article ## Source facts Microsoft documents a Storage Spaces Direct condition in which Get-VirtualDisk reports Detached while Get-PhysicalDisk reports the underlying disks as Healthy. It separately describes virtual disks failing to come online with insufficient redundancy information after unexpected node restarts. The troubleshooting guidance calls for checking drive support, hardware condition, firmware, updates, and the Storage Spaces Direct section of cluster validation. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/troubleshooting-storage-spaces). ## Applicability Use this review when virtual-disk availability and physical-disk health appear inconsistent. Identify the affected virtual disk, pool, nodes, and recent restart or power events. Select the source section matching the observed symptom and software version. ## DSE recommendation Preserve both virtual-disk and physical-disk observations before attempting repair. Build a timeline of the preceding node events and gather the corresponding validation and hardware information. Assign the investigation to the storage owner and involve the vendor when hardware support or health is uncertain. Keep an unrelated healthy physical-disk result from closing a virtual-disk availability incident. ## Verification After an approved corrective action, inspect the virtual disk’s operational state and verify the intended workload access. Compare the result with the original symptom and retained event timeline. Record redundancy and hardware findings separately. Escalate unresolved disagreement between layers instead of repeatedly changing storage settings without an identified cause. ## Official references [Microsoft Learn: Storage Spaces Direct troubleshooting](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/troubleshooting-storage-spaces). Source reviewed September 8, 2026. ## Primary reference - Name: Storage Spaces Direct troubleshooting - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/troubleshooting-storage-spaces - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Investigate detached Storage Spaces Direct volumes beyond physical-disk health,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-071-investigate-detached-storage-spaces-direct-volumes-beyond-physical-disk-health/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Investigate Program 2 incidents promptly and track corrective actions > Use 40 CFR 68.60 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/investigate-program-2-incidents-promptly-and-track-corrective-actions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:03+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.60 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.60 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Investigate Program 2 incidents promptly and track corrective actions. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.60 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.60) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the owner or operator promptly address and resolve the investigation findings and recommendations. The research record locates this support at 40 CFR 68.60(e) (eCFR anchor p-68.60(e)). - Under 40 CFR 68, the rule requires that the owner or operator investigate each incident which resulted in, or could reasonably have resulted in a catastrophic release. The research record locates this support at 40 CFR 68.60(a) (eCFR anchor p-68.60(a)). Only the traced statements above are asserted as source facts. Apply the review to essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives after confirming that the source and deployed context match. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.60(e) (eCFR anchor p-68.60(e)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.60(a) (eCFR anchor p-68.60(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to 40 CFR 68.60(e) (eCFR anchor p-68.60(e)); 40 CFR 68.60(a) (eCFR anchor p-68.60(a)) and to observable material such as business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [40 CFR 68.60 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.60) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.60 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.60 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Investigate Program 2 incidents promptly and track corrective actions,” DSE Security, https://update.dsesecurity.com/updates/investigate-program-2-incidents-promptly-and-track-corrective-actions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Investigate risky workload identities separately from risky users > Microsoft Entra ID Protection has workload-identity risk reports and remediation guidance, but workload identities cannot complete user MFA and the documented detection scope excludes some identity types. - Canonical URL: https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:24+00:00 - Modified: 2026-08-25T21:36:18+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Microsoft Entra ID Protection has workload-identity risk reports and remediation guidance, but workload identities cannot complete user MFA and the documented detection scope excludes some identity types. ## Potentially affected Organizations with Microsoft Entra application registrations and service principals, especially those using workload identity credentials for unattended access. ## DSE recommendation Inventory the credential and permissions of each flagged service principal, preserve evidence, contain based on business impact, rotate affected credentials, and verify dependent automation afterward. ## Article Bottom line: A workload identity is not a user account. It cannot respond to MFA, may use stored credentials, and often lacks a formal lifecycle. Microsoft Entra ID Protection provides workload-identity risk detections and reports for supported service principals, but its scope and licensing differ from user-risk protection. ## Source fact: what Microsoft documents Microsoft’s [workload-identity risk documentation](https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk) describes detections based on sign-in behavior and offline indicators. Documented examples include Microsoft Entra threat intelligence, suspicious sign-ins, and suspicious API traffic. Administrators can review risky workload identities and workload-identity risk detections or query the corresponding Microsoft Graph collections. Microsoft states that the feature’s risk scope covers specified application and service-principal scenarios and that managed identities are not currently in scope. Full risk detail and risk-based access controls have licensing requirements. Conditional Access for workload identities can block selected service principals marked at risk, but documented resource and identity limitations apply. Microsoft’s remediation sequence includes inventorying credentials, adding a new credential, removing compromised credentials, and rotating Key Vault secrets the identity could access. ## What the source does not establish A risk detection is not proof that an application was compromised, and the absence of a detection is not proof that a workload identity is safe. The feature does not inventory all secrets, certificates, federated credentials, API keys, managed identities, permissions, or downstream sessions. Disabling a service principal can interrupt business services, while rotating only one credential may leave other persistence intact. ## Applicability questions - Is the flagged object a supported single-tenant service principal, a multitenant application, Microsoft SaaS object, or managed identity? - What credentials exist on both application and service-principal objects, and where are copies stored? - Which Graph, Azure, Microsoft 365, Key Vault, and third-party permissions can it exercise? - Which owners, jobs, applications, and customers depend on it, and what is the containment impact? - Are the required reports, detail, exports, and Conditional Access controls licensed and available? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Preserve the risk record, sign-in evidence, object identifiers, owners, credentials, permissions, and recent configuration changes before cleanup. - Compare observed IPs, resources, user agents, API calls, and credential use with the application’s documented baseline. - If compromise is plausible, contain according to consequence: disable the service principal or restrict its access when operationally safe, and coordinate an outage path when it is not. - Add a known-good credential using the supported application design, remove all suspect credentials, and rotate reachable secrets or downstream credentials. - Revalidate permissions, owners, automation, and monitoring before dismissing risk or restoring service. ## Verification and evidence - Retain exported risk detections, service-principal sign-ins, audit events, credential metadata, and permission assignments. - Record every credential and secret rotation without storing secret values in the incident record. - Prove expected jobs succeed with the new credential and old credentials fail. - Document unsupported identity types and the separate monitoring used for them. ## Official references - [Securing workload identities](https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk) — Microsoft ## Primary reference - Name: Securing workload identities - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/id-protection/concept-workload-identity-risk - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Investigate risky workload identities separately from risky users,” DSE Security, https://update.dsesecurity.com/updates/entra-risky-workload-identities-investigation/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Investigate SPN and UPN collisions from directory-service events > Use SPN and UPN uniqueness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/investigate-spn-upn-collisions-from-events/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:00+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use SPN and UPN uniqueness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of SPN and UPN uniqueness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Investigate SPN and UPN collisions from directory-service events. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [SPN and UPN uniqueness](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/spn-and-upn-uniqueness) from Microsoft supports the following bounded statements: - The directory enforces UPN uniqueness during user creation and documents the resulting failure paths. The research record locates this support at Section: New user creation fails if UPN isn’t unique. - Event 2974 from ActiveDirectory_DomainService is documented as evidence for uniqueness conflicts. The research record locates this support at Section: Event 2974 Source: ActiveDirectory_DomainService. Keep the evidence boundary at these traced claims. They support a review of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Do not delete or overwrite a conflicting identifier until account ownership and service dependencies are known. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section: New user creation fails if UPN isn’t unique, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section: Event 2974 Source: ActiveDirectory_DomainService, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from Section: New user creation fails if UPN isn’t unique; Section: Event 2974 Source: ActiveDirectory_DomainService through directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [SPN and UPN uniqueness](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/spn-and-upn-uniqueness) — Microsoft ## Primary reference - Name: SPN and UPN uniqueness - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/spn-and-upn-uniqueness - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Investigate SPN and UPN collisions from directory-service events,” DSE Security, https://update.dsesecurity.com/updates/investigate-spn-upn-collisions-from-events/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Invoke-DnsServerZoneSign: invoke dns server zone sign with bounded evidence > Use Invoke-DnsServerZoneSign to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/invoke-dnsserverzonesign-invoke-dns-server-zone-sign-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:26+00:00 - Modified: 2026-08-27T17:22:20+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Invoke-DnsServerZoneSign to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Invoke-DnsServerZoneSign ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Invoke-DnsServerZoneSign: invoke dns server zone sign with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Invoke-DnsServerZoneSign](https://learn.microsoft.com/en-us/powershell/module/dnsserver/invoke-dnsserverzonesign?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Invoke-DnsServerZoneSign cmdlet signs a Domain Name System (DNS) server zone.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “If the zone is already signed, use the DoResign parameter.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-240 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Invoke-DnsServerZoneSign](https://learn.microsoft.com/en-us/powershell/module/dnsserver/invoke-dnsserverzonesign?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Invoke-DnsServerZoneSign - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/invoke-dnsserverzonesign?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Invoke-DnsServerZoneSign: invoke dns server zone sign with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/invoke-dnsserverzonesign-invoke-dns-server-zone-sign-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Invoke-DnsServerZoneUnsign: invoke dns server zone unsign with rollback checks > Use Invoke-DnsServerZoneUnsign to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/invoke-dnsserverzoneunsign-invoke-dns-server-zone-unsign-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:02:49+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Invoke-DnsServerZoneUnsign to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Invoke-DnsServerZoneUnsign ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Invoke-DnsServerZoneUnsign: invoke dns server zone unsign with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Invoke-DnsServerZoneUnsign](https://learn.microsoft.com/en-us/powershell/module/dnsserver/invoke-dnsserverzoneunsign?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Invoke-DnsServerZoneUnsign cmdlet unsigns a DNS Security Extensions (DNSSEC)-signed Domain Name System (DNS) zone.” The research record locates this support at DESCRIPTION. - At -AsJob, Microsoft states: “Use this parameter to run commands that take a long time to complete.” The research record locates this support at -AsJob. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at -AsJob, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations DESCRIPTION; -AsJob adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-277 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Invoke-DnsServerZoneUnsign](https://learn.microsoft.com/en-us/powershell/module/dnsserver/invoke-dnsserverzoneunsign?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Invoke-DnsServerZoneUnsign - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/invoke-dnsserverzoneunsign?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Invoke-DnsServerZoneUnsign: invoke dns server zone unsign with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/invoke-dnsserverzoneunsign-invoke-dns-server-zone-unsign-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Issue airport identification media with visible scope and accountability controls > Use 49 CFR 1542.211 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/issue-airport-identification-media-with-visible-scope-and-accountability-controls/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:29+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.211 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.211 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Issue airport identification media with visible scope and accountability controls. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.211 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.211) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, the rule requires that the personnel identification system under section section 1542.201(b)(3) and 1542.205(b)(1) include the following: procedures to ensure accountability through the following: reporting lost or stolen identification media. The research record locates this support at 49 CFR 1542.211(a)(3)(ii), read with 49 CFR 1542.211(a)(3) and 49 CFR 1542.211(a) (eCFR anchor p-1542.211(a)(3)(ii)). - Under 49 CFR 1542, the rule requires that the personnel identification system under section section 1542.201(b)(3) and 1542.205(b)(1) include the following: procedures to ensure accountability through the following: securing unissued identification media stock and supplies. The research record locates this support at 49 CFR 1542.211(a)(3)(iii), read with 49 CFR 1542.211(a)(3) and 49 CFR 1542.211(a) (eCFR anchor p-1542.211(a)(3)(iii)). Only the traced statements above are asserted as source facts. Apply the review to credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces after confirming that the source and deployed context match. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 49 CFR 1542.211(a)(3)(ii), read with 49 CFR 1542.211(a)(3) and 49 CFR 1542.211(a) (eCFR anchor p-1542.211(a)(3)(ii)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.211(a)(3)(iii), read with 49 CFR 1542.211(a)(3) and 49 CFR 1542.211(a) (eCFR anchor p-1542.211(a)(3)(iii)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to 49 CFR 1542.211(a)(3)(ii), read with 49 CFR 1542.211(a)(3) and 49 CFR 1542.211(a) (eCFR anchor p-1542.211(a)(3)(ii)); 49 CFR 1542.211(a)(3)(iii), read with 49 CFR 1542.211(a)(3) and 49 CFR 1542.211(a) (eCFR anchor p-1542.211(a)(3)(iii)) and to observable material such as approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [49 CFR 1542.211 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.211) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.211 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.211 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Issue airport identification media with visible scope and accountability controls,” DSE Security, https://update.dsesecurity.com/updates/issue-airport-identification-media-with-visible-scope-and-accountability-controls/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Issue Microsoft Entra Temporary Access Passes as controlled bootstrap credentials > A Temporary Access Pass can bootstrap passwordless registration or recovery, but its scope, delivery, lifetime, use count, and follow-up evidence need the same care as any other powerful temporary credential. - Canonical URL: https://update.dsesecurity.com/updates/entra-temporary-access-pass-bootstrap-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:26+00:00 - Modified: 2026-08-25T21:36:18+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know A Temporary Access Pass can bootstrap passwordless registration or recovery, but its scope, delivery, lifetime, use count, and follow-up evidence need the same care as any other powerful temporary credential. ## Potentially affected Microsoft Entra users, authentication administrators, passwordless enrollment, account recovery, device enrollment, federated domains, and Conditional Access session design. ## DSE recommendation Authorize each Temporary Access Pass for a named purpose, issue it through a verified support workflow, deliver it separately from routine account communications, and confirm both method registration and pass retirement. ## Article Bottom line: Microsoft Entra Temporary Access Pass (TAP) is a time-limited passcode for bootstrapping passwordless authentication or helping a user recover when a strong method is unavailable. It is still a usable sign-in credential. Treat its creation, delivery, use, and removal as a controlled identity operation rather than a convenience code sent through an unverified support channel. ## Source fact: what Microsoft documents Microsoft’s [Temporary Access Pass guidance](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass) says a TAP can be configured for one use or multiple sign-ins. A user can use it to register methods such as a passkey, FIDO2 security key, Windows Hello for Business, or Microsoft Authenticator. In a federated domain, TAP authentication is completed by Microsoft Entra instead of redirecting the user to the federated identity provider. The authentication methods policy controls which users may sign in with TAP and sets parameters such as minimum, maximum, and default lifetime, one-time-use behavior, and passcode length. Microsoft distinguishes the role used to manage the tenant policy from roles that can create, view, or delete a user’s TAP. The actual passcode is displayed when it is created and cannot be viewed again after the administrator closes that display. Microsoft also documents important boundaries. A user can have only one TAP at a time. A TAP issued to an external guest is not supported, although an external guest may use a TAP issued by the home tenant when cross-tenant requirements are satisfied. An expired or deleted TAP cannot be used for new authentication, but expiration does not retroactively terminate every already-established session. Conditional Access session controls can therefore affect how long access obtained through the sign-in continues. ## What the source does not establish The Microsoft page does not verify the requester’s identity, authorize a help-desk action, select a safe delivery channel, or prove that the intended user received the code. It does not make TAP an appropriate response to every lost-device, new-hire, or recovery scenario. A short lifetime does not compensate for weak requester verification, excessive administrator access, or an unmonitored handoff. ## Applicability questions - Which onboarding and recovery cases are approved to use TAP, and which require escalation? - How will the operator verify the person and the authorized request without relying on a compromised method? - Will one-time use work for the enrollment path, including device setup and passwordless registration timing? - Which administrators can manage the policy or issue passes, and how are their actions reviewed? - Does Conditional Access limit session duration appropriately after TAP authentication? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Define approved TAP scenarios, identity-proofing steps, authorizers, administrator roles, delivery channels, maximum lifetimes, and escalation triggers. - Pilot the complete enrollment and recovery journey with test identities. Include federated users, managed-device enrollment, delayed registration, and a failed or expired pass. - Verify the requester through an approved independent process before creation. Record the request, purpose, operator, start time, duration, and whether the pass is single-use. - Deliver the pass through a channel selected for the assessed risk. Avoid placing the TAP beside enough account context for an unintended recipient to use it. - Require the user to register the intended strong method, remove obsolete methods when authorized, and report completion through the support workflow. - Delete an unused or no-longer-needed TAP and investigate unexplained issuance, repeated failures, or registration outside the approved window. ## Verification and evidence - Preserve the approved request and administrator audit event without recording the TAP value. - Confirm the intended authentication method is registered and usable. - Confirm the TAP is expired, consumed, replaced, or deleted as designed. - Review sign-in evidence for unexpected resources, locations, devices, or continued sessions. - Record exceptions and the person who accepted any remaining exposure. ## Official references - [Configure Temporary Access Pass to register passwordless authentication methods](https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass) — Microsoft ## Primary reference - Name: Configure Temporary Access Pass to register passwordless authentication methods - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-temporary-access-pass - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Issue Microsoft Entra Temporary Access Passes as controlled bootstrap credentials,” DSE Security, https://update.dsesecurity.com/updates/entra-temporary-access-pass-bootstrap-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Join nuclear cyber protection to safety, security, and emergency systems > Use 10 CFR 73.54 - Digital computer and communication systems to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/join-nuclear-cyber-protection-to-safety-security-and-emergency-systems/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:46+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.54 - Digital computer and communication systems to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.54 - Digital computer and communication systems ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Join nuclear cyber protection to safety, security, and emergency systems. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.54 – Digital computer and communication systems](https://www.ecfr.gov/current/title-10/section-73.54) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, the rule requires that the licensee protect digital computer and communication systems and networks associated with: support systems and equipment which, if compromised, would adversely impact safety, security, or emergency preparedness functions. The research record locates this support at 10 CFR 73.54(a)(1)(iv), read with 10 CFR 73.54(a)(1) (eCFR anchor p-73.54(a)(1)(iv)). - Under 10 CFR 73, the rule requires that the licensee protect digital computer and communication systems and networks associated with: emergency preparedness functions, including offsite communications. The research record locates this support at 10 CFR 73.54(a)(1)(iii), read with 10 CFR 73.54(a)(1) (eCFR anchor p-73.54(a)(1)(iii)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths only where the source and recorded environment align. ## What the source does not establish NRC regulation for covered reactor licensees; security architecture and vulnerabilities can be sensitive, and compliance requires the full rule, license basis, orders, and NRC guidance. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.54(a)(1)(iv), read with 10 CFR 73.54(a)(1) (eCFR anchor p-73.54(a)(1)(iv)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.54(a)(1)(iii), read with 10 CFR 73.54(a)(1) (eCFR anchor p-73.54(a)(1)(iii)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from 10 CFR 73.54(a)(1)(iv), read with 10 CFR 73.54(a)(1) (eCFR anchor p-73.54(a)(1)(iv)); 10 CFR 73.54(a)(1)(iii), read with 10 CFR 73.54(a)(1) (eCFR anchor p-73.54(a)(1)(iii)) through asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [10 CFR 73.54 – Digital computer and communication systems](https://www.ecfr.gov/current/title-10/section-73.54) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.54 - Digital computer and communication systems - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.54 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Join nuclear cyber protection to safety, security, and emergency systems,” DSE Security, https://update.dsesecurity.com/updates/join-nuclear-cyber-protection-to-safety-security-and-emergency-systems/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # July 2026 Windows security update: deployment checks for managed environments > Microsoft’s July 2026 Windows update enforces Kerberos RC4 protections, while a July 18 out-of-band release resolves the limited Dell and Intel IPF compatibility hold. - Canonical URL: https://update.dsesecurity.com/updates/july-2026-windows-security-update-deployment-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-16T14:00:00+00:00 - Modified: 2026-07-19T19:29:33+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Briefing - DSE priority: Important - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Microsoft’s July 2026 Windows update enforces Kerberos RC4 protections, while a July 18 out-of-band release resolves the limited Dell and Intel IPF compatibility hold. ## Potentially affected Supported Windows client and server environments, especially Active Directory workloads with legacy RC4 dependencies and the limited Dell systems identified by Microsoft as using affected Intel IPF drivers. ## DSE recommendation Review current Microsoft release health, identify RC4 dependencies, confirm device-specific update applicability, pilot representative systems, verify recovery paths, and deploy through controlled waves. ## Article ## What Microsoft published Microsoft released the July 2026 security update for supported Windows versions on July 14. The [Windows message center](https://learn.microsoft.com/en-us/windows/release-health/windows-message-center) recommends prompt installation and links administrators to version-specific release notes and known-issue status. The release also begins the enforcement phase for Kerberos RC4 protections associated with CVE-2026-20833. Microsoft says domain controllers now enforce updated service-ticket behavior, with AES expected for supported configurations. Workloads that still depend on legacy RC4 behavior can experience authentication failures, so service accounts, older applications, appliances, and non-Windows Kerberos integrations need deliberate validation. ## The limited Dell and Intel hold has been resolved Microsoft initially withheld KB5101650 from a limited number of Dell devices using Intel Innovation Platform Framework drivers. On July 18, Microsoft published [out-of-band update KB5121767](https://support.microsoft.com/en-us/servicing/os/windows-11/2026/07/kb5121767-out-of-band) to address the issue and allow the affected devices to move forward. Microsoft states that the out-of-band update is intended for devices affected by that specific issue. Eligible devices can receive it through Windows Update; administrators should confirm model, driver, and update applicability rather than deploying an out-of-band package indiscriminately. ## Why change control still matters Prompt patching and controlled deployment are complementary. The Kerberos change can expose dependencies that were not visible during ordinary operation, while device-specific safeguards and out-of-band releases can change the correct update path for a subset of the fleet. A representative pilot makes those conditions visible before they become a broad service disruption. ## DSE deployment checklist - Inventory supported Windows client and server versions, build numbers, device models, and servicing channels. - Review Microsoft release health and the release notes for every version in scope. - Use documented Microsoft guidance and relevant event data to identify accounts, applications, devices, or integrations that still rely on RC4-based Kerberos behavior. - Confirm which Dell and Intel IPF devices were affected and whether normal Windows Update now offers the applicable resolution. - Pilot representative domain controllers, servers, workstations, remote users, and line-of-business applications. - Verify monitoring, current backups, recovery access, and a tested rollback or recovery path before broad deployment. - Validate authentication, endpoint health, business applications, printing, remote access, and security tooling after installation. - Record deferred systems, the reason, compensating safeguards, an owner, and a review date. ## Keep the evidence with the change Record the Microsoft references reviewed, approval, pilot population, observed results, exception list, deployment waves, and post-change validation. That record makes it easier to distinguish a patch issue from an application, identity, driver, or network dependency and supports a safer follow-up if Microsoft changes the release status again. ## Official references - [Windows message center](https://learn.microsoft.com/en-us/windows/release-health/windows-message-center) — Microsoft’s July 14 update and Kerberos enforcement announcements. - [KB5121767 out-of-band update](https://support.microsoft.com/en-us/servicing/os/windows-11/2026/07/kb5121767-out-of-band) — Microsoft’s July 18 resolution for the affected Windows 11 devices. - [Detect and remediate RC4 usage in Kerberos](https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos) — Microsoft’s discovery and remediation guidance. ## Primary reference - Name: Microsoft Windows message center - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/release-health/windows-message-center - Source publication date: Not stated by the source ## Citation and use Preferred citation: “July 2026 Windows security update: deployment checks for managed environments,” DSE Security, https://update.dsesecurity.com/updates/july-2026-windows-security-update-deployment-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep access-control hardware operable for the broadest users > Door and gate hardware on accessible routes has reach and operation requirements. Reader placement alone does not establish that the complete entry action is accessible. - Canonical URL: https://update.dsesecurity.com/updates/keep-access-control-hardware-operable-for-the-broadest-users/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:50+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Access Control - Reading time: 2 minutes ## What you need to know Door and gate hardware on accessible routes has reach and operation requirements. Reader placement alone does not establish that the complete entry action is accessible. ## Potentially affected Projects adding readers, keypads, intercoms, handles, latches, request-to-exit controls, or powered-door activation at accessible entrances and routes. ## DSE recommendation Evaluate the complete credential-and-door interaction with accessibility specialists and representative users, including reach, clearance, force, timing, feedback, and recovery. ## Article Bottom line: mounting a card reader at a familiar height does not accept an accessible entrance. A user must be able to reach and operate the relevant controls, present a credential, receive understandable feedback, clear the door movement, and complete entry while the unlock remains available. ## Source fact: operable hardware has reach and manipulation criteria The Access Board’s [Guide to Entrances, Doors, and Gates](https://www.access-board.gov/ada/guides/chapter-4-entrances-doors-and-gates/) explains ADA requirements for door and gate hardware. It describes operable hardware that can be used with one hand without tight grasping, pinching, or wrist twisting, a maximum operating force, and a mounting range. The guide also explains that keys and access cards are not treated as part of the lockset for the cited hardware provision, while recommending accessible selection as good practice. That limited exception does not make the rest of the doorway exempt. Handles, latches, closers, clearances, controls, and maneuvering space still need the applicable assessment. ## Source boundary and applicability The guide explains federal accessibility standards; it is not a project-specific legal determination and does not cover every disability, technology, or local code. Applicable ADA provisions, adopted codes, existing-facility rules, alterations, historic conditions, and enforcement authority must be assessed by qualified professionals. Security requirements do not automatically override accessibility obligations. ## Applicability questions - Which entrance and route accessibility requirements apply to this project? - Can a person approach the reader or control without an obstruction, excessive reach, or door-swing hazard? - Does the credential require grip, dexterity, vision, hearing, or timing that excludes expected users? - Are audible, visible, and tactile feedback understandable without exposing sensitive access status? - Is unlock duration sufficient for the approach, credential action, door operation, and passage? ## DSE recommendation: test the whole user journey The following steps are DSE recommendations based on the cited source. Have the design reviewed against applicable accessibility and building requirements. Map the journey from approach through credential presentation, feedback, door manipulation, passage, and relatching. Include reader and intercom height, clear floor space, protrusion, lighting, door swing, handle, force, timing, and alternate assistance workflow. Use representative user testing where appropriate and voluntary, without asking participants to disclose medical information. Correct barriers through coordinated hardware and software changes. An extended unlock timer may help one step but create a security or tailgating issue; document the balanced design and obtain the responsible approvals. ## Verification and evidence Retain the accessibility review, elevations and clearances, hardware schedule, force and timing measurements, configured unlock durations, feedback tests, representative workflow observations, exception analysis, and acceptance signatures. Re-test after reader, credential, door, closer, furniture, queue, or software changes. ## Official references - [Access Board Guide to Entrances, Doors, and Gates](https://www.access-board.gov/ada/guides/chapter-4-entrances-doors-and-gates/) – United States Access Board ## Primary reference - Name: Access Board Guide to Entrances, Doors, and Gates - Authority: www.access-board.gov - URL: https://www.access-board.gov/ada/guides/chapter-4-entrances-doors-and-gates/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep access-control hardware operable for the broadest users,” DSE Security, https://update.dsesecurity.com/updates/keep-access-control-hardware-operable-for-the-broadest-users/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep an airport security coordinator available and accountable for TSA coordination > Use 49 CFR 1542.3 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-an-airport-security-coordinator-available-and-accountable-for-tsa-coordination/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:41+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.3 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.3 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Keep an airport security coordinator available and accountable for TSA coordination. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.3 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.3) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, the rule requires that each airport operator designate one or more Airport Security Coordinator(s) (ASC) in its security program. The research record locates this support at 49 CFR 1542.3(a) (eCFR anchor p-1542.3(a)). - Under 49 CFR 1542, any individual designated as an ASC may perform other duties in addition to those described in this paragraph (b). The research record locates this support at 49 CFR 1542.3(b)(1) (eCFR anchor p-1542.3(b)(1)). The source support ends with the statements listed above. Use them to examine access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 49 CFR 1542.3(a) (eCFR anchor p-1542.3(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.3(b)(1) (eCFR anchor p-1542.3(b)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from 49 CFR 1542.3(a) (eCFR anchor p-1542.3(a)); 49 CFR 1542.3(b)(1) (eCFR anchor p-1542.3(b)(1)) to the observed environment. Useful domain evidence includes asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [49 CFR 1542.3 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.3) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.3 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.3 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep an airport security coordinator available and accountable for TSA coordination,” DSE Security, https://update.dsesecurity.com/updates/keep-an-airport-security-coordinator-available-and-accountable-for-tsa-coordination/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep approved maritime-security compliance documents available and protected > Use 33 CFR 105.120 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-approved-maritime-security-compliance-documents-available-and-protected/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:46+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.120 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.120 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Keep approved maritime-security compliance documents available and protected. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.120 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.120) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, a covered facility must keep its approved Facility Security Plan, approved revisions or amendments, and a COTP approval letter dated within the last five years available at the facility and to the Coast Guard on request. The research record locates this support at 33 CFR 105.120(a), read with the unnumbered introductory paragraph of 33 CFR 105.120 (eCFR anchor p-105.120(a)). - Under 33 CFR 105, a facility awaiting FSP approval may continue operating under its submitted plan when it holds the COTP acknowledgment described in paragraph (b) and remains compliant with that submitted plan. The research record locates this support at 33 CFR 105.120(b), read with the unnumbered introductory paragraph of 33 CFR 105.120 (eCFR anchor p-105.120(b)). Keep the evidence boundary at these traced claims. They support a review of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.120(a), read with the unnumbered introductory paragraph of 33 CFR 105.120 (eCFR anchor p-105.120(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.120(b), read with the unnumbered introductory paragraph of 33 CFR 105.120 (eCFR anchor p-105.120(b)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 33 CFR 105.120(a), read with the unnumbered introductory paragraph of 33 CFR 105.120 (eCFR anchor p-105.120(a)); 33 CFR 105.120(b), read with the unnumbered introductory paragraph of 33 CFR 105.120 (eCFR anchor p-105.120(b)). Favor asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [33 CFR 105.120 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.120) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.120 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.120 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep approved maritime-security compliance documents available and protected,” DSE Security, https://update.dsesecurity.com/updates/keep-approved-maritime-security-compliance-documents-available-and-protected/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep at least one restricted entrance accessible where the ADA applies > The ADA standards address restricted entrances and service-only entrances. Security classification does not automatically remove accessible-entry requirements. - Canonical URL: https://update.dsesecurity.com/updates/keep-one-restricted-entrance-accessible-where-the-ada-applies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:42+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Briefing - DSE priority: Important - Topics: Access Control - Reading time: 2 minutes ## What you need to know The ADA standards address restricted entrances and service-only entrances. Security classification does not automatically remove accessible-entry requirements. ## Potentially affected Facilities with employee-only, security-restricted, loading, service, or controlled entrances that may be part of required accessible routes. ## DSE recommendation Include restricted and service-only entrances in the accessibility determination before finalizing readers, gates, turnstiles, intercoms, and alternate-entry procedures. ## Article Bottom line: calling an entrance employee-only, secure, loading, or service does not by itself remove it from accessibility review. The project must determine which controlled opening supplies the required accessible route and make the security journey work there. ## Source fact: the ADA standards explicitly address restricted entrances Sections 206.4.7 and 206.4.8 of the [2010 ADA Standards for Accessible Design](https://www.ada.gov/law-and-regs/design-standards/2010-stds/) require at least one restricted entrance to comply with Section 404 and require a service entrance to comply with Section 404 when it is the only entrance to a building or tenancy. That text means the accessibility analysis should occur before a project concentrates all controlled access in a turnstile bank, narrow gate, loading entrance, or distant staff door. ## Source boundary and applicability The DOJ source is the official online version of the 2010 ADA Standards, but enforceable obligations and exceptions depend on facility type, alteration status, route, occupancy, federal or state enforcement, local adoption, and project facts. It does not decide which entrance should be selected for a specific facility or approve a separate staff-assistance process. This article is not legal or code advice. ## Applicability questions - Which entrances are public, restricted, service-only, employee-only, or assigned to separate tenancies? - Which accessible routes connect arrival points, parking, transit, site boundaries, and interior destinations? - Do readers, intercoms, turnstiles, gates, thresholds, doors, and queues preserve the required route? - Is the accessible restricted entrance open and independently usable whenever the corresponding restricted access is offered? - How are equivalent security screening, identity verification, and emergency communication provided? ## DSE recommendation: put accessibility on the entrance schedule The following steps are DSE recommendations based on the cited source. Have qualified accessibility and code professionals classify every entrance and mark required accessible routes on the architectural and security plans. For each restricted entry population and operating period, identify the compliant opening, credential or intercom workflow, maneuvering space, clear width, hardware, timing, screening procedure, and route to the destination. Test the journey in normal, after-hours, visitor, denied-access, assistance, power-loss, and emergency states. An alternate gate that is locked, unstaffed, blocked by deliveries, or available only after a burdensome detour is not an operational solution. Coordinate changes with egress and site-security requirements. ## Verification and evidence Retain the entrance classification, accessible-route plan, applicable-requirement determination, reader and hardware elevations, clear-width and maneuvering measurements, workflow tests, operating-hours review, deficiency record, and qualified acceptance. Recheck after tenant, route, landscaping, parking, gate, turnstile, or staffing changes. ## Official references - [2010 ADA Standards for Accessible Design, Sections 206.4.7–206.4.8](https://www.ada.gov/law-and-regs/design-standards/2010-stds/) – U.S. Department of Justice; September 15, 2010 ## Primary reference - Name: 2010 ADA Standards for Accessible Design, Sections 206.4.7–206.4.8 - Authority: www.ada.gov - URL: https://www.ada.gov/law-and-regs/design-standards/2010-stds/ - Source publication date: 2010-09-15 ## Citation and use Preferred citation: “Keep at least one restricted entrance accessible where the ADA applies,” DSE Security, https://update.dsesecurity.com/updates/keep-one-restricted-entrance-accessible-where-the-ada-applies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep Azure Connected Machine agents inside their one-year support window > Azure Arc management depends on software installed on every connected server. Inventory the Connected Machine agent, establish an upgrade path for each operating system, pilot releases, verify reconnection, and resolve version exceptions before support expires. - Canonical URL: https://update.dsesecurity.com/updates/azure-connected-machine-agent-version-operations/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-11T10:46:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: IT - Reading time: 3 minutes ## What you need to know Azure Arc management depends on software installed on every connected server. Inventory the Connected Machine agent, establish an upgrade path for each operating system, pilot releases, verify reconnection, and resolve version exceptions before support expires. ## Potentially affected Azure Arc-enabled Windows and Linux servers; Azure Connected Machine agent; Microsoft Update, WSUS, Configuration Manager, Azure Update Manager, Linux package repositories, proxies, extensions, policies, monitoring, and server maintenance processes. ## DSE recommendation Report agent version and connection state across the estate, choose a supported update mechanism by platform, pilot the current release, verify post-update Arc functions, and assign deadlines to agents approaching the one-year support boundary. ## Article ## Source facts: Arc management has a locally installed lifecycle Microsoft’s [Connected Machine agent maintenance guidance](https://learn.microsoft.com/en-us/azure/azure-arc/servers/manage-agent) says the agent is updated regularly for bug fixes, stability improvements, and new functionality. Azure Advisor can identify machines that are not using the latest version. Microsoft recommends the most recent release and states that the product group officially supports only Connected Machine agent versions released within the last year. Windows and Linux use different delivery paths. Microsoft lists manual installation and Azure Update Manager for both platform families, Microsoft Update for Windows, and the appropriate apt, yum, or zypper package workflow for Linux. Installing, upgrading, or uninstalling the agent does not require a server restart. If a connected machine needs a specific older version, Microsoft instructs administrators to uninstall the current version and install the target version; the existing Arc connection does not need to be disconnected for that version change. Windows Server does not check Microsoft Update for other Microsoft products by default. A server expected to receive the agent that way must be configured accordingly. Environments using WSUS or Configuration Manager must synchronize the Azure Connected Machine Agent product, including its suboptions, and approve the Critical Updates and Updates classifications. Linux machines need access to Microsoft’s package repository through the organization’s package-management design. The absence of a reboot does not remove change risk. The installed agent carries the machine’s connection to Azure Arc and supports downstream management functions. A successful package transaction therefore needs a separate check that the resource reconnects and the intended Arc capabilities still operate. ## DSE recommendation: manage version, connection, and function separately Create one operational record for every Arc-enabled server and reconcile it with the Azure resource. Do not use resource existence as the sole health signal. - Inventory the control path. Record server owner, operating system, environment, Arc resource ID and region, Connected Machine agent version, connection state, outbound proxy, update authority, installed extensions, assigned policy, maintenance window, and last successful check-in. - Set an internal age limit. Calculate version age from Microsoft’s release history and remediate comfortably before the one-year support boundary. Give every freeze or compatibility exception an owner, justification, expiry date, and tested recovery plan. - Prove delivery. For Windows, verify that Microsoft Update or the organization’s approved WSUS, Configuration Manager, or Azure Update Manager path includes the Connected Machine agent. For Linux, verify repository configuration, trust, package visibility, proxy behavior, and the intended automated or controlled approval process. - Pilot representative servers. Include each supported operating-system family, proxy route, network zone, extension pattern, update tool, and important workload class. Capture the pre-change version and connection state, package result, setup or package-manager log, post-change version, and elapsed reconnection time. - Test the service after the package. Confirm the Arc resource is connected, inventory is current, assigned policy reports, expected extensions remain healthy, remote management used by the organization works, and monitoring has not gone silent. Application checks remain necessary even when no restart occurs. - Reconcile failure states. Alert on disconnected agents, unsupported versions, repeated upgrade failures, missing repositories or update products, proxy errors, duplicate or abandoned Arc resources, and machines that no longer have an accountable owner. Track the percentage on the approved release, oldest version age, disconnected duration, upgrade success by platform, exception age, and the time between a successful package installation and a healthy Arc check-in. Keep agent upgrades in the same maintenance register as operating-system and extension changes, while preserving their separate status. The useful result is a management channel that remains supported and demonstrably functional—not merely an Azure inventory row that still has a familiar server name. ## Official references - Microsoft Learn, [Manage Azure Connected Machine agent versions for Azure Arc-enabled servers](https://learn.microsoft.com/en-us/azure/azure-arc/servers/manage-agent), April 28, 2026. - Microsoft Learn, [What’s new with the Azure Connected Machine agent](https://learn.microsoft.com/en-us/azure/azure-arc/servers/agent-release-notes); release history reviewed August 11, 2026. ## Primary reference - Name: Microsoft Learn: Manage Azure Connected Machine agent versions - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/azure-arc/servers/manage-agent - Source publication date: 2026-04-28 ## Citation and use Preferred citation: “Keep Azure Connected Machine agents inside their one-year support window,” DSE Security, https://update.dsesecurity.com/updates/azure-connected-machine-agent-version-operations/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep confederation-internal AS paths from leaking beyond the confederation > Use RFC 5065 — Autonomous System Confederations for BGP to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-confederation-internal-as-paths-from-leaking-beyond-the-confederation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:25+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 5065 — Autonomous System Confederations for BGP to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 5065 — Autonomous System Confederations for BGP ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Keep confederation-internal AS paths from leaking beyond the confederation. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 5065 — Autonomous System Confederations for BGP](https://www.rfc-editor.org/rfc/rfc5065.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A confederation member uses its confederation identifier with outside peers and its Member-AS number with peers inside the same confederation. The research record locates this support at Section 4 (Operation). - Before advertising outside the confederation, a speaker must remove AS_CONFED_SEQUENCE and AS_CONFED_SET segments and prepend its confederation identifier under the external AS_PATH rules. The research record locates this support at Section 4.1 (AS_PATH Modification Rules), rule c. - A speaker must not transmit confederation path segments to an outside peer, and receiving them from an outside neighbor is a malformed AS_PATH error. The research record locates this support at Section 5 (Error Handling). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Section 4 (Operation), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4.1 (AS_PATH Modification Rules), rule c, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5 (Error Handling), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 4 (Operation); Section 4.1 (AS_PATH Modification Rules), rule c; Section 5 (Error Handling). Favor configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 5065 — Autonomous System Confederations for BGP](https://www.rfc-editor.org/rfc/rfc5065.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 5065 — Autonomous System Confederations for BGP - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5065.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep confederation-internal AS paths from leaking beyond the confederation,” DSE Security, https://update.dsesecurity.com/updates/keep-confederation-internal-as-paths-from-leaking-beyond-the-confederation/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep Defender for Identity email and Syslog notifications on sensor v2 dependencies > Use Defender for Identity notifications in Microsoft Defender to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-identity-email-and-syslog-notifications-on-sensor-v2-dependencies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:41+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Defender for Identity notifications in Microsoft Defender to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Defender for Identity notifications in Microsoft Defender ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Keep Defender for Identity email and Syslog notifications on sensor v2 dependencies. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Defender for Identity notifications in Microsoft Defender](https://learn.microsoft.com/en-us/defender-for-identity/notifications) from Microsoft supports the following bounded statements: - Defender for Identity notifications are supported only by sensor v2.x. The research record locates this support at Opening applicability statement. - The service can notify on health issues and security alerts through email or a Syslog server. The research record locates this support at Opening notification overview. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions and the conditions the source actually describes. ## What the source does not establish Notifications are delivery mechanisms rather than authoritative retention or response systems; monitor failures and plan for the v3 feature limitation. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening applicability statement, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening notification overview, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Opening applicability statement; Opening notification overview to the observed environment. Useful domain evidence includes sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Defender for Identity notifications in Microsoft Defender](https://learn.microsoft.com/en-us/defender-for-identity/notifications) — Microsoft ## Primary reference - Name: Defender for Identity notifications in Microsoft Defender - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/notifications - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Keep Defender for Identity email and Syslog notifications on sensor v2 dependencies,” DSE Security, https://update.dsesecurity.com/updates/keep-identity-email-and-syslog-notifications-on-sensor-v2-dependencies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep Defender for Identity sensor v2 scope to legacy controllers and non-DC identity roles > Use Microsoft Defender for Identity sensor v2.x prerequisites to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-defender-identity-sensor-v2-legacy-controllers-non-dc-roles/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:38+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Microsoft Defender for Identity sensor v2.x prerequisites to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft Defender for Identity sensor v2.x prerequisites ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Keep Defender for Identity sensor v2 scope to legacy controllers and non-DC identity roles. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft Defender for Identity sensor v2.x prerequisites](https://learn.microsoft.com/en-us/defender-for-identity/deploy/prerequisites-sensor-version-2) from Microsoft supports the following bounded statements: - Sensor v2 supports domain controllers running Windows Server 2016 or earlier and AD FS, AD CS, or Microsoft Entra Connect servers that are not domain controllers. The research record locates this support at In this article > supported v2 scenarios. - For domain controllers running Windows Server 2019 or later, Microsoft recommends sensor v3 instead of sensor v2. The research record locates this support at In this article > Tip following supported v2 scenarios. - Defender for Identity deployment requires one of the listed EMS, Microsoft 365 Security, or standalone licenses; both F5 options also require the listed F1, F3, and EMS E3 prerequisites. The research record locates this support at Licensing requirements. The source support ends with the statements listed above. Use them to examine Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Windows Server 2012 and 2012 R2 are past extended support; existing sensors can report but OS-dependent functionality may be unavailable, so this v2 page is not an operating-system support extension. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at In this article > supported v2 scenarios, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at In this article > Tip following supported v2 scenarios, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Licensing requirements, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations In this article > supported v2 scenarios; In this article > Tip following supported v2 scenarios; Licensing requirements. Favor sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Microsoft Defender for Identity sensor v2.x prerequisites](https://learn.microsoft.com/en-us/defender-for-identity/deploy/prerequisites-sensor-version-2) — Microsoft ## Primary reference - Name: Microsoft Defender for Identity sensor v2.x prerequisites - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/prerequisites-sensor-version-2 - Source publication date: 2026-06-08 ## Citation and use Preferred citation: “Keep Defender for Identity sensor v2 scope to legacy controllers and non-DC identity roles,” DSE Security, https://update.dsesecurity.com/updates/keep-defender-identity-sensor-v2-legacy-controllers-non-dc-roles/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep documentation and test names inside reserved namespaces > Use RFC 2606 — Reserved Top Level DNS Names to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-documentation-and-test-names-inside-reserved-namespaces/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:40+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2606 — Reserved Top Level DNS Names to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2606 — Reserved Top Level DNS Names ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Keep documentation and test names inside reserved namespaces. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2606 — Reserved Top Level DNS Names](https://www.rfc-editor.org/rfc/rfc2606.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - The top-level names .test, .example, .invalid, and .localhost are reserved for their designated testing, documentation, invalid-name, and loopback uses. The research record locates this support at Section 2 (TLDs for Testing and Documentation Examples). - The second-level names example.com, example.net, and example.org are reserved for examples. The research record locates this support at Section 3 (Reserved Example Second Level Domain Names). - Using these reservations avoids collisions that can occur when test or example code names a real or subsequently delegated namespace. The research record locates this support at Section 2 (TLDs for Testing and Documentation Examples), collision rationale. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Section 2 (TLDs for Testing and Documentation Examples), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Reserved Example Second Level Domain Names), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2 (TLDs for Testing and Documentation Examples), collision rationale, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 2 (TLDs for Testing and Documentation Examples); Section 3 (Reserved Example Second Level Domain Names); Section 2 (TLDs for Testing and Documentation Examples), collision rationale. Favor zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 2606 — Reserved Top Level DNS Names](https://www.rfc-editor.org/rfc/rfc2606.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2606 — Reserved Top Level DNS Names - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2606.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep documentation and test names inside reserved namespaces,” DSE Security, https://update.dsesecurity.com/updates/keep-documentation-and-test-names-inside-reserved-namespaces/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep each RDS session collection at a consistent Windows Server version > Can different Windows Server versions coexist within one RDS session collection? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-064-keep-each-rds-session-collection-at-a-consistent-windows-server-version/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:07+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Can different Windows Server versions coexist within one RDS session collection? ## Potentially affected Use this review when designing or auditing a mixed-version RDS environment. ## DSE recommendation Build a collection-membership matrix rather than relying on a deployment-wide list of servers. ## Article ## Source facts Microsoft requires the Session Hosts within one collection to use the same version level, while allowing separate collections. Connection Brokers in a highly available deployment must also share an operating-system level. The source’s compatibility example allows a Windows Server 2022 Session Host with a Windows Server 2025 Broker, but not the reverse pairing. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-supported-config). ## Applicability Use this review when designing or auditing a mixed-version RDS environment. Identify every collection, its member hosts, and the brokers serving it. Check the current interoperability tables for the actual proposed combinations. ## DSE recommendation Build a collection-membership matrix rather than relying on a deployment-wide list of servers. Have the RDS owner confirm the intended version for each collection and the consistent level of the broker group. Review any newly added host against that matrix before admitting user sessions. Keep a subsequent migration or upgrade sequence separately planned from this supported steady-state design. ## Verification Inspect actual collection membership and operating-system versions, then test representative sessions through the intended broker path. Record the specific host and collection serving each test. Resolve an inconsistent collection or unsupported broker pairing before adding more hosts. Retain the accepted matrix with the deployment inventory and review it after membership changes. ## Official references [Microsoft Learn: Supported Configurations for Remote Desktop Services](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-supported-config). Source reviewed September 8, 2026. ## Primary reference - Name: Supported Configurations for Remote Desktop Services - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-supported-config - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep each RDS session collection at a consistent Windows Server version,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-064-keep-each-rds-session-collection-at-a-consistent-windows-server-version/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep emergency drenching and flushing reachable in the seconds that matter > Emergency eyewash and drench equipment must match the corrosive-exposure hazard and remain immediately usable. Map each task, walk the real path, remove locks and obstructions, inspect activation and flow, train workers, and treat every impairment as an urgent operating condition. - Canonical URL: https://update.dsesecurity.com/updates/keep-emergency-drenching-flushing-immediately-reachable/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:23:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity - Reading time: 4 minutes ## What you need to know Emergency eyewash and drench equipment must match the corrosive-exposure hazard and remain immediately usable. Map each task, walk the real path, remove locks and obstructions, inspect activation and flow, train workers, and treat every impairment as an urgent operating condition. ## Potentially affected Work areas where corrosive materials may contact eyes or body; laboratories, battery areas, maintenance rooms, chemical storage and transfer points, cleaning operations, delivery and unloading areas, emergency eyewashes, drench showers, water supplies, and response procedures. ## DSE recommendation Complete a task-level corrosive-exposure assessment, match suitable flushing and drenching facilities to the exposed body area, verify immediate unobstructed access from every hazard point, inspect readiness, train workers hands-on, and control impairments before work continues. ## Article ## Source facts: possible corrosive exposure triggers immediate-use facilities OSHA’s general-industry medical and first-aid standard, [29 CFR 1910.151](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.151), requires suitable facilities for quick drenching or flushing of the eyes and body within the work area for immediate emergency use wherever a person’s eyes or body may be exposed to injurious corrosive materials. The standard also requires ready availability of medical personnel for plant-health consultation and, when no infirmary, clinic, or hospital is in near proximity, adequately trained first-aid personnel and readily available supplies. OSHA’s April 14, 2008 interpretation says there is no agency list of every chemical or concentration that requires an eyewash or shower and no threshold quantity that triggers the rule. The determining issue is possible employee exposure to injury from a corrosive. Safety data sheets and the actual work process help identify corrosivity and the ways a release, splash, sampling task, open container, transfer, connection, or maintenance activity could contact a worker. A February 27, 2007 interpretation explains that the OSHA standard does not prescribe detailed equipment specifications, while equipment complying with the relevant ANSI requirements would usually meet the standard’s intent. OSHA emphasizes that its own requirement is suitable facilities within the work area for immediate use. A locked path ordinarily creates a problem. The employer must assess the work-area configuration, material corrosivity, and contact potential, then provide suitable facilities for its own employees. OSHA also distinguishes prevention from consequence reduction. Required personal protective equipment is the first line of defense intended to prevent contact. Eyewash and shower equipment is intended to minimize injury when that defense fails. Providing one does not eliminate the need for the other. ## DSE recommendation: test reachability from the worker’s point of exposure Manage each unit as emergency equipment connected to specific tasks and hazards. A fixture shown on a floor plan may be unusable if the route, activation, water supply, or surrounding operation has changed. - Map exposure tasks. For every corrosive, record the safety data sheet, concentration, quantity, open or closed handling, pressure and temperature, transfer points, sampling, charging, cleaning, waste, delivery, maintenance, likely splash area, exposed body area, PPE, and people who could be present. - Select for the credible exposure. Have a qualified safety professional determine whether eye flushing, body drenching, or both are needed and what equipment, flow, duration, temperature control, drainage, freeze protection, and supplemental first-aid arrangements satisfy applicable rules and the hazard. - Walk the impaired path. Start at each exposure point and reach the equipment without assuming normal vision or dexterity. Remove locked doors, stored material, hoses, vehicles, pallets, level changes, narrow turns, snow, poor lighting, or doors that delay immediate use. Keep identification visible from the work position. - Verify activation and delivery. Use the manufacturer’s instructions and the organization’s approved inspection schedule to confirm the unit activates as designed, remains operating without improvised control, delivers suitable flushing to the intended area, drains safely, and is free of contamination or damage. - Train by doing. Before assignment, have workers locate and activate the equipment, demonstrate how they would hold eyelids or remove contaminated clothing as directed, summon help, and continue into the medical-response process. Include contractors, delivery personnel, lone workers, and after-hours access. - Control impairments. Label each unit, assign an owner, record inspections and repairs, and require immediate escalation for blocked access, failed flow, contamination, frozen piping, inadequate temperature, missing supply, or nearby construction. Suspend or redesign exposed work until suitable protection is restored. Reassess after chemical, concentration, container, equipment, layout, staffing, or process changes. During drills and inspections, measure the complete action from the task to effective flushing—not merely the distance on a drawing. Review near misses, activations, maintenance history, and worker feedback. The durable control is an exposed person reaching effective drenching or flushing immediately, under the conditions in which the emergency would actually happen. ## Official references - Occupational Safety and Health Administration, [29 CFR 1910.151: Medical services and first aid](https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.151); current regulation reviewed August 11, 2026. - Occupational Safety and Health Administration, [Requirement to provide accessible quick drenching and flushing facilities where there is exposure to corrosive materials](https://www.osha.gov/laws-regs/standardinterpretations/2007-02-27), February 27, 2007. - Occupational Safety and Health Administration, [Request to provide list of corrosive materials and concentrations requiring use of emergency eyewashes and showers](https://www.osha.gov/laws-regs/standardinterpretations/2008-04-14-0), April 14, 2008. ## Primary reference - Name: OSHA 29 CFR 1910.151: Medical services and first aid - Authority: Occupational Safety and Health Administration - URL: https://www.osha.gov/laws-regs/regulations/standardnumber/1910/1910.151 - Source publication date: 1998-06-18 ## Citation and use Preferred citation: “Keep emergency drenching and flushing reachable in the seconds that matter,” DSE Security, https://update.dsesecurity.com/updates/keep-emergency-drenching-flushing-immediately-reachable/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep essential functions running with FEMA continuity elements > FEMA continuity guidance connects essential functions to authority, people, facilities, communications, vital records, technology, devolution, reconstitution, and recurring exercises. - Canonical URL: https://update.dsesecurity.com/updates/fema-essential-functions-continuity-elements/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:26:27+00:00 - Modified: 2026-07-19T21:26:27+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Information - Topics: Business Continuity, IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know FEMA continuity guidance connects essential functions to authority, people, facilities, communications, vital records, technology, devolution, reconstitution, and recurring exercises. ## Potentially affected Private-sector organizations, critical-infrastructure owners, nongovernmental organizations, and public entities developing or refreshing continuity capabilities. ## DSE recommendation Identify essential functions, address each FEMA continuity element, coordinate related plans, exercise degraded conditions, and maintain evidence-backed improvements. ## Article Continuity is broader than keeping equipment powered. An organization must preserve essential functions when normal leaders, staff, facilities, communications, records, technology, or suppliers are unavailable—and then return to a stable operating state. ## What FEMA’s circular covers Source fact: FEMA’s Continuity Guidance Circular is intended for the whole community, including state, local, tribal, and territorial governments, nongovernmental organizations, and private-sector critical-infrastructure owners and operators. It supplies a framework that organizations can tailor based on applicable requirements, resources, size, functions, and risk. Source fact: FEMA continuity elements include essential functions, orders of succession, delegations of authority, continuity facilities, continuity communications, vital records, human capital, devolution, reconstitution, and testing, training, and exercises. The circular also calls for coordination with emergency operations, incident management, information-technology disaster recovery, pandemic, and business-continuity planning. ## A whole-service continuity review DSE recommendation: select one essential function and review every element against real operating evidence: - Define the function, its priority, minimum acceptable output, dependencies, and the consequences of interruption. - Name successors and document delegations with activation, scope, limits, and communication requirements. - Identify alternate facilities and remote options, including safety, access, equipment, connectivity, and logistical support. - Maintain redundant communication methods for leadership, staff, partners, suppliers, and customers when normal channels fail. - Identify vital records, where protected copies exist, who can retrieve them, and how their integrity and currency are verified. - Plan critical staffing, cross-training, accessibility, health and safety, and support for extended operations. - Define devolution when normal leadership or operations cannot perform the function and reconstitution when stable operations can resume. ## Exercise the degraded condition DSE recommendation: do not exercise only the best case. Remove a facility, communications channel, key decision maker, identity service, or supplier from the scenario. Confirm that people can locate current plans and records, understand authority, communicate, perform the minimum function, and report status. Record findings, owners, due dates, retest criteria, and any accepted residual risk. Coordinate improvements across continuity, emergency action, cyber incident, disaster recovery, occupational safety, crisis communications, and supplier plans. Contradictory activation authority or contact information can make individually polished plans fail together. ## Applicability and limits The circular is national guidance, not a universal private-sector regulation or a replacement for sector, accreditation, contractual, legal, or safety requirements. Organizations decide which options fit their circumstances. The guidance does not establish a guaranteed continuity duration, and having a written element does not prove it works. ## Official reference [FEMA Preparedness Toolkit: E.6 Continuity Guidance Circular](https://preptoolkit.fema.gov/web/cip-citap/ncig/-/knowledge_base/ncig/e-6-continuity-guidance-circular) — FEMA’s official overview of continuity capabilities for sustaining essential functions and critical services. ## Primary reference - Name: FEMA Preparedness Toolkit: E.6 Continuity Guidance Circular - Authority: Federal Emergency Management Agency - URL: https://preptoolkit.fema.gov/web/cip-citap/ncig/-/knowledge_base/ncig/e-6-continuity-guidance-circular - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep essential functions running with FEMA continuity elements,” DSE Security, https://update.dsesecurity.com/updates/fema-essential-functions-continuity-elements/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep essential records findable and usable during an outage > Identify and protect the records required to continue essential operations and preserve legal or financial rights during disruption. - Canonical URL: https://update.dsesecurity.com/updates/keep-essential-records-usable-during-outage/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:31+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know Identify and protect the records required to continue essential operations and preserve legal or financial rights during disruption. ## Potentially affected Organizations whose emergency operations, recovery decisions, or stakeholder rights depend on records that may become unavailable ## DSE recommendation Maintain a narrow essential-records inventory with resilient access methods, owners, update triggers, and tested retrieval. ## Article A backup catalog is not an essential-records program. The organization must know which small set of records it needs during and immediately after disruption, who can retrieve them, and whether they remain understandable and authoritative when normal systems are unavailable. ## Source fact: [The U.S. National Archives and Records Administration’s Essential Records Guide](https://www.archives.gov/records-mgmt/essential-records/essential-records-guide) describes records needed to continue operations during an emergency and records needed to protect the legal and financial rights of the government and people affected by government activity. It emphasizes identifying, protecting, and making those records available when required. NARA’s program guidance is written for federal records management, while the guide notes that nonfederal organizations may also find the concepts useful. Essential records are selected because of their emergency value; the category is not intended to include every important or permanent record. Protection may involve duplication, dispersal, or other measures suited to the record and threat. ## Boundary This article does not determine statutory retention, evidentiary status, privacy obligations, or which records are legally “vital” for a particular organization. Records-management counsel and accountable business owners must make those determinations. A duplicated record can still be unusable if it is stale, encrypted without available keys, stored in a proprietary format, missing context, or inaccessible to authorized incident staff. ## Applicability questions - Which records are needed in the first hours and days to direct emergency operations? - Which records protect employees, customers, owners, or other parties’ legal and financial rights? - What system, physical location, identity service, cryptographic key, application, and specialist knowledge does retrieval depend on? - How frequently does each record change, and what event should refresh its protected copy? - Who may access it under emergency conditions, and how is that access audited? ## DSE recommendation: Interview continuity, legal, finance, human resources, facilities, security, IT, and service owners against specific incident decisions. Record each selected item, authoritative source, purpose, owner, update frequency, sensitivity, format, retrieval dependency, protection method, and alternate custodian. Keep the selection narrow enough to maintain and exercise. Store protected copies or replicas in a location and failure domain appropriate to the threat, with encryption and access controls matching the data. Preserve the software, keys, schemas, code lists, and instructions needed to interpret the record. Provide an offline index that tells authorized staff what exists and how to request it without exposing the record itself. Tie material process and system changes to inventory review. ## Verification and evidence At a defined interval, give an authorized person an incident scenario and require retrieval from the protected method without using the primary system. Verify freshness, completeness, readability, authority, access logging, and the ability to use the record for its intended decision. Retain the approved inventory, owners’ attestations, protection configuration, test results, exceptions, and remediation dates. Test destruction or revocation rules separately where protected copies should not persist indefinitely. ## Official references - [NARA Essential Records Guide](https://www.archives.gov/records-mgmt/essential-records/essential-records-guide) ## Primary reference - Name: Essential Records Guide - Authority: www.archives.gov - URL: https://www.archives.gov/records-mgmt/essential-records/essential-records-guide - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep essential records findable and usable during an outage,” DSE Security, https://update.dsesecurity.com/updates/keep-essential-records-usable-during-outage/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep GPU resource-pool names consistent across clustered DDA hosts > How should clustered GPU assignment be represented across Hyper-V nodes? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-230-keep-gpu-resource-pool-names-consistent-across-clustered-dda-hosts/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:21+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know How should clustered GPU assignment be represented across Hyper-V nodes? ## Potentially affected Administrators assigning dedicated GPUs to clustered VMs using DDA. ## DSE recommendation Create a per-node GPU inventory linked to the intended shared pool name and VM assignments. ## Article ## Source facts Microsoft documents dedicating physical GPUs to clustered VMs through DDA as distinct from GPU partitioning. The cluster uses a GPU resource pool to determine placement of VMs assigned to that pool. The PowerShell procedure creates a pool on each server and requires the same pool name on every server. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/use-gpu-with-clustered-vm). ## Applicability Confirm the supported cluster, GPU, and VM requirements in the current source before preparing pools. Inventory the available hardware on each intended node. Keep a matching pool label separate from proof that every node has suitable hardware and capacity. ## DSE recommendation Create a per-node GPU inventory linked to the intended shared pool name and VM assignments. Have the hardware and virtualization owners review the mapping together. Preserve the host device state and the VM preparation settings before the pilot. Define where the VM should be allowed to start or move and which observed condition will block placement. ## Verification Inspect pool names and membership on every intended host, then assign a representative prepared VM. Verify its actual GPU and workload behavior on the permitted placement paths. Exercise the agreed failover scenario and record the selected node and hardware. Resolve inconsistent names, missing devices, or unexpected placement before assigning more workloads. ## Official references [Microsoft Learn: Use GPUs with Discrete Device Assignment in clustered VMs on Windows Server and Azure Local](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/use-gpu-with-clustered-vm). Source reviewed September 8, 2026. ## Primary reference - Name: Use GPUs with Discrete Device Assignment in clustered VMs on Windows Server and Azure Local - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/use-gpu-with-clustered-vm - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep GPU resource-pool names consistent across clustered DDA hosts,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-230-keep-gpu-resource-pool-names-consistent-across-clustered-dda-hosts/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep JMAP mail objects in separate method families > Use RFC 8621 — The JSON Meta Application Protocol (JMAP) for Mail to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-jmap-mail-objects-in-separate-method-families/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:00+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8621 — The JSON Meta Application Protocol (JMAP) for Mail to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8621 — The JSON Meta Application Protocol (JMAP) for Mail ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Keep JMAP mail objects in separate method families. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8621 — The JSON Meta Application Protocol (JMAP) for Mail](https://www.rfc-editor.org/rfc/rfc8621.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A Mailbox is a named collection of Email objects, and moving an Email between Mailboxes does not change the Email object’s identifier. The research record locates this support at Section 2 (Mailboxes). - An Email object represents one RFC 5322 message independently of the Mailbox and Thread objects that organize or group it. The research record locates this support at Section 4 (Emails). - An EmailSubmission is a separate object that references an Email and an Identity and tracks envelope, release, cancellation, and per-recipient delivery status. The research record locates this support at Section 7 (Email Submission). The source support ends with the statements listed above. Use them to examine sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 2 (Mailboxes), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4 (Emails), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 7 (Email Submission), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from Section 2 (Mailboxes); Section 4 (Emails); Section 7 (Email Submission) through sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 8621 — The JSON Meta Application Protocol (JMAP) for Mail](https://www.rfc-editor.org/rfc/rfc8621.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8621 — The JSON Meta Application Protocol (JMAP) for Mail - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8621.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep JMAP mail objects in separate method families,” DSE Security, https://update.dsesecurity.com/updates/keep-jmap-mail-objects-in-separate-method-families/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep labels, safety data sheets, and training synchronized after change > Use 29 CFR 1910.1200 - Hazard Communication to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-labels-safety-data-sheets-and-training-synchronized-after-change/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:26+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.1200 - Hazard Communication to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.1200 - Hazard Communication ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Keep labels, safety data sheets, and training synchronized after change. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.1200 – Hazard Communication](https://www.ecfr.gov/current/title-29/section-1910.1200) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, in addition, this section requires distributors to transmit the required information to employers. (Employers who do not produce or import chemicals need only focus on those parts of this rule that deal with establishing a workplace program and communicating information to their workers.). The research record locates this support at 29 CFR 1910.1200(b)(1) (eCFR anchor p-1910.1200(b)(1)). - Under 29 CFR 1910, the rule requires that employers provide employees with effective information and training on hazardous chemicals in their work area at the time of their initial assignment, and whenever a new chemical hazard the employees have not previously been trained about is introduced into their work area. The research record locates this support at 29 CFR 1910.1200(h)(1) (eCFR anchor p-1910.1200(h)(1)). Keep the evidence boundary at these traced claims. They support a review of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Federal workplace rule; classification, exemptions, multi-employer coordination, and state-plan requirements must be evaluated for the actual chemicals and work. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.1200(b)(1) (eCFR anchor p-1910.1200(b)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.1200(h)(1) (eCFR anchor p-1910.1200(h)(1)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to 29 CFR 1910.1200(b)(1) (eCFR anchor p-1910.1200(b)(1)); 29 CFR 1910.1200(h)(1) (eCFR anchor p-1910.1200(h)(1)) and to observable material such as facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [29 CFR 1910.1200 – Hazard Communication](https://www.ecfr.gov/current/title-29/section-1910.1200) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.1200 - Hazard Communication - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.1200 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep labels, safety data sheets, and training synchronized after change,” DSE Security, https://update.dsesecurity.com/updates/keep-labels-safety-data-sheets-and-training-synchronized-after-change/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep Linux guest adapter identity stable during cluster failover > What network-adapter settings should be reviewed before failing over a Linux VM? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-124-keep-linux-guest-adapter-identity-stable-during-cluster-failover/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:07+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What network-adapter settings should be reviewed before failing over a Linux VM? ## Potentially affected Administrators operating Linux VMs on Hyper-V failover clusters. ## DSE recommendation Record the expected guest interface names and addresses alongside the configured virtual adapters. ## Article ## Source facts Microsoft recommends a static MAC address for every virtual adapter of a clustered Linux VM. Some Linux versions can lose network configuration after failover if a different MAC address is assigned. Its Linux guidance also recommends the Hyper-V-specific virtual Ethernet adapter. Mixing legacy and Hyper-V-specific adapters can produce unexpected interface names, so Microsoft advises removing legacy adapters when using the Hyper-V-specific adapter. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/Best-Practices-for-running-Linux-on-Hyper-V). ## Applicability Identify the Linux distribution and release, guest integration components, adapter types, MAC assignments, and network configuration files. Check the distribution-specific support guidance before changing guest networking. ## DSE recommendation Record the expected guest interface names and addresses alongside the configured virtual adapters. Have the Linux and virtualization owners review the mapping and approve any removal of an unused legacy adapter. Define a recovery route that does not depend solely on the interface being changed. ## Verification Test a controlled cluster move and compare the guest’s adapter identities and connectivity before and afterward. Include a guest restart and an application transaction using the intended interface. Record an unexpected rename or missing network configuration as a failure to resolve before scheduling routine failover operations. ## Official references [Microsoft Learn: Best Practices for running Linux on Hyper-V](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/Best-Practices-for-running-Linux-on-Hyper-V). Source reviewed September 8, 2026. ## Primary reference - Name: Best Practices for running Linux on Hyper-V - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/Best-Practices-for-running-Linux-on-Hyper-V - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep Linux guest adapter identity stable during cluster failover,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-124-keep-linux-guest-adapter-identity-stable-during-cluster-failover/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep maritime-security communications available among facilities, vessels, authorities, and personnel > Use 33 CFR 105.235 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-maritime-security-communications-available-among-facilities-vessels-authorities-and-personnel/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:15+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.235 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.235 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Keep maritime-security communications available among facilities, vessels, authorities, and personnel. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.235 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.235) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that communication systems and procedures allow effective and continuous communications between the facility security personnel, vessels interfacing with the facility, the cognizant COTP, and national and local authorities with security responsibilities. The research record locates this support at 33 CFR 105.235(b) (eCFR anchor p-105.235(b)). - Under 33 CFR 105, the rule requires that the Facility Security Officer have a means to effectively notify facility personnel of changes in security conditions at the facility. The research record locates this support at 33 CFR 105.235(a) (eCFR anchor p-105.235(a)). Keep the evidence boundary at these traced claims. They support a review of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.235(b) (eCFR anchor p-105.235(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.235(a) (eCFR anchor p-105.235(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 33 CFR 105.235(b) (eCFR anchor p-105.235(b)); 33 CFR 105.235(a) (eCFR anchor p-105.235(a)). Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [33 CFR 105.235 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.235) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.235 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.235 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep maritime-security communications available among facilities, vessels, authorities, and personnel,” DSE Security, https://update.dsesecurity.com/updates/keep-maritime-security-communications-available-among-facilities-vessels-authorities-and-personnel/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep MSP operator identities and customer administration out of the corporate collaboration tenant > An MSP identity exposed to ordinary email and browsing can become a route into customer administration. Separate privileged operators, devices, policies, secrets, and monitoring from collaboration activity. - Canonical URL: https://update.dsesecurity.com/updates/isolate-msp-operator-identities-customer-administration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:24:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know An MSP identity exposed to ordinary email and browsing can become a route into customer administration. Separate privileged operators, devices, policies, secrets, and monitoring from collaboration activity. ## Potentially affected MSP Microsoft Entra tenants; Partner Center; email and collaboration accounts; privileged administrator accounts; service identities; technician workstations; RMM and PSA access; vaults; and customer administration. ## DSE recommendation Create a dedicated privileged identity plane, separate administrative accounts from email identities, require protected devices and phishing-resistant authentication, prohibit shared accounts, monitor partner actions, and test containment. ## Article ## Source facts: MSP identities sit on a high-consequence trust path Microsoft’s [Cloud Solution Provider security best practices](https://learn.microsoft.com/en-us/partner-center/security/csp-security-best-practices) address the elevated risk around partner tenants and customer administration. The guidance calls for multifactor authentication, least privilege, removal of unused delegated access, monitoring, incident response, and stronger protection for identities that can act in customer environments. Microsoft also recommends separating privileged administrative accounts from ordinary productivity use and protecting privileged work through controlled devices and policies. CISA’s advisory on protecting managed service providers and their customers explains why this architecture matters beyond one vendor. Attackers can target an MSP’s centralized tools, credentials, and trusted relationships to reach multiple customers. CISA recommends hardening remote access, using strong authentication, restricting privileged access, separating internal and customer environments where appropriate, logging provider activity, and agreeing on responsibilities with customers. A separate identity plane does not have to mean that every tool is placed in one new tenant, and it does not make the provider immune to compromise. It means identities with customer impact are not routinely exposed to inbox links, general web sessions, collaboration applications, and unmanaged endpoints. The appropriate implementation depends on licensing, tool federation, customer contracts, availability requirements, and each vendor’s supported identity model. ## DSE recommendation: design a customer-administration identity plane Treat the MSP’s administrative identity system as production infrastructure for every customer it can affect. Its architecture should limit how far a single phished account, stolen token, malicious extension, or compromised workstation can travel. - Map privileged paths. Inventory Partner Center, GDAP, RMM, PSA, backup, documentation, password vault, firewall, cloud, registrar, security tooling, and customer-local accounts. Record identity provider, authentication flow, session duration, customer reach, owner, and recovery path. - Separate human identities. Give administrators distinct named accounts for customer work and corporate collaboration. Do not provision mailboxes, chat, social applications, or ordinary browsing access to privileged identities unless there is a documented operational need. Never use shared technician accounts. - Protect the device path. Require administration from hardened, managed devices or privileged access workstations. Limit browser extensions and local administrator rights, enforce device health, patch quickly, control removable media, and prevent privileged sessions from being copied into unmanaged environments. - Use strong, scoped authentication. Prefer phishing-resistant credentials, conditional access, short sessions, and time-bound elevation. Restrict source locations where practical. Store recovery material separately, protect break-glass accounts, and alert on changes to authentication methods and policies. - Constrain service identities. Replace embedded or shared secrets with managed, rotatable credentials where supported. Document every non-human account, permitted customers and actions, owners, expiry, and evidence. Do not let an automation identity inherit the combined reach of every technician. - Correlate customer-impacting activity. Send identity, Partner Center, vault, RMM, and administrative logs to protected monitoring. Associate high-risk actions with an operator, device, customer, ticket, and time. Alert on impossible travel, unusual customers, bulk changes, policy tampering, and access outside expected workflows. - Test containment. Run exercises for a phished collaboration account, stolen privileged token, lost workstation, compromised RMM identity, and disabled identity provider. Verify that responders can revoke sessions, isolate devices, disable customer paths, notify affected customers, and preserve evidence without destroying recovery access. Factual boundary: Microsoft and CISA publish security practices, not a universal requirement that every MSP create a particular tenant topology. Separation reduces shared exposure but also creates operational and recovery dependencies. Architecture must be tested against supported product behavior and customer obligations. Measure privileged identities with collaboration access, customer reach per identity, phishing-resistant enrollment, unmanaged privileged sessions, stale service accounts, log coverage, and containment time. The goal is a defensible boundary: compromising an ordinary corporate session should not immediately grant an attacker the provider’s customer-administration authority. ## Official references - Microsoft Learn, [Security best practices for Cloud Solution Provider partners](https://learn.microsoft.com/en-us/partner-center/security/csp-security-best-practices). - CISA, [Protecting Against Cyber Threats to Managed Service Providers and their Customers](https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-131a). - Microsoft Learn, [Customer security best practices](https://learn.microsoft.com/en-us/partner-center/security/customer-security-best-practices). ## Primary reference - Name: Microsoft Learn: Security best practices for Cloud Solution Provider partners - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/partner-center/security/csp-security-best-practices - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep MSP operator identities and customer administration out of the corporate collaboration tenant,” DSE Security, https://update.dsesecurity.com/updates/isolate-msp-operator-identities-customer-administration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep NRC physical-protection records linked to the requirement they evidence > Use 10 CFR 73.70 - Records to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-nrc-physical-protection-records-linked-to-the-requirement-they-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:39+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.70 - Records to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.70 - Records ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Keep NRC physical-protection records linked to the requirement they evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.70 – Records](https://www.ecfr.gov/current/title-10/section-73.70) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, the rule requires that the licensee retain this record of currently designated authorized individuals for the period during which the licensee possesses the appropriate type and quantity of special nuclear material requiring this record under each license that authorizes the activity that is subject to the recordkeeping requirement and, for three years thereafter. The research record locates this support at 10 CFR 73.70(a) (eCFR anchor p-73.70(a)). - Under 10 CFR 73, the rule requires that the licensee retain the documentation for these events for three years from the date of documenting each event. The research record locates this support at 10 CFR 73.70(e) (eCFR anchor p-73.70(e)). Keep the evidence boundary at these traced claims. They support a review of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish NRC regulation; exact record types, retention periods, protected information, electronic systems, license conditions, and inspections require full-rule and qualified review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.70(a) (eCFR anchor p-73.70(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.70(e) (eCFR anchor p-73.70(e)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 10 CFR 73.70(a) (eCFR anchor p-73.70(a)); 10 CFR 73.70(e) (eCFR anchor p-73.70(e)). Favor asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [10 CFR 73.70 – Records](https://www.ecfr.gov/current/title-10/section-73.70) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.70 - Records - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.70 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep NRC physical-protection records linked to the requirement they evidence,” DSE Security, https://update.dsesecurity.com/updates/keep-nrc-physical-protection-records-linked-to-the-requirement-they-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep PACE participants connected to care during community disruption > Use 42 CFR 460.84 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-pace-participants-connected-to-care-during-community-disruption/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:06+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 460.84 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 460.84 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Keep PACE participants connected to care during community disruption. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 460.84 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-460.84) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 460, the rule requires that the PACE organization do all of the following: initial training in emergency preparedness policies and procedures to all new and existing staff, individuals providing on-site services under arrangement, contractors, participants, and volunteers, consistent with their expected roles. The research record locates this support at 42 CFR 460.84(d)(1)(i), read with 42 CFR 460.84(d)(1) (eCFR anchor p-460.84(d)(1)(i)). - Under 42 CFR 460, the rule requires that the PACE organization develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 460.84(d) (eCFR anchor p-460.84(d)). Only the traced statements above are asserted as source facts. Apply the review to essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives after confirming that the source and deployed context match. ## What the source does not establish PACE-specific federal requirement; participant needs, transportation, center operations, contracted care, medication, state agreements, and current CMS guidance require local planning. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 460.84(d)(1)(i), read with 42 CFR 460.84(d)(1) (eCFR anchor p-460.84(d)(1)(i)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 460.84(d) (eCFR anchor p-460.84(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from 42 CFR 460.84(d)(1)(i), read with 42 CFR 460.84(d)(1) (eCFR anchor p-460.84(d)(1)(i)); 42 CFR 460.84(d) (eCFR anchor p-460.84(d)) through business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [42 CFR 460.84 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-460.84) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 460.84 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-460.84 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep PACE participants connected to care during community disruption,” DSE Security, https://update.dsesecurity.com/updates/keep-pace-participants-connected-to-care-during-community-disruption/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep privileged administration off ordinary workstations > MFA cannot make an already-compromised workstation trustworthy. Dedicated privileged access workstations separate administration from email, general browsing, and everyday applications so high-impact credentials and sessions begin from a controlled device. - Canonical URL: https://update.dsesecurity.com/updates/keep-privileged-administration-on-dedicated-workstations/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-11T09:53:00+00:00 - Modified: 2026-08-11T14:12:10+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 4 minutes ## What you need to know MFA cannot make an already-compromised workstation trustworthy. Dedicated privileged access workstations separate administration from email, general browsing, and everyday applications so high-impact credentials and sessions begin from a controlled device. ## Potentially affected Microsoft Entra ID, Active Directory, hypervisors, backup platforms, firewalls, cloud portals, RMM tools, certificate services, security platforms, and other high-impact administration interfaces. ## DSE recommendation Classify privileged roles and interfaces, issue separate administrator identities and dedicated hardened devices, restrict where those identities can sign in, and continuously monitor privileged activity. ## Article ## Source fact: the originating device is part of the security decision Microsoft’s privileged-access guidance says that protecting roles and accounts is not enough. The device, administrative interface, and any intermediary—such as a jump server, VPN, or virtual desktop—form part of the end-to-end privileged session. If an attacker controls the originating device, the attacker may impersonate the administrator during the session or steal credentials and tokens for later use. Microsoft defines a Privileged Access Workstation (PAW) as a dedicated, hardened device used only for administrative tasks. It is separate from ordinary user devices and restricts general browsing and productivity activity. The objective is to prevent privileged credentials and actions from being exposed to an untrusted environment. The current Microsoft model describes privileged access as explicitly controlled, isolated from normal activity, continuously monitored, and assumed to be a primary target. Recommended safeguards include strong authentication, managed and compliant devices, time-bound elevation, device hardening, restricted connectivity, and monitoring of identity and endpoint behavior. ## Source fact: MFA does not repair a compromised endpoint Strong multifactor authentication is essential, but it proves only the factors and conditions evaluated by the authentication system. Malware controlling the workstation may still capture a session, abuse an already-authorized browser, alter an administrator’s intended command, or wait until privilege is activated. A separate trusted administrative device reduces the opportunity for email attachments, arbitrary websites, consumer software, and ordinary user activity to share the same execution environment as high-impact administration. ## DSE recommendation: define the privileged plane first Create an inventory of roles and interfaces capable of changing identity, security policy, code, backups, network traffic, or business-critical systems. Include Global and Domain Administrators, hypervisor and backup administrators, firewall and switching control, RMM platforms, certificate authorities, password and secret stores, security-management consoles, domain registrars, video-management systems, and access-control administration. Classify each role by potential impact rather than job title. A technician with authority to deploy software to every endpoint may present more organizational risk than a conventional server administrator. Document the approved device, account, interface, elevation method, and monitoring source for every privileged path. ## DSE recommendation: separate identities, devices, and activities - Issue separate accounts. Ordinary email and collaboration should use a standard identity. Administration should use a distinct account that is not licensed or configured for routine productivity unless a documented requirement exists. - Provide a dedicated device or isolated service. Use a PAW, tightly controlled virtual administrative desktop, or comparable architecture whose security assurance is maintained end to end. - Restrict sign-in locations. Permit privileged identities only from approved compliant devices and administrative paths. Block their use from unmanaged devices and ordinary workstations. - Use phishing-resistant authentication. Choose supported FIDO2/passkey, certificate, or other phishing-resistant methods and maintain separately protected emergency access. - Minimize software and destinations. Remove local administrative rights where unnecessary, control application execution, disable general email, and restrict browsing to required administration sites. - Encrypt and harden the device. Maintain secure boot, TPM-backed protection, full-disk encryption, endpoint detection, host firewall policy, timely updates, and controlled provisioning. ## DSE recommendation: do not weaken the chain through an intermediary A jump server does not automatically create a trusted path. It must be managed, monitored, patched, and restricted to at least the assurance required by the target system. Clipboard transfer, drive mapping, downloads, browser use, and outbound connectivity should be allowed only when required. Administrative connections should terminate at named systems through approved protocols rather than opening broad network access. Apply the same principle to vendor support. A third party should not enter the privileged plane through a shared VPN account or an unmanaged technician laptop. Use individually attributable identities, approved access devices or controlled intermediaries, limited destinations, time bounds, and recorded approval. ## DSE recommendation: prove that the model is operating Alert on privileged sign-ins from unapproved devices, unexpected role activation, security-policy changes, disabled monitoring, new local administrators, and attempts to use administrative accounts for email or general applications. Review PAW compliance and administrative group membership regularly. Test replacement, recovery, and emergency access before a device failure or tenant lockout. A PAW program is complete only when administrators can perform necessary work, emergency paths remain available, and high-impact credentials no longer appear on ordinary endpoints. ## Official references - [Microsoft Learn: Privileged access](https://learn.microsoft.com/en-us/security/zero-trust/security-concept-privileged-access) - [Microsoft Learn: Securing privileged access devices](https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-devices) - [Microsoft Learn: Securing privileged access interfaces](https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-interfaces) - [Microsoft Learn: Securing privileged access intermediaries](https://learn.microsoft.com/en-us/security/privileged-access-workstations/privileged-access-intermediaries) ## Primary reference - Name: Microsoft Learn: Privileged access - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/security/zero-trust/security-concept-privileged-access - Source publication date: 2026-05-31 ## Citation and use Preferred citation: “Keep privileged administration off ordinary workstations,” DSE Security, https://update.dsesecurity.com/updates/keep-privileged-administration-on-dedicated-workstations/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep Program 2 safety information current for substances, processes, and equipment > Use 40 CFR 68.48 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-program-2-safety-information-current-for-substances-processes-and-equipment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:10+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.48 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.48 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Keep Program 2 safety information current for substances, processes, and equipment. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.48 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.48) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the owner or operator compile and maintain the following up-to-date safety information related to the regulated substances, processes, and equipment: equipment specifications. The research record locates this support at 40 CFR 68.48(a)(4), read with 40 CFR 68.48(a) (eCFR anchor p-68.48(a)(4)). - Under 40 CFR 68, the rule requires that the owner or operator compile and maintain the following up-to-date safety information related to the regulated substances, processes, and equipment: codes and standards used to design, build, and operate the process. The research record locates this support at 40 CFR 68.48(a)(5), read with 40 CFR 68.48(a) (eCFR anchor p-68.48(a)(5)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths only where the source and recorded environment align. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.48(a)(4), read with 40 CFR 68.48(a) (eCFR anchor p-68.48(a)(4)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.48(a)(5), read with 40 CFR 68.48(a) (eCFR anchor p-68.48(a)(5)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from 40 CFR 68.48(a)(4), read with 40 CFR 68.48(a) (eCFR anchor p-68.48(a)(4)); 40 CFR 68.48(a)(5), read with 40 CFR 68.48(a) (eCFR anchor p-68.48(a)(5)) through facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [40 CFR 68.48 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.48) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.48 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.48 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep Program 2 safety information current for substances, processes, and equipment,” DSE Security, https://update.dsesecurity.com/updates/keep-program-2-safety-information-current-for-substances-processes-and-equipment/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep Program 3 operating procedures accurate, accessible, and annually certified > Use 40 CFR 68.69 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-program-3-operating-procedures-accurate-accessible-and-annually-certified/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:59+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.69 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.69 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Keep Program 3 operating procedures accurate, accessible, and annually certified. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.69 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.69) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the operating procedures be reviewed as often as necessary to assure that they reflect current operating practice, including changes that result from changes in process chemicals, technology, and equipment, and changes to stationary sources. The research record locates this support at 40 CFR 68.69(c) (eCFR anchor p-68.69(c)). - Under 40 CFR 68, the rule requires that operating procedures be readily accessible to employees who work in or maintain a process. The research record locates this support at 40 CFR 68.69(b) (eCFR anchor p-68.69(b)). Keep the evidence boundary at these traced claims. They support a review of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.69(c) (eCFR anchor p-68.69(c)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.69(b) (eCFR anchor p-68.69(b)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 40 CFR 68.69(c) (eCFR anchor p-68.69(c)); 40 CFR 68.69(b) (eCFR anchor p-68.69(b)). Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [40 CFR 68.69 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.69) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.69 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.69 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep Program 3 operating procedures accurate, accessible, and annually certified,” DSE Security, https://update.dsesecurity.com/updates/keep-program-3-operating-procedures-accurate-accessible-and-annually-certified/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep protected machine accounts disabled until Microsoft resolves rotation > Use Credential Guard protected machine accounts in Windows Server 2025 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-protected-machine-accounts-disabled-until-fixed/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:39+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Credential Guard protected machine accounts in Windows Server 2025 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Credential Guard protected machine accounts in Windows Server 2025 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Keep protected machine accounts disabled until Microsoft resolves rotation. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Credential Guard protected machine accounts in Windows Server 2025](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/credential-guard-protected-machine-accounts) from Microsoft supports the following bounded statements: - Microsoft states that Credential Guard protected machine accounts are temporarily disabled because of a Kerberos machine-password rotation issue. The research record locates this support at Opening important notice. - FAST and managed service accounts increasingly depend on machine-account identity. The research record locates this support at Opening overview. Only the traced statements above are asserted as source facts. Apply the review to forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles after confirming that the source and deployed context match. ## What the source does not establish This is status-sensitive guidance; recheck the official page before any deployment decision. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening important notice, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations Opening important notice; Opening overview adjacent to the sanitized artifacts used for comparison. Prefer directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Credential Guard protected machine accounts in Windows Server 2025](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/credential-guard-protected-machine-accounts) — Microsoft ## Primary reference - Name: Credential Guard protected machine accounts in Windows Server 2025 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/credential-guard-protected-machine-accounts - Source publication date: 2025-04-11 ## Citation and use Preferred citation: “Keep protected machine accounts disabled until Microsoft resolves rotation,” DSE Security, https://update.dsesecurity.com/updates/keep-protected-machine-accounts-disabled-until-fixed/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep public-access facility exemptions conditional and reachable > Use 33 CFR 105.110 - Exemptions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-public-access-facility-exemptions-conditional-and-reachable/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:58+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.110 - Exemptions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.110 - Exemptions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Keep public-access facility exemptions conditional and reachable. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.110 – Exemptions](https://www.ecfr.gov/current/title-33/section-105.110) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, a designated public-access area is exempt from the specified screening and identification requirements in sections 105.255 and 105.285(a)(1). The research record locates this support at 33 CFR 105.110(a) (eCFR anchor p-105.110(a)). - An exempted public-access facility must comply with every COTP condition and keep the COTP supplied with current contact information for the person responsible for facility security. The research record locates this support at 33 CFR 105.110(c)(2)(i) and 105.110(c)(2)(ii), read with 33 CFR 105.110(c)(2) (eCFR anchors p-105.110(c)(2)(i) and p-105.110(c)(2)(ii)). Keep the evidence boundary at these traced claims. They support a review of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This applies only to exemptions within 33 CFR 105.110. It does not create an exemption, displace COTP conditions, or excuse security measures imposed under other authority. A correct source interpretation can still be inapplicable to a particular design. Confirm identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 33 CFR 105.110(a) (eCFR anchor p-105.110(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.110(c)(2)(i) and 105.110(c)(2)(ii), read with 33 CFR 105.110(c)(2) (eCFR anchors p-105.110(c)(2)(i) and p-105.110(c)(2)(ii)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 33 CFR 105.110(a) (eCFR anchor p-105.110(a)); 33 CFR 105.110(c)(2)(i) and 105.110(c)(2)(ii), read with 33 CFR 105.110(c)(2) (eCFR anchors p-105.110(c)(2)(i) and p-105.110(c)(2)(ii)). Favor approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [33 CFR 105.110 – Exemptions](https://www.ecfr.gov/current/title-33/section-105.110) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.110 - Exemptions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.110 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep public-access facility exemptions conditional and reachable,” DSE Security, https://update.dsesecurity.com/updates/keep-public-access-facility-exemptions-conditional-and-reachable/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep RDP credentials off the target with Remote Credential Guard > Use Remote Credential Guard to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-rdp-credentials-off-target-with-remote-credential-guard/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:42+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Use Remote Credential Guard to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remote Credential Guard ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Keep RDP credentials off the target with Remote Credential Guard. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remote Credential Guard](https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard) from Microsoft supports the following bounded statements: - Remote Credential Guard redirects Kerberos requests to the originating device instead of sending credentials to the RDP target. The research record locates this support at Opening overview. - It protects credentials and derivatives from a compromised target while retaining Remote Desktop single sign-on. The research record locates this support at Opening overview. Keep the evidence boundary at these traced claims. They support a review of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Confirm OS, domain, Kerberos, delegation, and client requirements before requiring it. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as policy and feature state, security events, test detections, administrative assignments, exception approvals, and response tickets. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Remote Credential Guard](https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard) — Microsoft ## Primary reference - Name: Remote Credential Guard - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard - Source publication date: 2026-03-29 ## Citation and use Preferred citation: “Keep RDP credentials off the target with Remote Credential Guard,” DSE Security, https://update.dsesecurity.com/updates/keep-rdp-credentials-off-target-with-remote-credential-guard/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep RFC 2544 overload tests inside an isolated lab > Prevent benchmark traffic designed to overload network devices from disrupting production services. - Canonical URL: https://update.dsesecurity.com/updates/keep-rfc-2544-overload-tests-isolated/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:39+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Briefing - DSE priority: Important - Topics: Business Continuity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Prevent benchmark traffic designed to overload network devices from disrupting production services. ## Potentially affected Network teams, service providers, and test vendors using RFC 2544-style throughput, latency, frame-loss, or recovery benchmarks ## DSE recommendation Confine device-overload benchmarking to isolated test paths and use production-safe service methods for live networks. ## Article RFC 2544 benchmarking methods deliberately push a device or path toward overload. Running that traffic on a network carrying users can create the congestion, loss, and service interruption the test is designed to observe. ## Source fact: [IETF RFC 6815](https://www.rfc-editor.org/rfc/rfc6815.html) states that the benchmarking methods described by RFC 2544 were designed for isolated laboratory environments. Those methods seek performance limits by offering loads that can overload the device or system under test. Applying them to production networks can harm user traffic, and RFC 6815 describes that use as inappropriate. The warning covers more than an obvious maximum-rate throughput run. Test sequences for frame loss, back-to-back frames, system recovery, and reset behavior can introduce disruptive conditions or intentionally affect the device. RFC 6815 directs operators toward methods intended for in-service measurement when the goal is to assess a live service. ## Boundary The applicability statement does not prohibit RFC 2544 benchmarking in a properly isolated lab, factory acceptance setup, or maintenance environment where no production traffic can be affected and all participants approve the risk. Calling a VLAN, test identifier, or low-usage window “isolated” is not enough if it shares queues, processors, links, control plane, power, or failure domains with production. Other test standards have their own applicability requirements. ## Applicability questions - Is the request benchmarking a device limit or measuring a live service objective? - Can test traffic reach any production queue, control plane, shared uplink, provider domain, or customer endpoint? - Does the test include overload, reset, recovery, or frame-loss searches? - Have all network owners and the carrier approved the exact traffic profile and demarcation? - Is there an in-service method that answers the operational question with bounded load? ## DSE recommendation: Classify test requests before scheduling them. Send RFC 2544 device benchmarking to a physically or demonstrably isolated environment with representative hardware and configuration. Validate isolation by topology and resource dependency, not only IP addressing. Put rate limits and an independent stop mechanism around the generator, and prevent accidental routing or bridging into production. For a live circuit, define the service characteristic being validated and select a method explicitly designed for in-service or service-activation use, consistent with the provider contract and equipment guidance. Bound the offered load, duration, and traffic class. Monitor user-impact indicators and give operations authority to stop the test. Never let a vendor label override the risk assessment of the actual packet pattern. ## Verification and evidence Retain the test objective, selected methodology, generator configuration, topology, proof of isolation or production-safe load bound, approvals, maintenance window, stop conditions, and monitoring results. In the lab, record device limits without generalizing them beyond the tested software, ports, frame sizes, and features. On live services, document that the method and load differed from RFC 2544 overload benchmarking. ## Official references - [IETF RFC 6815](https://www.rfc-editor.org/rfc/rfc6815.html) - [IETF RFC 2544, Benchmarking Methodology for Network Interconnect Devices](https://www.rfc-editor.org/rfc/rfc2544.html) ## Primary reference - Name: RFC 6815: Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6815.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep RFC 2544 overload tests inside an isolated lab,” DSE Security, https://update.dsesecurity.com/updates/keep-rfc-2544-overload-tests-isolated/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep roaming-profile storage separate from redirected-folder shares > How should the storage location and user scope for roaming profiles be prepared? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-055-keep-roaming-profile-storage-separate-from-redirected-folder-shares/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:16+00:00 - Modified: 2026-09-08T18:20:21+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should the storage location and user scope for roaming profiles be prepared? ## Potentially affected Use this review when deploying traditional roaming profiles to a defined client population. ## DSE recommendation Prepare a storage-and-policy map showing the profile share separately from any redirected-folder share. ## Article ## Source facts Roaming user profiles place profile data on a file share so users can receive operating-system and application settings on multiple computers. Microsoft’s deployment procedure creates a security group for the users or computers receiving the profile policies. It calls for a profile share separate from redirected-folder shares to avoid inadvertently caching the roaming-profile folder. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-roaming-user-profiles). ## Applicability Use this review when deploying traditional roaming profiles to a defined client population. Identify the client versions, user group, share owner, and existing Folder Redirection configuration. Review version-specific profile requirements before the deployment. ## DSE recommendation Prepare a storage-and-policy map showing the profile share separately from any redirected-folder share. Ask the desktop owner to approve the pilot users and application-settings tests. Verify the planned share permissions through the documented procedure and preserve the existing profile arrangement. Define how support will handle an incomplete first sign-in or an unexpected profile location. ## Verification Test a pilot user on the intended computers and record the profile path and application settings observed. Inspect whether the approved policy scope and share separation are in place. Include a user outside the pilot scope. Resolve unexpected caching, profile placement, or missing settings before extending the deployment to more users. ## Official references [Microsoft Learn: Deploy roaming user profiles](https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-roaming-user-profiles). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy roaming user profiles - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/deploy-roaming-user-profiles - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep roaming-profile storage separate from redirected-folder shares,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-055-keep-roaming-profile-storage-separate-from-redirected-folder-shares/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep security-related door and lock maintenance records for HIPAA scope > The HIPAA Security Rule addresses maintenance records for physical security components. Covered workflows should capture relevant door, lock, wall, and hardware changes. - Canonical URL: https://update.dsesecurity.com/updates/keep-security-related-door-and-lock-maintenance-records-for-hipaa-scope/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:48+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know The HIPAA Security Rule addresses maintenance records for physical security components. Covered workflows should capture relevant door, lock, wall, and hardware changes. ## Potentially affected HIPAA covered entities and business associates operating facilities where physical security components protect electronic protected health information. ## DSE recommendation Link security-related repair and modification records to the affected facility, component, access boundary, approval, test result, and retained compliance documentation. ## Article Bottom line: a lock repair can be both a facilities event and a security-control change. For organizations in scope, the record should establish what security component changed, why, who authorized it, and whether the protected boundary still works as intended. ## Source fact: the HIPAA rule addresses security-component maintenance records [45 CFR 164.310(a)(2)(iv) — Maintenance records](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.310#p-164.310%28a%29%282%29%28iv%29) is part of the facility-access-controls standard for covered entities and business associates. The maintenance-records implementation specification calls for documenting repairs and modifications to the physical components of a facility that are related to security, with examples including hardware, walls, doors, and locks. The regulation identifies that specification as addressable. Addressable does not mean irrelevant or automatically optional. The HIPAA Security Rule’s implementation framework requires the regulated organization to make and document the appropriate determination based on its circumstances. ## Source boundary and applicability The eCFR is an authoritative, continuously updated online version of the CFR, but it is not an official legal edition. This article is not legal advice or a finding that HIPAA applies to a facility, system, or work order. Scope, implementation decisions, documentation period, and safeguards depend on the entity’s risk analysis, policies, electronic protected health information, facility-access plan, and counsel or compliance interpretation. ## Applicability questions - Does the facility or component protect systems or areas containing electronic protected health information? - Which documented facility access control or risk-analysis decision depends on it? - Did the work change a door, lock, wall, hardware, keying, credential, alarm, or monitored state? - Was temporary access or a compensating control required during repair? - Where will the record be retained and linked to configuration and test evidence? ## DSE recommendation: add a security record to the maintenance workflow The following steps are DSE recommendations based on the cited source. Have the HIPAA security or compliance owner define which facilities and components are in scope. For each relevant repair or modification, record asset and location, protected boundary, condition, requested change, requester, authorizer, technicians, dates, parts, key or credential impact, temporary safeguard, final configuration, and post-work test. Avoid including protected health information in the ticket unless necessary and permitted. Reconcile facilities work orders with PACS configuration, key-control records, drawings, and incident logs. Review repeat repairs and emergency bypasses for a larger control weakness. Document the organization’s treatment of the addressable specification through the established HIPAA process. ## Verification and evidence Retain the applicability decision, policy, work order, before-and-after photos where authorized, parts and configuration record, temporary-control log, door and alarm tests, access review, exception approval, and closeout. Audit a sample from facilities dispatch through the compliance repository to confirm the record is complete and retrievable. ## Official references - [45 CFR 164.310(a)(2)(iv) — Maintenance records](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.310#p-164.310%28a%29%282%29%28iv%29) – Electronic Code of Federal Regulations ## Primary reference - Name: 45 CFR 164.310(a)(2)(iv) — Maintenance records - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.310#p-164.310%28a%29%282%29%28iv%29 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep security-related door and lock maintenance records for HIPAA scope,” DSE Security, https://update.dsesecurity.com/updates/keep-security-related-door-and-lock-maintenance-records-for-hipaa-scope/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep SMB over QUIC device admission separate from user authentication > What does an SMB over QUIC client certificate access list decide? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-156-keep-smb-over-quic-device-admission-separate-from-user-authentication/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:35+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What does an SMB over QUIC client certificate access list decide? ## Potentially affected Administrators configuring SMB over QUIC client access control on supported Windows servers. ## DSE recommendation Prepare a certificate-to-device inventory and label each required thumbprint with its algorithm. ## Article ## Source facts SMB over QUIC client access control permits device allowlists and blocklists without changing the authentication used for the SMB connection. The server validates the client certificate chain and its trust before checking the access list. Administrators can add a certificate hash to that server-maintained list. Microsoft distinguishes the SHA1 thumbprint used by certificate-mapping commands from the SHA256 thumbprint required for client access control. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/file-server/configure-smb-over-quic-client-access-control). ## Applicability Check the specific server release and feature prerequisites, existing QUIC configuration, client certificate, issuing authority, and administrative permissions. Review device admission and user/share authorization as separate controls. ## DSE recommendation Prepare a certificate-to-device inventory and label each required thumbprint with its algorithm. Have the PKI and file-service owners approve the allowed and blocked test devices. Preserve the existing mappings and access entries before changing admission policy. ## Verification Test an allowed device, a blocked device, and a device with an untrusted certificate chain. For the admitted device, separately verify the intended user’s share permissions. Record the certificate identity and observed rejection stage so a failed device check is not misreported as a user-password problem. ## Official references [Microsoft Learn: Configure SMB over QUIC client access control in Windows Server](https://learn.microsoft.com/en-us/windows-server/storage/file-server/configure-smb-over-quic-client-access-control). Source reviewed September 8, 2026. ## Primary reference - Name: Configure SMB over QUIC client access control in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/file-server/configure-smb-over-quic-client-access-control - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep SMB over QUIC device admission separate from user authentication,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-156-keep-smb-over-quic-device-admission-separate-from-user-authentication/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep storage aisles clear and stacked materials stable through daily operations > Use 29 CFR 1910.176 - Handling materials to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-storage-aisles-clear-and-stacked-materials-stable-through-daily-operations/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:17+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.176 - Handling materials to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.176 - Handling materials ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Keep storage aisles clear and stacked materials stable through daily operations. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.176 – Handling materials](https://www.ecfr.gov/current/title-29/section-1910.176) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, where mechanical handling equipment is used, sufficient safe clearances must be allowed for aisles, at loading docks, through doorways and wherever turns or passage must be made. The research record locates this support at 29 CFR 1910.176(a) (eCFR anchor p-1910.176(a)). - Under 29 CFR 1910, the rule requires that storage of material not create a hazard. The research record locates this support at 29 CFR 1910.176(b) (eCFR anchor p-1910.176(b)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths and the conditions the source actually describes. ## What the source does not establish Federal workplace rule; rack engineering, seismic restraint, fire code, commodity class, and powered-equipment operations require additional review. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.176(a) (eCFR anchor p-1910.176(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.176(b) (eCFR anchor p-1910.176(b)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from 29 CFR 1910.176(a) (eCFR anchor p-1910.176(a)); 29 CFR 1910.176(b) (eCFR anchor p-1910.176(b)) to the observed environment. Useful domain evidence includes facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [29 CFR 1910.176 – Handling materials](https://www.ecfr.gov/current/title-29/section-1910.176) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.176 - Handling materials - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.176 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep storage aisles clear and stacked materials stable through daily operations,” DSE Security, https://update.dsesecurity.com/updates/keep-storage-aisles-clear-and-stacked-materials-stable-through-daily-operations/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep system plans current with control status and named responsibilities > Use SP 800-18 Rev. 2, Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-system-plans-current-with-control-status-and-named-responsibilities/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:18:01+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use SP 800-18 Rev. 2, Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of SP 800-18 Rev. 2, Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Keep system plans current with control status and named responsibilities. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [SP 800-18 Rev. 2, Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems](https://csrc.nist.gov/pubs/sp/800/18/r2/final) from National Institute of Standards and Technology supports the following bounded statements: - NIST SP 800-18 Rev. 2 collectively calls the system security, privacy, and C-SCRM plans ‘system plans.’. The research record locates this support at Abstract. - NIST says those plans describe system purpose, control operational status, and responsibilities and expected behavior of people who manage, support, and access the system. The research record locates this support at Abstract. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives only where the source and recorded environment align. ## What the source does not establish A completed plan is not evidence that controls operate, dependencies are current, or responsible people can perform the documented actions during disruption. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Abstract, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Abstract, which observable configuration, record, or test can confirm applicability here? - Within essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, which versions, roles, and configuration states define the review population? - Could identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Abstract; Abstract. Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [SP 800-18 Rev. 2, Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems](https://csrc.nist.gov/pubs/sp/800/18/r2/final) — National Institute of Standards and Technology ## Primary reference - Name: SP 800-18 Rev. 2, Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/18/r2/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep system plans current with control status and named responsibilities,” DSE Security, https://update.dsesecurity.com/updates/keep-system-plans-current-with-control-status-and-named-responsibilities/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep the custom banned-password list small, local, and testable > Microsoft Entra custom banned passwords are intended for organization-specific terms, not for importing a large breached-password corpus or replacing layered authentication controls. - Canonical URL: https://update.dsesecurity.com/updates/entra-custom-banned-password-list-governance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:28+00:00 - Modified: 2026-08-25T21:36:18+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Microsoft Entra custom banned passwords are intended for organization-specific terms, not for importing a large breached-password corpus or replacing layered authentication controls. ## Potentially affected Microsoft Entra tenants considering a custom banned-password list for cloud users or a broader password-protection deployment. ## DSE recommendation Use a short owned list of organization-specific terms, test realistic variants and user impact, and combine it with stronger authentication and account-recovery controls. ## Article Bottom line: Microsoft Entra provides a global banned-password list and an optional custom list for locally meaningful terms such as brand names, products, locations, and abbreviations. Microsoft says the custom list is not designed to hold a large list of passwords. Build a focused control that can be explained, tested, and maintained. ## Source fact: what Microsoft documents Microsoft’s [custom password-protection tutorial](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-configure-custom-password-protection) explains that the custom list works alongside Microsoft’s global banned-password list. A password-change or reset request is rejected when the candidate password matches the evaluation performed against these lists. The documentation describes concrete boundaries: the custom list supports up to 1,000 terms, treats entries case-insensitively, considers common character substitutions, and accepts terms from four through sixteen characters. Microsoft explicitly says it is not designed for blocking large password lists. Updates can take time to apply. The tutorial also lists tenant, role, and license prerequisites and notes that its web reset test assumes self-service password reset is configured. ## What the source does not establish The list does not detect every compromised, reused, predictable, or contextually weak password. It does not evaluate passwords until a change or reset operation occurs, and it does not force existing users to choose a new password merely because a term was added. It is not a substitute for MFA, phishing-resistant authentication, monitoring, recovery design, or on-premises deployment components where those are needed. ## Applicability questions - Are the users cloud-only, synchronized, or on-premises AD DS users, and where is the password set or changed? - Which organization-specific words are genuinely predictable to an attacker? - Could a proposed term create excessive false rejections because it is short, common, or part of ordinary language? - Are the required licenses, administrator role, SSPR configuration, and any on-premises agents present? - Who will review the list after rebranding, mergers, new products, or location changes? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Start with a small list derived from public organization names, common abbreviations, prominent products, locations, and campaigns. Do not paste a breached-password dump into this feature. - Assign an owner and record the rationale for every term. Review for duplication, unintended language impact, and predictable variants. - Test password changes and resets with allowed and blocked examples across the actual cloud and hybrid paths. - Communicate useful guidance without publishing the complete control list. Give helpdesk staff a safe troubleshooting and escalation process. - Review the list at least after material naming changes and alongside the wider authentication strategy. ## Verification and evidence - Preserve the approved term list, rationale, owner, change date, and policy configuration. - Record successful tests for exact terms, case changes, common substitutions, permitted passwords, and applicable on-premises paths. - Monitor password-change and reset support issues after rollout without collecting user passwords. - Confirm the global and custom protections are supplemented by the intended MFA and recovery controls. ## Official references - [Configure custom Microsoft Entra password protection lists](https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-configure-custom-password-protection) — Microsoft ## Primary reference - Name: Configure custom Microsoft Entra password protection lists - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/authentication/tutorial-configure-custom-password-protection - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep the custom banned-password list small, local, and testable,” DSE Security, https://update.dsesecurity.com/updates/entra-custom-banned-password-list-governance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep the records-emergency plan usable without Internet access > Preserve offsite printed contacts, procedures, priorities, and supply information so records response can start while systems are unavailable. - Canonical URL: https://update.dsesecurity.com/updates/keep-records-emergency-plan-usable-offline/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:26+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know Preserve offsite printed contacts, procedures, priorities, and supply information so records response can start while systems are unavailable. ## Potentially affected Organizations responsible for paper, photographic, audiovisual, or other physical records vulnerable to water, fire, contamination, or facility loss ## DSE recommendation Maintain controlled offline copies of the records-emergency plan and exercise activation without corporate Internet, email, or file shares. ## Article A response plan stored only on the network is unavailable in exactly the kind of facility, power, identity, or cyber disruption that can threaten records. The activation package needs a controlled offline form that responders can find and use. ## Source fact: [The U.S. National Archives and Records Administration’s Records Emergency Preparedness and Response Toolkit](https://www.archives.gov/preservation/records-emergency/toolkit.html) advises organizations to plan for loss of Internet access and keep printed emergency information offsite. NARA’s planning materials identify practical content such as notification procedures, response-team and staff contacts, inventories of supplies and equipment, and special procedures or access information needed during an emergency. The toolkit covers preparedness, response, and recovery for records emergencies. Its offline recommendation recognizes that contact and procedural dependencies may fail together. A printed plan supports activation; it does not preserve the records themselves, make a damaged building safe to enter, or replace emergency services and qualified recovery specialists. ## Boundary NARA guidance must be adapted to the organization’s record formats, hazards, insurance, contracts, safety program, and legal duties. Printed material becomes stale and can disclose phone numbers, access information, floor plans, or vendor details. The offline package should contain what responders need without including credentials, alarm codes, sensitive personal data, or unsafe technical instructions. Life safety and authority having jurisdiction take precedence over collection recovery. ## Applicability questions - Which collections or record groups receive first attention, and who approved that priority? - Who can authorize entry, spending, vendors, movement, freezing, disposal, or disclosure? - Where are shutoffs, supplies, protective equipment, elevators, loading points, and vulnerable storage areas? - Which specialists and recovery vendors are reachable outside normal systems and hours? - How will every controlled offline copy be updated, recalled, or destroyed after revision? ## DSE recommendation: Create a compact activation packet containing emergency numbers, call tree, roles and alternates, collection priorities, floor or storage orientation, safety and authority boundaries, approved vendors, insurance contact, essential supplies, and decision checklists. Reference detailed technical procedures rather than asking untrained responders to improvise conservation treatment. Exclude passwords and other access secrets. Issue numbered copies to at least two appropriate offsite custodians and place another in a protected alternate location. Set an owner and scheduled review, plus event-driven updates for staffing, vendors, buildings, storage, and priorities. Recall old copies when possible. Exercise after hours with corporate connectivity and identity unavailable: locate the packet, contact the team, validate a vendor, identify priority records, and make a safe first-hour decision. ## Verification and evidence Keep the master version, distribution register, custodian acknowledgments, update and recall record, contact test results, exercise timeline, and corrective actions. During review, call a representative sample of numbers and confirm authority rather than only comparing names to an org chart. Evidence should demonstrate that responders can begin safely offline while a later step reconnects them to authoritative current information. ## Official references - [NARA Records Emergency Preparedness and Response Toolkit](https://www.archives.gov/preservation/records-emergency/toolkit.html) ## Primary reference - Name: Records Emergency Preparedness and Response Toolkit - Authority: www.archives.gov - URL: https://www.archives.gov/preservation/records-emergency/toolkit.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep the records-emergency plan usable without Internet access,” DSE Security, https://update.dsesecurity.com/updates/keep-records-emergency-plan-usable-offline/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep tornado safe rooms available, signed, supplied, and occupancy-ready > A certified safe room can fail operationally when it is locked, used for storage, missing from the warning plan, over capacity, poorly signed, inaccessible, or not maintained as its approved design requires. - Canonical URL: https://update.dsesecurity.com/updates/keep-tornado-safe-rooms-available-signed-occupancy-ready/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:31:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know A certified safe room can fail operationally when it is locked, used for storage, missing from the warning plan, over capacity, poorly signed, inaccessible, or not maintained as its approved design requires. ## Potentially affected Community and workplace tornado safe rooms, storm shelters, refuge routes, warning and activation procedures, doors and hardware, signage, emergency supplies, accessibility, capacity, inspections, drills, and facility alterations. ## DSE recommendation Preserve the approved safe-room design and documentation, assign an operations owner, keep the room and route immediately usable, define activation and accountability, inspect critical features, control alterations, and drill arrival before warning time expires. ## Article ## Source facts: a safe room has operational requirements as well as structural ones [FEMA P-361, Safe Rooms for Tornadoes and Hurricanes, Fourth Edition](https://www.fema.gov/sites/default/files/documents/fema_rsl_fema-p-361-safe-rooms-for-tornadoes-and-hurricanes_042025.pdf) provides planning, design, construction, inspection, operation, and maintenance guidance for residential and community safe rooms. FEMA distinguishes a storm shelter that meets ICC 500 from a FEMA safe room, which also meets FEMA’s more stringent criteria intended to provide near-absolute protection from the design event. “Near-absolute” is not an unlimited guarantee against every possible event. The 2025 edition uses ICC 500-2023 as a companion reference. It addresses hazard assessment, occupant capacity, travel time, accessibility, signage, communications, emergency supplies, operations and maintenance planning, and protection of the envelope and its openings. A safe room must remain consistent with its approved design; doors, hardware, penetrations, ventilation, and surrounding construction are not ordinary components that can be changed without review. FEMA criteria apply to FEMA-funded safe rooms as described in the publication. The adopted code, ICC 500 edition, grant conditions, approved construction documents, authority having jurisdiction, and qualified design professionals govern a specific facility. An interior room called a “tornado room” is not necessarily a compliant storm shelter or FEMA safe room. ## DSE recommendation: operate the room so protection is available on warning Start with the record. Identify the room’s exact classification, design criteria, approved occupant capacity, intended population, responsible owner, inspection requirements, and as-built documents. If that evidence is missing, engage the design professional and authority having jurisdiction; do not infer performance from thick walls or a label. - Protect the route and arrival time. Map travel from every occupied area, including public, warehouse, outdoor, and accessible locations. Account for stairs, secured doors, turnstiles, elevators, shift staffing, visitors, children, and people who need assistance. The activation threshold must leave enough time to warn, stop work, and reach shelter before hazardous winds arrive. - Keep access immediate. Do not allow a locked door, stored furniture, pallet, floor mat, temporary partition, or access-control schedule to delay entry. If security controls protect the room in ordinary conditions, document their emergency release and a reliable manual alternative. Keep the door’s full closing and latching path clear. - Control capacity. Post the approved capacity and define overflow destinations before an event. Consider employees, contractors, visitors, occupants with mobility devices, service animals, and expected public use. Never solve overcrowding by blocking required door operation or placing people in unapproved adjoining space. - Inspect protective features. Use the approved operations and maintenance plan to check doors, frames, hinges, latches, closers, labels, seals, ventilation openings, protective covers, penetrations, signs, lighting, communications, drainage, moisture, corrosion, and damage. Route deficiencies to qualified evaluation and record repair and retest. - Prepare occupied operations. Maintain approved first-aid and emergency supplies, accessible communication, occupant accountability, sanitation arrangements where needed, and a way to receive authoritative weather information. Define who decides entry, who checks the room, who brings visitor records, and who authorizes exit. - Control every alteration. Prevent unreviewed cable, pipe, duct, access reader, camera, shelf, fastener, door contact, or finish work from penetrating or loading the protective assembly. Require the original design criteria and qualified review in the work order. Run timed, announced drills during representative shifts. Measure warning receipt, decision time, travel, door closure, accountability, communications, and capacity without creating panic or exposing occupants to weather. Include an unavailable coordinator, a person needing assistance, a blocked preferred route, visitors, and loss of normal power. After each drill, warning, severe-weather event, impact, leak, or nearby construction activity, inspect and document the room before returning it to ordinary readiness. The operating test is simple: the correct people can recognize the warning, reach the protected space, secure it as designed, remain there safely, and leave only when authorized. ## Official references - Federal Emergency Management Agency, [FEMA P-361, Safe Rooms for Tornadoes and Hurricanes, Fourth Edition](https://www.fema.gov/sites/default/files/documents/fema_rsl_fema-p-361-safe-rooms-for-tornadoes-and-hurricanes_042025.pdf), April 2025. - FEMA, [Safe Rooms for Tornadoes and Hurricanes](https://www.fema.gov/emergency-managers/risk-management/building-science/safe-rooms), Building Science resource center. ## Primary reference - Name: FEMA P-361: Safe Rooms for Tornadoes and Hurricanes, Fourth Edition - Authority: Federal Emergency Management Agency - URL: https://www.fema.gov/sites/default/files/documents/fema_rsl_fema-p-361-safe-rooms-for-tornadoes-and-hurricanes_042025.pdf - Source publication date: 2025-04-01 ## Citation and use Preferred citation: “Keep tornado safe rooms available, signed, supplied, and occupancy-ready,” DSE Security, https://update.dsesecurity.com/updates/keep-tornado-safe-rooms-available-signed-occupancy-ready/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep two emergency Microsoft Entra accounts ready before the tenant needs them > Emergency access accounts provide a recovery path when normal administrators cannot sign in or activate a role. They must be independent, strongly protected, monitored, and tested without becoming everyday admin accounts. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:53+00:00 - Modified: 2026-07-19T21:27:53+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Emergency access accounts provide a recovery path when normal administrators cannot sign in or activate a role. They must be independent, strongly protected, monitored, and tested without becoming everyday admin accounts. ## Potentially affected Microsoft Entra tenants, especially organizations that use federation, Conditional Access, Privileged Identity Management, multifactor authentication, or a small administrator team. ## DSE recommendation Maintain at least two cloud-only emergency accounts, protect them with independent phishing-resistant credentials, exclude them from blocking access policies, alert on use, and validate them every 90 days. ## Article ## Source fact: what Microsoft documents Microsoft recommends maintaining two or more emergency access accounts for situations in which ordinary administrators cannot sign in or activate a required role. Examples include an unavailable federated identity provider, inaccessible multifactor devices, an approval chain with no available approver, or an accidental tenant-wide lockout. These accounts are highly privileged and are intended only for planned validation or a real emergency. The current Microsoft guidance says the accounts should be cloud-only, use the tenant’s .onmicrosoft.com domain, and have a permanent active Global Administrator assignment rather than an eligible assignment in Privileged Identity Management. Microsoft recommends phishing-resistant authentication with passkeys (FIDO2) or certificate-based authentication, credentials that do not share the same dependency as normal administrators, and designated secure workstations. Accounts should be excluded from Conditional Access policies that can block or restrict sign-in. Report-only policies do not block access and do not require that exclusion. Microsoft also recommends alerting on every sign-in and audit event, keeping credentials in separate secure locations, reviewing every use, and validating account functionality at least every 90 days. A validation should prove that the account can sign in and perform an administrative task and that monitoring generates the expected notification. ## Applicability and cautions These recommendations apply to Microsoft Entra tenants, but the exact credential, alerting, workstation, storage, and approval design depends on the organization. Azure Monitor, Microsoft Sentinel, secure hardware, certificate infrastructure, or other components can introduce separate licensing and operational requirements. Emergency accounts must not be connected to employee-supplied devices or used as convenient secondary administrator identities. ## DSE recommendation: production-safe operational steps - Inventory existing emergency accounts, their object IDs, assigned roles, authentication methods, owners, storage locations, and policy exclusions. - Create at least two cloud-only accounts if the tenant does not already have them. Use non-personal naming that does not expose a password or recovery detail. - Register independent phishing-resistant credentials and store the credentials in separate, access-controlled locations available to more than one authorized custodian. - Confirm permanent active Global Administrator assignment and exclude the accounts from every policy that could make them unusable during the failure scenario they address. - Configure alerts for sign-in and audit activity, document authorized-use criteria, and require a post-use review. - Run a witnessed drill at least every 90 days and after material administrator, authentication, federation, or Conditional Access changes. DSE recommends recording the date, tester, observed alerts, administrative action, and any corrective work for each drill. Stop the test after the minimum administrative validation; do not use an emergency account for routine maintenance. If a test fails, treat the recovery design as unavailable until the cause is corrected and independently retested. ## Official reference [Manage emergency access accounts in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) — account design, authentication, Conditional Access, monitoring, and validation guidance. ## Primary reference - Name: Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access - Source publication date: 2026-06-05 ## Citation and use Preferred citation: “Keep two emergency Microsoft Entra accounts ready before the tenant needs them,” DSE Security, https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep VM configuration upgrades separate from Hyper-V host upgrades > When should a Hyper-V VM configuration version be advanced? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-199-keep-vm-configuration-upgrades-separate-from-hyper-v-host-upgrades/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:52+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know When should a Hyper-V VM configuration version be advanced? ## Potentially affected Administrators upgrading Hyper-V hosts and virtual-machine configuration versions. ## DSE recommendation For each VM, write down the feature that requires an upgrade and the older-host return path that may still be needed. ## Article ## Source facts Microsoft explains that moving or importing a VM onto a newer Hyper-V host does not automatically upgrade its configuration version. Keeping the older version preserves the documented ability to move the VM back to an older host, while some newer features require an explicit upgrade. The source provides Get-VMHostSupportedVersion to inspect supported versions. An upgraded VM configuration version cannot be downgraded. Its upgrade procedure starts by shutting down the virtual machine. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/Upgrade-virtual-machine-version-in-Hyper-V-on-Windows-or-Windows-Server). ## Applicability Inventory the current VM configuration version and every host that might need to run it, including recovery destinations. Check those hosts against the source support table. Make the configuration-version decision separately from completing the host operating-system upgrade. ## DSE recommendation For each VM, write down the feature that requires an upgrade and the older-host return path that may still be needed. Have the virtualization and workload owners agree when that fallback requirement ends. Schedule the required shutdown and preserve a recoverable pre-change record. Do not advance every VM automatically just because a newer host offers the option. ## Verification After the approved upgrade, verify the reported configuration version and the specific feature that motivated it. Validate startup and the representative application transaction. Compare all intended placement destinations with the accepted compatibility plan, and document any destination that is no longer part of that plan. ## Official references [Microsoft Learn: Upgrade virtual machine version in Hyper-V on Windows or Windows Server](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/Upgrade-virtual-machine-version-in-Hyper-V-on-Windows-or-Windows-Server). Source reviewed September 8, 2026. ## Primary reference - Name: Upgrade virtual machine version in Hyper-V on Windows or Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/Upgrade-virtual-machine-version-in-Hyper-V-on-Windows-or-Windows-Server - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep VM configuration upgrades separate from Hyper-V host upgrades,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-199-keep-vm-configuration-upgrades-separate-from-hyper-v-host-upgrades/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep VPN identity enrichment on sensor v2 and validate RADIUS accounting data > Use Defender for Identity VPN integration in Microsoft Defender to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-vpn-identity-enrichment-on-sensor-v2-and-validate-radius-data/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:44+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Defender for Identity VPN integration in Microsoft Defender to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Defender for Identity VPN integration in Microsoft Defender ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Keep VPN identity enrichment on sensor v2 and validate RADIUS accounting data. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Defender for Identity VPN integration in Microsoft Defender](https://learn.microsoft.com/en-us/defender-for-identity/vpn-integration) from Microsoft supports the following bounded statements: - Defender for Identity VPN integration is supported only by sensor v2.x. The research record locates this support at Opening applicability statement. - The integration listens to forwarded RADIUS accounting events and can add connection IP address and location context plus an abnormal-VPN-connection detection. The research record locates this support at VPN data and investigation description. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs and the conditions the source actually describes. ## What the source does not establish The source says the integration is unsupported in FIPS environments; RADIUS location is context, not proof of a user’s physical presence. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening applicability statement, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at VPN data and investigation description, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of identity sensors, connected directories, cloud security services, event flows, roles, alerts, and investigation handoffs, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, time, certificates, cloud identity, endpoint telemetry, network paths, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from Opening applicability statement; VPN data and investigation description to the observed environment. Useful domain evidence includes integration configuration, connectivity tests, event timestamps, alert correlation, role assignments, and case records; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Defender for Identity VPN integration in Microsoft Defender](https://learn.microsoft.com/en-us/defender-for-identity/vpn-integration) — Microsoft ## Primary reference - Name: Defender for Identity VPN integration in Microsoft Defender - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/vpn-integration - Source publication date: 2026-08-07 ## Citation and use Preferred citation: “Keep VPN identity enrichment on sensor v2 and validate RADIUS accounting data,” DSE Security, https://update.dsesecurity.com/updates/keep-vpn-identity-enrichment-on-sensor-v2-and-validate-radius-data/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Keep Windows geo-DNS policy data consistent across primary and secondary servers > Use Use DNS Policy for Geo-Location Based Traffic Management with Primary-Secondary Deployments to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/keep-windows-geo-dns-policy-data-consistent-across-primary-and-secondary-servers/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:28+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Use DNS Policy for Geo-Location Based Traffic Management with Primary-Secondary Deployments to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Use DNS Policy for Geo-Location Based Traffic Management with Primary-Secondary Deployments ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Keep Windows geo-DNS policy data consistent across primary and secondary servers. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Use DNS Policy for Geo-Location Based Traffic Management with Primary-Secondary Deployments](https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/primary-secondary-geo-location) from Microsoft supports the following bounded statements: - Microsoft documents geo-location DNS Policy in a primary-secondary DNS deployment. The research record locates this support at Article introduction. - Secondary servers receive zone changes through AXFR and IXFR in the documented primary-secondary model. The research record locates this support at Section ‘How the DNS Primary-Secondary System Works’. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish Ordinary zone synchronization does not by itself prove consistent zone-scope and policy behavior at every secondary server. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Article introduction, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section ‘How the DNS Primary-Secondary System Works’, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations Article introduction; Section ‘How the DNS Primary-Secondary System Works’ adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Use DNS Policy for Geo-Location Based Traffic Management with Primary-Secondary Deployments](https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/primary-secondary-geo-location) — Microsoft ## Primary reference - Name: Use DNS Policy for Geo-Location Based Traffic Management with Primary-Secondary Deployments - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/primary-secondary-geo-location - Source publication date: 2021-07-29 ## Citation and use Preferred citation: “Keep Windows geo-DNS policy data consistent across primary and secondary servers,” DSE Security, https://update.dsesecurity.com/updates/keep-windows-geo-dns-policy-data-consistent-across-primary-and-secondary-servers/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Key Defender for Identity SIEM automation to externalId values > Use Microsoft Defender for Identity SIEM log reference to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/key-defender-identity-siem-automation-to-externalid/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:16+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Microsoft Defender for Identity SIEM log reference to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft Defender for Identity SIEM log reference ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Key Defender for Identity SIEM automation to externalId values. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft Defender for Identity SIEM log reference](https://learn.microsoft.com/en-us/defender-for-identity/cef-format-sa) from Microsoft supports the following bounded statements: - Defender for Identity forwards CEF security-alert fields including start, suser, shost, outcome, msg, cnt, app, and externalId to a SIEM. The research record locates this support at Sample Defender for Identity security alerts in CEF format > forwarded fields table. - Microsoft recommends identifying alert types with externalId in automation because alert names can change while each alert type’s externalId is permanent. The research record locates this support at Sample Defender for Identity security alerts in CEF format > note following the forwarded fields table. The source support ends with the statements listed above. Use them to examine identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows in the applicable environment, not to imply a wider guarantee. ## What the source does not establish CEF field definitions do not prove event delivery, parser compatibility, retention, or automation correctness; test the selected SIEM path and failure handling. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Sample Defender for Identity security alerts in CEF format > forwarded fields table, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sample Defender for Identity security alerts in CEF format > note following the forwarded fields table, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows are in and out of scope? - Which condition in Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to Sample Defender for Identity security alerts in CEF format > forwarded fields table; Sample Defender for Identity security alerts in CEF format > note following the forwarded fields table and to observable material such as alert records, investigation timelines, analyst actions, tuning or exclusion approvals, remediation results, and case closure. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Microsoft Defender for Identity SIEM log reference](https://learn.microsoft.com/en-us/defender-for-identity/cef-format-sa) — Microsoft ## Primary reference - Name: Microsoft Defender for Identity SIEM log reference - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/cef-format-sa - Source publication date: 2024-09-22 ## Citation and use Preferred citation: “Key Defender for Identity SIEM automation to externalId values,” DSE Security, https://update.dsesecurity.com/updates/key-defender-identity-siem-automation-to-externalid/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Label collaboration containers without assuming the files inherit the label > Purview sensitivity labels for Teams, Microsoft 365 groups, and SharePoint sites can enforce container settings, but a container label does not automatically label the documents stored inside. - Canonical URL: https://update.dsesecurity.com/updates/purview-container-labels-file-boundary/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:15+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Explainer - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Purview sensitivity labels for Teams, Microsoft 365 groups, and SharePoint sites can enforce container settings, but a container label does not automatically label the documents stored inside. ## Potentially affected Organizations using Microsoft Purview sensitivity labels for Teams, Microsoft 365 groups, SharePoint sites, or other supported collaboration containers. ## DSE recommendation Design container and item labeling as related but distinct controls, test privacy and sharing settings, and verify both container configuration and representative file labels. ## Article Bottom line: Microsoft Purview sensitivity labels can apply settings to collaboration containers such as Teams, Microsoft 365 groups, and SharePoint sites. Microsoft explicitly distinguishes the container from the items stored inside it. A labeled Team or site does not, by that fact alone, label or encrypt every file within it. ## Source fact: what Microsoft documents Microsoft’s [container-label documentation](https://learn.microsoft.com/en-us/purview/sensitivity-labels-teams-groups-sites) explains that sensitivity labels with the Groups & sites scope can control supported settings for Microsoft 365 groups, Teams, SharePoint sites, and other listed containers. Depending on current capabilities and configuration, settings can include privacy, external-user access, external sharing, unmanaged-device access, authentication context, and related collaboration controls. When a label is applied through a supported connected workload, Microsoft coordinates the label on the Microsoft 365 group and connected SharePoint site. The source states that content in these containers does not inherit the container’s sensitivity label. Item-level labeling for files and emails is a separate scope and mechanism. The page documents prerequisites, synchronization, limitations, and effects of renaming or deleting labels, including possible creation failures if a referenced label is removed incorrectly. ## What the source does not establish A container label does not prove that membership is appropriate, existing external sharing is remediated, or every file has item-level protection. It does not classify data automatically unless separate supported labeling features do so. A displayed label name is not evidence that each associated setting applied successfully to every connected service. Licensing and supported settings vary. ## Applicability questions - Is the requirement to control the workspace, label files, encrypt items, or all three? - Which Teams, groups, SharePoint sites, private or shared channels, and other supported containers are in scope? - What privacy, guest, external-sharing, unmanaged-device, and authentication-context settings should each label carry? - How will unlabeled, preexisting, orphaned, or differently labeled files be handled? - What automation creates containers, and can it select or preserve sensitivity labels correctly? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Define a label taxonomy with separate requirements for containers and items. Do not overload one label name with ambiguous promises. - Pilot labels on test groups, Teams, sites, private channels, and representative files. Verify connected-service synchronization and settings. - Inventory existing sharing and membership before applying a restrictive label; plan remediation rather than assuming retroactive cleanup. - Protect label rename, deletion, publication, and policy-order changes through formal change control. - Report container labels and item-label coverage separately so stakeholders can see the remaining gap. ## Verification and evidence - Preserve label definitions, scopes, published policies, settings, order, and approvals. - Capture the label and effective sharing or access configuration on each test container and connected site. - Inspect representative files to show whether item-level labels and encryption are present or absent. - Test new container creation, relabeling, external access, and label removal in a nonproduction scope. ## Official references - [Use sensitivity labels to protect collaborative workspaces (groups and sites)](https://learn.microsoft.com/en-us/purview/sensitivity-labels-teams-groups-sites) — Microsoft ## Primary reference - Name: Use sensitivity labels to protect collaborative workspaces (groups and sites) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/purview/sensitivity-labels-teams-groups-sites - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Label collaboration containers without assuming the files inherit the label,” DSE Security, https://update.dsesecurity.com/updates/purview-container-labels-file-boundary/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Layer access, monitoring, and response measures at Certain Dangerous Cargo facilities > Use 33 CFR 105.295 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/layer-access-monitoring-and-response-measures-at-certain-dangerous-cargo-facilities/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:00+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.295 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.295 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Layer access, monitoring, and response measures at Certain Dangerous Cargo facilities. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.295 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.295) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, a Certain Dangerous Cargo facility must always escort visitors and other nonemployees who lack access identification. The research record locates this support at 33 CFR 105.295(a)(1), read with 33 CFR 105.295(a) (eCFR anchor p-105.295(a)(1)). - Under 33 CFR 105, at MARSEC Level 2 a Certain Dangerous Cargo facility may release cargo only with the FSO or the FSO’s representative present. The research record locates this support at 33 CFR 105.295(b)(1), read with 33 CFR 105.295(b) (eCFR anchor p-105.295(b)(1)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths only where the source and recorded environment align. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.295(a)(1), read with 33 CFR 105.295(a) (eCFR anchor p-105.295(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.295(b)(1), read with 33 CFR 105.295(b) (eCFR anchor p-105.295(b)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from 33 CFR 105.295(a)(1), read with 33 CFR 105.295(a) (eCFR anchor p-105.295(a)(1)); 33 CFR 105.295(b)(1), read with 33 CFR 105.295(b) (eCFR anchor p-105.295(b)(1)) through asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [33 CFR 105.295 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.295) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.295 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.295 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Layer access, monitoring, and response measures at Certain Dangerous Cargo facilities,” DSE Security, https://update.dsesecurity.com/updates/layer-access-monitoring-and-response-measures-at-certain-dangerous-cargo-facilities/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Limit device redirection when using Hyper-V Enhanced Session Mode > Which local devices should be shared with a Windows VM through VMConnect? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-221-limit-device-redirection-when-using-hyper-v-enhanced-session-mode/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:30+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Which local devices should be shared with a Windows VM through VMConnect? ## Potentially affected Administrators using Hyper-V Enhanced Session Mode with Windows guest VMs. ## DSE recommendation Define a minimal redirection profile for each administrative use case. ## Article ## Source facts Microsoft documents Enhanced Session Mode as an RDP-based VMConnect connection available for Windows VMs. It enables sharing capabilities such as clipboard, printers, audio, USB devices, and data disks. The documented guest configuration requires Remote Desktop to be enabled. The connection settings let the operator choose devices to share. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/enhanced-session-mode). ## Applicability Identify the session mode, guest purpose, and exact local resources required for the task. Review the difference between viewing the guest and redirecting a device into it. Keep device sharing separate from assigning a physical GPU through DDA. ## DSE recommendation Define a minimal redirection profile for each administrative use case. Ask the data owner to approve access to a local drive or clipboard when the guest is outside the same trust scope. Open the connection settings before the session and verify the selections rather than accepting an accumulated profile. Use a disposable test file for any file-transfer exercise. ## Verification Confirm the displayed session mode and inspect which resources actually appear inside the guest. Test the approved device and check that an excluded drive or printer is unavailable through redirection. Record the profile used and remove temporary sharing after the task. Investigate unexpected resources before reusing the profile elsewhere. ## Official references [Microsoft Learn: Share devices with Hyper-V Windows virtual machines](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/enhanced-session-mode). Source reviewed September 8, 2026. ## Primary reference - Name: Share devices with Hyper-V Windows virtual machines - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/enhanced-session-mode - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Limit device redirection when using Hyper-V Enhanced Session Mode,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-221-limit-device-redirection-when-using-hyper-v-enhanced-session-mode/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Limit newly hired employees' secure-area access before TWIC issuance > Use 33 CFR 105.257 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/limit-newly-hired-employees-secure-area-access-before-twic-issuance/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:09+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.257 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.257 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Limit newly hired employees’ secure-area access before TWIC issuance. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.257 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.257) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, newly-hired facility employees may be granted entry to secure areas of the facility for up to 30 consecutive calendar days prior to receiving their TWIC provided all of the requirements in paragraph (b) of this section are met, and provided that the new hire is accompanied by an individual with a TWIC while within the secure areas of the facility. The research record locates this support at 33 CFR 105.257(a) (eCFR anchor p-105.257(a)). - Under 33 CFR 105, newly-hired facility employees may be granted the access provided for in paragraph (a) of this section if: the new hire has applied for a TWIC in accordance with 49 CFR part 1572 by completing the full enrollment process, paying the user fee, and is not currently engaged in a waiver or appeal process. The research record locates this support at 33 CFR 105.257(b)(1), read with 33 CFR 105.257(b) (eCFR anchor p-105.257(b)(1)). The source support ends with the statements listed above. Use them to examine credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.257(a) (eCFR anchor p-105.257(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.257(b)(1), read with 33 CFR 105.257(b) (eCFR anchor p-105.257(b)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from 33 CFR 105.257(a) (eCFR anchor p-105.257(a)); 33 CFR 105.257(b)(1), read with 33 CFR 105.257(b) (eCFR anchor p-105.257(b)(1)) to the observed environment. Useful domain evidence includes approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [33 CFR 105.257 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.257) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.257 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.257 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Limit newly hired employees' secure-area access before TWIC issuance,” DSE Security, https://update.dsesecurity.com/updates/limit-newly-hired-employees-secure-area-access-before-twic-issuance/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Limit unescorted SIDA access to trained and authorized individuals > Use 49 CFR 1542.205 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/limit-unescorted-sida-access-to-trained-and-authorized-individuals/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:32+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.205 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.205 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Limit unescorted SIDA access to trained and authorized individuals. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.205 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.205) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, each airport operator required to establish a SIDA must establish and carry out measures to prevent the unauthorized presence and movement of individuals in the SIDA and must do the following: train each individual before granting unescorted access to the SIDA, as required in section 1542.213(b). The research record locates this support at 49 CFR 1542.205(b)(3), read with 49 CFR 1542.205(b) (eCFR anchor p-1542.205(b)(3)). - Under 49 CFR 1542, each airport operator required to establish a SIDA must establish and carry out measures to prevent the unauthorized presence and movement of individuals in the SIDA and must do the following: subject each individual to a criminal history records check as described in section 1542.209 before authorizing unescorted access to the SIDA. The research record locates this support at 49 CFR 1542.205(b)(2), read with 49 CFR 1542.205(b) (eCFR anchor p-1542.205(b)(2)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces only where the source and recorded environment align. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 49 CFR 1542.205(b)(3), read with 49 CFR 1542.205(b) (eCFR anchor p-1542.205(b)(3)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.205(b)(2), read with 49 CFR 1542.205(b) (eCFR anchor p-1542.205(b)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from 49 CFR 1542.205(b)(3), read with 49 CFR 1542.205(b) (eCFR anchor p-1542.205(b)(3)); 49 CFR 1542.205(b)(2), read with 49 CFR 1542.205(b) (eCFR anchor p-1542.205(b)(2)) through approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [49 CFR 1542.205 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.205) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.205 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.205 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Limit unescorted SIDA access to trained and authorized individuals,” DSE Security, https://update.dsesecurity.com/updates/limit-unescorted-sida-access-to-trained-and-authorized-individuals/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Limit Zero Trust DNS pilots to licensed Windows 11 Enterprise or Education devices > Use Zero Trust DNS to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/limit-zero-trust-dns-pilots-licensed-windows-11-enterprise-education/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:47+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Use Zero Trust DNS to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Zero Trust DNS ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Limit Zero Trust DNS pilots to licensed Windows 11 Enterprise or Education devices. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Zero Trust DNS](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/zero-trust-dns/) from Microsoft supports the following bounded statements: - Zero Trust DNS uses a deny-by-default outbound model; traffic is allowed when its destination came from the trusted resolver or an administrator placed it on the approved list. The research record locates this support at Overview. - Zero Trust DNS is supported on Windows 11 Enterprise and Education, not Home or Pro, with entitlements from Windows Enterprise E3 or E5 and Windows Education A3 or A5. The research record locates this support at Windows edition and licensing requirements > edition and entitlement tables. Only the traced statements above are asserted as source facts. Apply the review to Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows after confirming that the source and deployed context match. ## What the source does not establish The page applies only to Windows 11 with the listed edition and license; inventory literal-IP, bootstrap, VPN, discovery, and emergency paths before a deny-by-default pilot. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Windows edition and licensing requirements > edition and entitlement tables, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Overview; Windows edition and licensing requirements > edition and entitlement tables through policy and feature state, security events, test detections, administrative assignments, exception approvals, and response tickets. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Zero Trust DNS](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/zero-trust-dns/) — Microsoft ## Primary reference - Name: Zero Trust DNS - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/zero-trust-dns/ - Source publication date: 2025-10-30 ## Citation and use Preferred citation: “Limit Zero Trust DNS pilots to licensed Windows 11 Enterprise or Education devices,” DSE Security, https://update.dsesecurity.com/updates/limit-zero-trust-dns-pilots-licensed-windows-11-enterprise-education/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Link fragmented user accounts only with evidence of common identity > Use Manage related identities and accounts in Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/link-fragmented-user-accounts-with-evidence-of-common-identity/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:52+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Manage related identities and accounts in Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Manage related identities and accounts in Microsoft Defender for Identity ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Link fragmented user accounts only with evidence of common identity. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Manage related identities and accounts in Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/manage-related-identities-accounts) from Microsoft supports the following bounded statements: - One person can have personal, privileged, legacy, cloud, or orphaned accounts across Active Directory, Entra ID, and non-Microsoft identity providers. The research record locates this support at Opening fragmentation overview. - Microsoft supports manually linking or unlinking related accounts to address fragmented identity views. The research record locates this support at Manual correlation overview. Keep the evidence boundary at these traced claims. They support a review of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish A manual link is an analyst assertion, not authoritative proof that two accounts have the same owner; preserve review and rollback evidence. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening fragmentation overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Manual correlation overview, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to Opening fragmentation overview; Manual correlation overview and to observable material such as sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Manage related identities and accounts in Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/manage-related-identities-accounts) — Microsoft ## Primary reference - Name: Manage related identities and accounts in Microsoft Defender for Identity - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/manage-related-identities-accounts - Source publication date: 2026-07-23 ## Citation and use Preferred citation: “Link fragmented user accounts only with evidence of common identity,” DSE Security, https://update.dsesecurity.com/updates/link-fragmented-user-accounts-with-evidence-of-common-identity/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Locate the failed layer in a drive firmware-update attempt > How should a failed Windows drive firmware update be investigated? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-029-locate-the-failed-layer-in-a-drive-firmware-update-attempt/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:42+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know How should a failed Windows drive firmware update be investigated? ## Potentially affected Use this review after a drive firmware operation fails or capability is uncertain. ## DSE recommendation Reproduce the capability query without changing the firmware first. ## Article ## Source facts Microsoft explains that the PowerShell firmware-update path depends on Windows storage APIs, drivers, hardware, and their implementation of the required commands. Failures can arise at several of these layers. The documentation uses Get-StorageFirmwareInfo with a PhysicalDisk object to check whether a device exposes the expected command support. For unsupported commands, Microsoft directs administrators to the vendor or Windows Server Catalog for suitable firmware or devices. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/troubleshoot-firmware-update). ## Applicability Use this review after a drive firmware operation fails or capability is uncertain. Identify the exact drive, controller, driver, and attempted operation before retrying. Keep the original error and the device’s reported firmware version. ## DSE recommendation Reproduce the capability query without changing the firmware first. Compare the returned information with the intended device and the vendor documentation. Escalate a command-support gap with the hardware details and original failure evidence. Ask the storage owner to approve any further update attempt, including its workload impact, instead of treating repeated retries as a diagnostic method. ## Verification Retain the query output and identify the layer for which support remains unconfirmed. If a vendor-approved correction is later tested, compare the before-and-after capability and firmware observations. Check the associated workload through the agreed acceptance procedure. Close the issue only when the original failure and the corrective action are both accounted for. ## Official references [Microsoft Learn: Troubleshooting drive firmware updates](https://learn.microsoft.com/en-us/windows-server/storage/troubleshoot-firmware-update). Source reviewed September 8, 2026. ## Primary reference - Name: Troubleshooting drive firmware updates - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/troubleshoot-firmware-update - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Locate the failed layer in a drive firmware-update attempt,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-029-locate-the-failed-layer-in-a-drive-firmware-update-attempt/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Log AI tool calls as privileged operations—not just chat transcripts > A chat transcript cannot prove which identity, permission, tool, parameters, approval, or downstream result produced a business change. Build a protected event chain around every AI tool invocation while keeping secrets and sensitive content out of routine telemetry. - Canonical URL: https://update.dsesecurity.com/updates/log-ai-tool-calls-privileged-operations/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:28:00+00:00 - Modified: 2026-08-17T19:22:08+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know A chat transcript cannot prove which identity, permission, tool, parameters, approval, or downstream result produced a business change. Build a protected event chain around every AI tool invocation while keeping secrets and sensitive content out of routine telemetry. ## Potentially affected Tool-using AI agents; model and orchestration services; APIs; databases; tickets; email and workflow systems; approval services; identities and tokens; observability pipelines; SIEM platforms; and audit retention. ## DSE recommendation Define a tool-call event schema, correlate the full execution chain, record authorization and approval decisions, protect telemetry independently from the agent, redact sensitive values, alert on behavioral change, and test incident reconstruction. ## Article ## Source facts: a tool invocation is an execution boundary Microsoft’s [runtime-risk guidance for AI agents](https://www.microsoft.com/en-us/security/blog/2026/01/23/runtime-risk-realtime-defense-securing-ai-agents/) describes tool invocations as high-value, high-risk events. In the Microsoft product pattern discussed, context about a planned invocation can be evaluated before execution so policy can allow or block it. The larger principle is product independent: once a model can call an API, update a record, send a message, or run code, observability must extend beyond generated text. OpenTelemetry publishes GenAI semantic attributes for operations, agents, conversations, retrieval, tool definitions, tool-call identifiers, arguments, and results. Its documentation also warns that messages, queries, arguments, and results may contain sensitive information. Some GenAI conventions are still in development or have moved between repositories, so they are useful building blocks rather than a finished compliance record that every implementation can adopt unchanged. A transcript can show what the user asked and what the assistant claimed it did. It cannot by itself prove which agent version ran, what context was retrieved, which identity obtained a token, what permission was evaluated, whether approval occurred, which exact parameters reached the tool, what the downstream system accepted, or whether a retry created duplicate effects. Those facts require events from the orchestrator, identity layer, policy point, tool gateway, and target system. ## DSE recommendation: create one reconstructable chain from request to effect Design the audit path before production. Start with the decisions investigators, administrators, customers, and reviewers would need to reproduce after an unexpected change. - Assign stable identities and versions. Record the human requester, agent identity, orchestrator, model and version, governing prompt or policy version, tool server, tool definition version, deployment environment, and target tenant. Distinguish acting as the user from acting as the agent’s own service identity. - Correlate the execution. Generate a request ID and carry it through planning, retrieval, policy evaluation, token issuance, approval, each tool attempt, target-system response, retry, rollback, and final user message. Keep parent and child relationships when one request creates several calls or sub-agents. - Record the control decisions. Capture requested operation, target, authorization scope, policy result, approval requirement, reviewer, decision time, expiry, denial reason, rate limit, and stop condition. Record the enforced decision, not merely the model’s explanation of why an action should be allowed. - Protect content selectively. Prefer hashes, object IDs, field names, counts, classifications, and redacted summaries when full arguments or results are unnecessary. Never copy access tokens, passwords, private keys, or whole sensitive records into ordinary traces. Place any content-rich forensic record behind stricter access and retention. - Keep evidence outside the agent’s control. Send security-relevant events to a protected collector the agent and tool cannot alter or delete. Monitor missing exporters, sequence gaps, clock problems, schema changes, disabled instrumentation, and unexplained differences between orchestrator and target-system logs. - Test reconstruction and response. Run a controlled action, then ask an independent reviewer to identify who requested it, what evidence was used, which permissions and approvals applied, what changed, whether retries occurred, and how to revoke the agent. Exercise unexpected denial, partial completion, tool timeout, and rollback. Factual boundary: OpenTelemetry conventions standardize useful fields but do not guarantee that an implementation records every event, protects the record, or preserves semantic truth. Logging tool inputs and results can itself create privacy and credential risk. Microsoft product behavior described in the primary source should not be represented as a capability of every agent platform. Measure tool calls without correlation, unknown agent versions, approval-to-execution delay, denied and retried calls, missing target confirmations, sensitive-field redactions, and reconstruction test success. The goal is evidence that survives the conversation: enough to explain and contain the real operation without turning the logging system into a second sensitive-data store. ## Official references - Microsoft Security, [From runtime risk to real-time defense: Securing AI agents](https://www.microsoft.com/en-us/security/blog/2026/01/23/runtime-risk-realtime-defense-securing-ai-agents/), January 23, 2026. - OpenTelemetry, [Generative AI semantic attributes](https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/); stability notices should be reviewed before adoption. - NIST, [Generative Artificial Intelligence Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence), NIST AI 600-1. ## Primary reference - Name: Microsoft Security: From runtime risk to real-time defense - Authority: www.microsoft.com - URL: https://www.microsoft.com/en-us/security/blog/2026/01/23/runtime-risk-realtime-defense-securing-ai-agents/ - Source publication date: 2026-01-23 ## Citation and use Preferred citation: “Log AI tool calls as privileged operations—not just chat transcripts,” DSE Security, https://update.dsesecurity.com/updates/log-ai-tool-calls-privileged-operations/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Log Windows Firewall drops and successes to separate paths > Use Configure Windows Firewall logging to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/log-windows-firewall-drops-and-successes-separately/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:45+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Use Configure Windows Firewall logging to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Configure Windows Firewall logging ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Log Windows Firewall drops and successes to separate paths. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Configure Windows Firewall logging](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-logging) from Microsoft supports the following bounded statements: - Windows Firewall can log dropped packets and successful connections. The research record locates this support at Opening overview. - Microsoft documents configuration through CSP or Group Policy together with parsing and missing-log troubleshooting. The research record locates this support at Opening overview; sections: Parsing methods; Troubleshoot if the log file is not created or modified. Keep the evidence boundary at these traced claims. They support a review of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Size, rotate, protect, and centralize logs without exposing sensitive network metadata unnecessarily. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview; sections: Parsing methods; Troubleshoot if the log file is not created or modified, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview; sections: Parsing methods; Troubleshoot if the log file is not created or modified and to observable material such as policy and feature state, security events, test detections, administrative assignments, exception approvals, and response tickets. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Configure Windows Firewall logging](https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-logging) — Microsoft ## Primary reference - Name: Configure Windows Firewall logging - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/configure-logging - Source publication date: 2025-04-07 ## Citation and use Preferred citation: “Log Windows Firewall drops and successes to separate paths,” DSE Security, https://update.dsesecurity.com/updates/log-windows-firewall-drops-and-successes-separately/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Maintain a regulated stationary-source emergency-response program and keep it current > Use 40 CFR 68.95 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/maintain-a-regulated-stationary-source-emergency-response-program-and-keep-it-current/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:47+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.95 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.95 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Maintain a regulated stationary-source emergency-response program and keep it current. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.95 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.95) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the emergency response plan maintained at the stationary source must include procedures and measures for responding after an accidental release of a regulated substance. The research record locates this support at 40 CFR 68.95(a)(1)(iii), read with 40 CFR 68.95(a)(1) (eCFR anchor p-68.95(a)(1)(iii)). - Under 40 CFR 68, the owner or operator must update the plan for source changes or new information from coordination, exercises, investigations, or other sources and inform employees of the changes. The research record locates this support at 40 CFR 68.95(a)(4) (eCFR anchor p-68.95(a)(4)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives and the conditions the source actually describes. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 40 CFR 68.95(a)(1)(iii), read with 40 CFR 68.95(a)(1) (eCFR anchor p-68.95(a)(1)(iii)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.95(a)(4) (eCFR anchor p-68.95(a)(4)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations 40 CFR 68.95(a)(1)(iii), read with 40 CFR 68.95(a)(1) (eCFR anchor p-68.95(a)(1)(iii)); 40 CFR 68.95(a)(4) (eCFR anchor p-68.95(a)(4)) adjacent to the sanitized artifacts used for comparison. Prefer business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [40 CFR 68.95 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.95) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.95 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.95 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Maintain a regulated stationary-source emergency-response program and keep it current,” DSE Security, https://update.dsesecurity.com/updates/maintain-a-regulated-stationary-source-emergency-response-program-and-keep-it-current/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Maintain an airport contingency plan for security conditions and disruptions > Use 49 CFR 1542.301 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/maintain-an-airport-contingency-plan-for-security-conditions-and-disruptions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:23+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.301 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.301 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Maintain an airport contingency plan for security conditions and disruptions. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.301 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.301) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, each airport operator required to have a security program under section 1542.103(a) and (b) must adopt a contingency plan and must implement its contingency plan when directed by TSA. The research record locates this support at 49 CFR 1542.301(a)(1), read with 49 CFR 1542.301(a) (eCFR anchor p-1542.301(a)(1)). - Under 49 CFR 1542, each airport operator required to have a security program under section 1542.103(a) and (b) must adopt a contingency plan and must ensure that all parties involved know their responsibilities and that all information contained in the plan is current. The research record locates this support at 49 CFR 1542.301(a)(3), read with 49 CFR 1542.301(a) (eCFR anchor p-1542.301(a)(3)). Keep the evidence boundary at these traced claims. They support a review of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 49 CFR 1542.301(a)(1), read with 49 CFR 1542.301(a) (eCFR anchor p-1542.301(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.301(a)(3), read with 49 CFR 1542.301(a) (eCFR anchor p-1542.301(a)(3)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 49 CFR 1542.301(a)(1), read with 49 CFR 1542.301(a) (eCFR anchor p-1542.301(a)(1)); 49 CFR 1542.301(a)(3), read with 49 CFR 1542.301(a) (eCFR anchor p-1542.301(a)(3)). Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [49 CFR 1542.301 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.301) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.301 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.301 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Maintain an airport contingency plan for security conditions and disruptions,” DSE Security, https://update.dsesecurity.com/updates/maintain-an-airport-contingency-plan-for-security-conditions-and-disruptions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Maintain electronic-system inventories, documentation, and migration plans > Use 36 CFR 1236.26 - Maintaining electronic information systems to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/maintain-electronic-system-inventories-documentation-and-migration-plans/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:27+00:00 - Modified: 2026-08-27T13:07:00+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 36 CFR 1236.26 - Maintaining electronic information systems to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 36 CFR 1236.26 - Maintaining electronic information systems ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Maintain electronic-system inventories, documentation, and migration plans. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [36 CFR 1236.26 – Maintaining electronic information systems](https://www.ecfr.gov/current/title-36/section-1236.26) from National Archives and Records Administration via eCFR supports the following bounded statements: - Under 36 CFR 1236, the rule requires that agencies maintain up-to-date documentation about electronic information systems that is adequate to specify all technical characteristics necessary for reading and processing the records contained in the system. The research record locates this support at 36 CFR 1236.26(b)(1), read with 36 CFR 1236.26(b) (eCFR anchor p-1236.26(b)(1)). - Under 36 CFR 1236, the rule requires that agencies maintain inventories of electronic information systems and review the systems periodically for conformance to established agency procedures, standards, and policies as part of the periodic reviews required by 44 U.S.C. 3506. The research record locates this support at 36 CFR 1236.26(a) (eCFR anchor p-1236.26(a)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives and the conditions the source actually describes. ## What the source does not establish Federal agency records-management regulation; inventory depth, schedules, technical dependencies, migration, validation, security, and permanent-record transfer require complete-section and NARA-guidance review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 36 CFR 1236.26(b)(1), read with 36 CFR 1236.26(b) (eCFR anchor p-1236.26(b)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 36 CFR 1236.26(a) (eCFR anchor p-1236.26(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations 36 CFR 1236.26(b)(1), read with 36 CFR 1236.26(b) (eCFR anchor p-1236.26(b)(1)); 36 CFR 1236.26(a) (eCFR anchor p-1236.26(a)) adjacent to the sanitized artifacts used for comparison. Prefer business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [36 CFR 1236.26 – Maintaining electronic information systems](https://www.ecfr.gov/current/title-36/section-1236.26) — National Archives and Records Administration via eCFR ## Primary reference - Name: 36 CFR 1236.26 - Maintaining electronic information systems - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-36/section-1236.26 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Maintain electronic-system inventories, documentation, and migration plans,” DSE Security, https://update.dsesecurity.com/updates/maintain-electronic-system-inventories-documentation-and-migration-plans/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make eBGP default-reject a tested policy, not a surprise outage > Confirm explicit import and export policy coverage before changing an eBGP platform to default-reject behavior. - Canonical URL: https://update.dsesecurity.com/updates/make-ebgp-default-reject-a-tested-policy/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:51+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Confirm explicit import and export policy coverage before changing an eBGP platform to default-reject behavior. ## Potentially affected Networks upgrading or standardizing routers that operate external BGP sessions ## DSE recommendation Inventory policy attachment in both directions, stage default-reject behavior, and prove expected prefixes before and after each change. ## Article An eBGP session being established does not mean it should exchange routes. Default-reject behavior reduces accidental propagation, but an upgrade that activates it before policies are attached can remove legitimate reachability just as effectively as a bad filter. ## Source fact: [IETF RFC 8212](https://www.rfc-editor.org/rfc/rfc8212.html) specifies a safer default for external BGP. When an explicit import policy has not been applied, routes received from an eBGP neighbor are not eligible for route selection. When an explicit export policy has not been applied, routes are not added to that neighbor’s outbound advertisement set. The intent is to avoid accidental route exchange caused by the historical assumption that an unconfigured session may accept and advertise broadly. The RFC also recognizes transition reality. An implementation can provide a configuration option that retains the previous behavior, and existing deployments may need a migration period. That accommodation makes release notes, default settings, and configuration inheritance important parts of the change—not merely the route-map text visible on one neighbor. ## Boundary Default-reject is a baseline behavior, not a complete routing-security policy. An explicitly attached policy can still be overly broad, refer to stale prefix data, or apply in the wrong direction. Platform semantics differ on what counts as an explicit policy, especially with templates, address-family activation, route servers, and generated configurations. The RFC does not validate the business authorization for any prefix. ## Applicability questions - Which routers and releases implement RFC 8212 behavior, and what is each device’s current default? - Does every active eBGP address family have an intentional import and export policy? - Are inherited, empty, or pass-all policies treated as explicit by the platform? - Which prefixes and communities should be received and advertised for each relationship? - Is an out-of-band recovery path available if management reachability depends on the changed session? ## DSE recommendation: Export the running neighbor inventory and normalize it by device, virtual routing instance, peer, and address family. For every direction, link the attached policy to an approved prefix and community expectation. Flag missing attachments, empty policy objects, and compatibility knobs. Resolve those gaps before changing the default. Stage the behavior in a representative lab or a single controlled peer. Capture received routes, selected routes, and advertised routes before the change. Apply or verify explicit policies, enable the target behavior, and compare the same data. Roll out in small groups with route-count, reachability, and session-state monitoring. Keep a time-bounded rollback step that restores the known setting without discarding the new policy objects. ## Verification and evidence Evidence should include the device and software matrix, neighbor/address-family inventory, approved prefix expectations, policy definitions and attachment points, pre/post route snapshots, external route-collector observations where available, and change records. A useful negative test establishes that a session with no policy exchanges no routes. A positive test establishes that adding the approved policy restores only the expected routes. ## Official references - [IETF RFC 8212](https://www.rfc-editor.org/rfc/rfc8212.html) - [IETF RFC 4271, A Border Gateway Protocol 4](https://www.rfc-editor.org/rfc/rfc4271.html) ## Primary reference - Name: RFC 8212: Default External BGP Route Propagation Behavior without Policies - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8212.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Make eBGP default-reject a tested policy, not a surprise outage,” DSE Security, https://update.dsesecurity.com/updates/make-ebgp-default-reject-a-tested-policy/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make edge-storage encryption recoverable before enabling it > Encrypting a camera card can protect removed media, but initialization and recovery actions can erase recordings. Establish passphrase custody and recovery tests first. - Canonical URL: https://update.dsesecurity.com/updates/make-edge-storage-encryption-recoverable-before-enabling-it/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:55+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, Video Surveillance - Reading time: 2 minutes ## What you need to know Encrypting a camera card can protect removed media, but initialization and recovery actions can erase recordings. Establish passphrase custody and recovery tests first. ## Potentially affected Axis cameras using encrypted SD-card storage for primary, distributed, or failover recording. ## DSE recommendation Before enabling encryption, approve key custody, preserve any required footage, test supported recovery on non-evidence media, and document destructive format or decrypt steps. ## Article Bottom line: storage encryption can reduce disclosure from removed media, but a lost passphrase or misunderstood format/decrypt action can make authorized recovery impossible or erase the recording. Design recovery before changing the card. ## Source fact: encryption and decryption workflows can format storage The [AXIS OS Web Interface Help for LTS 2026](https://help.axis.com/en-us/axis-os-web-interface-help-lts-2026) documents encrypted SD-card controls. It states that encrypting a card formats and erases it and that decrypting it also formats and erases it. The interface documentation distinguishes changing the encryption password from those destructive operations. Related Axis guidance states that the original passphrase is required for supported reuse or decryption scenarios. The safe sequence is therefore evidence first, configuration second. A technician should never discover the destructive effect while handling the only copy of relevant video. ## Source boundary and applicability The help applies to supported Axis products and software. Exact controls, recovery tools, passphrase behavior, and compatibility can differ by release and card state. Encryption does not by itself secure camera credentials, live streams, recorder copies, exports, backups, or authorized misuse. Organizational key-management and evidence rules remain necessary. ## Applicability questions - What threat is encryption addressing: theft, removed media, service handling, or disposal? - Is the card the only copy, failover copy, or a synchronized recording? - Who creates, stores, retrieves, rotates, and audits the passphrase? - Can recovery occur if the camera fails and the card must be handled elsewhere? - Which actions format or erase the media on the deployed AXIS OS version? ## DSE recommendation: use a two-person encryption runbook The following steps are DSE recommendations based on the cited source. Inventory the exact camera, firmware, card, purpose, and existing footage. Place any required recording under the appropriate hold or export workflow before initialization. Generate and escrow the passphrase in an approved secrets system with role separation, recovery access, and audit logging. Do not place it in a ticket, camera name, drawing, or unsecured installer note. Rehearse enablement, authorized access, password change, camera replacement, and recovery using disposable test media and the supported tools. Mark every destructive step explicitly and require confirmation of card identity and evidence status. Define what occurs if the secret is unavailable or a device fails. Set a recurring escrow-recovery check that proves an authorized alternate can retrieve the correct secret without displaying it to the tester or altering production media. ## Verification and evidence Retain the approved threat decision, device/card inventory, non-evidence test record, screenshots or exports that avoid secret disclosure, escrow-access test, role review, before-and-after recording check, and change ticket. Never attach the passphrase to the evidence package or verification artifact. ## Official references - [AXIS OS Web Interface Help – LTS 2026](https://help.axis.com/en-us/axis-os-web-interface-help-lts-2026) – Axis Communications ## Primary reference - Name: AXIS OS Web Interface Help - LTS 2026 - Authority: Axis Communications - URL: https://help.axis.com/en-us/axis-os-web-interface-help-lts-2026 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Make edge-storage encryption recoverable before enabling it,” DSE Security, https://update.dsesecurity.com/updates/make-edge-storage-encryption-recoverable-before-enabling-it/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make emergency alerts and evacuation workflows accessible by design > Design alerts, transportation, evacuation, and shelter procedures so people with disabilities can receive information and use the response. - Canonical URL: https://update.dsesecurity.com/updates/make-emergency-workflows-accessible-by-design/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:29+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know Design alerts, transportation, evacuation, and shelter procedures so people with disabilities can receive information and use the response. ## Potentially affected State and local government emergency programs, plus organizations using the DOJ guidance as a planning reference ## DSE recommendation Include people with disabilities in planning and exercises, provide multiple accessible communication methods, and verify the whole workflow. ## Article An alert is not effective if some people cannot perceive it, understand it, or act on it. Accessibility must connect warning, assistance, transportation, evacuation, shelter, and return—not stop at adding one more message format. ## Source fact: [The U.S. Department of Justice’s ADA emergency-planning guidance](https://www.ada.gov/topics/emergency-planning/) addresses the obligations of state and local governments toward people with disabilities. It explains that emergency notifications need methods that reach people who are deaf or hard of hearing and people who are blind or have low vision, including both visual and audible approaches and multiple communication methods. The guidance also addresses accessible evacuation and transportation, shelter access, effective communication, service animals, and disability-related needs in emergency programs. It encourages planning with people with disabilities rather than assuming what will work. The DOJ page states that the guidance is informal, has no legally binding effect, and does not create duties beyond applicable law. ## Boundary The source’s legal discussion is specifically directed to state and local governments under the ADA. This article is not a legal determination for any organization, facility, employee, customer, or jurisdiction. Employers, federal agencies, private businesses, housing providers, schools, healthcare entities, and recipients of federal funds may have different or additional obligations. Local codes, emergency authority, privacy rules, and individual accommodation processes require qualified review. ## Applicability questions - Who uses or visits each facility, and which access or communication needs have been identified through inclusive engagement? - Can alerts be perceived without relying only on sound, sight, color, fine motor control, or one language channel? - Are accessible routes, areas of refuge, evacuation devices, transportation, and shelters available for the actual hazard? - How are personal assistance, medical equipment, power, medication, and service animals addressed without improper assumptions? - Do alternate sites and third-party transport providers meet the planned accessibility needs? ## DSE recommendation: Engage people with varied disabilities and local accessibility expertise during design, procurement, and exercises. Map the complete journey from receiving an alert through reaching safety and returning or relocating. Use redundant, accessible formats and plain instructions. Validate captioning, text, visual indicators, audio, screen-reader behavior, language access, and contact methods on the actual systems. Survey evacuation routes and equipment with facilities, fire/life-safety professionals, emergency management, and legal counsel. Train staff in role-specific assistance without requiring unsafe lifting or improvisation. Arrange accessible transportation and alternate-site capability contractually where needed. Offer confidential, voluntary planning channels for individual needs and protect that information. Correct failures found in exercises with an accountable owner and date. ## Verification and evidence Retain inclusive-engagement records, accessibility reviews, vendor test results, route and equipment inspections, training attendance, exercise observations, accommodation process documentation, and remediation closure. Evidence should cover varied notification modes and at least one end-to-end scenario, not merely successful message transmission. Obtain current legal advice for the organization’s facts and jurisdiction before presenting the plan as compliant. ## Official references - [U.S. Department of Justice: Emergency Planning under the ADA](https://www.ada.gov/topics/emergency-planning/) ## Primary reference - Name: Emergency Planning under the Americans with Disabilities Act - Authority: www.ada.gov - URL: https://www.ada.gov/topics/emergency-planning/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Make emergency alerts and evacuation workflows accessible by design,” DSE Security, https://update.dsesecurity.com/updates/make-emergency-workflows-accessible-by-design/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make every onsite 911 call direct, locatable, and locally visible > A 911 call from a desk, lobby, elevator landing, guard post, or conference room should connect without a prefix, carry usable dispatchable location, alert the right onsite responder, and survive moves and changes. - Canonical URL: https://update.dsesecurity.com/updates/make-onsite-911-calls-direct-locatable-locally-visible/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:32:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity - Reading time: 4 minutes ## What you need to know A 911 call from a desk, lobby, elevator landing, guard post, or conference room should connect without a prefix, carry usable dispatchable location, alert the right onsite responder, and survive moves and changes. ## Potentially affected Multi-line telephone systems, lobby and guard phones, fixed desk and wall phones, common-area emergency phones, softphones, remote users, dispatchable-location records, onsite notifications, reception, facilities, security, and emergency procedures. ## DSE recommendation Inventory every path people may use to call 911, confirm the applicable legal requirements, assign and validate dispatchable locations, test direct dialing and onsite notification with authorized partners, and retest after every material move or system change. ## Article ## Source facts: emergency calling includes connection, location, and notification The National 911 Program’s [Kari’s Law and RAY BAUM’s Act guidance](https://www.911.gov/issues/legislation-and-policy/kari-s-law-and-ray-baum-s-act/) explains two related federal requirements for multi-line telephone systems. Kari’s Law addresses direct dialing of 911 without an outside-line prefix and requires notification to a central location onsite or offsite when a 911 call is made. The notice is intended to include a callback number and information about the caller’s location. RAY BAUM’s Act addresses dispatchable location. The guidance defines this as a validated street address plus additional information, such as a suite, apartment, or similar detail, needed to locate the caller. In a campus or multi-story facility, a street address alone may not direct responders to the correct building, entrance, floor, wing, or room. Requirements vary for fixed, non-fixed, onsite, and offsite devices, and applicability depends on the system and relevant dates. The Federal Communications Commission is the authority on federal compliance. State and local 911 rules, fire and building codes, elevator requirements, carrier capabilities, and the emergency communications center’s practices can add obligations. A business should obtain qualified legal and technical advice rather than treating this article as a compliance determination. ## DSE recommendation: test the caller-to-responder path as a life-safety function Create an emergency-calling register that covers more than ordinary desk phones. Include reception and guard stations, conference rooms, common-area and refuge-area phones, elevator or parking devices, analog lines, contact-center positions, softphones, shared phones, temporary spaces, remote users, and any security intercom that can place an outside call. - Assign a real location. For each endpoint or calling zone, record the civic address and the additional building, entrance, floor, suite, room, quadrant, or landmark responders need. Use names that match posted wayfinding and the information known to the responding agency. Do not rely on an internal extension label that public safety cannot interpret. - Verify direct dialing. Confirm that dialing 911 reaches the correct emergency communications center without a trunk prefix, authorization code, receptionist, or menu. Preserve 911 behavior when ordinary outbound calling restrictions are applied. - Design the onsite notice. Route the legally required notification to a continuously appropriate destination, not one unattended inbox. The recipient should see the callback and location, avoid delaying or intercepting the call, initiate the site response, direct responders to the caller, and protect sensitive incident information. - Test failure and mobility cases. Address a phone moved to another jack, a softphone used from home, Wi-Fi calling, loss of primary connectivity, power failure, failover carrier, changed tenant suite, renovated floor, night shift, and a notification recipient who is unavailable. Define which cases cannot provide an automatic precise location and what approved alternative applies. - Coordinate lawful testing. Never create an unannounced test call to 911. Arrange the method and timing with the service provider and appropriate emergency communications center, then verify the displayed calling number and location, two-way audio, routing, callback, and onsite notification. Document who authorized and observed the test. - Control change. Make emergency-location review mandatory when phones, switches, trunks, carriers, network zones, room numbers, tenants, buildings, or notification groups change. A successful commissioning test years ago does not prove today’s location record. Post the facility address and concise location cues where a caller can read them under stress. Train reception and security not to hang up, transfer, or call the person placing the emergency call merely to investigate. Their job is to support the response: open the correct entrance, send a guide, control an elevator if authorized, bring emergency equipment, and preserve access for responders. Audit unmatched endpoints, duplicate or vague locations, test exceptions, failed notifications, and moves completed without 911 review. The acceptance record should prove the entire chain—from a person dialing three digits to public safety receiving a usable location and onsite staff taking a defined supporting action. ## Official references - National Highway Traffic Safety Administration, National 911 Program, [Kari’s Law and RAY BAUM’s Act](https://www.911.gov/issues/legislation-and-policy/kari-s-law-and-ray-baum-s-act/), updated March 8, 2023. - Federal Communications Commission, [Implementing Kari’s Law and Section 506 of RAY BAUM’s Act](https://docs.fcc.gov/public/attachments/FCC-18-132A1_Rcd.pdf), Report and Order FCC 18-132. ## Primary reference - Name: National 911 Program: Kari's Law and RAY BAUM's Act - Authority: www.911.gov - URL: https://www.911.gov/issues/legislation-and-policy/kari-s-law-and-ray-baum-s-act/ - Source publication date: 2023-03-08 ## Citation and use Preferred citation: “Make every onsite 911 call direct, locatable, and locally visible,” DSE Security, https://update.dsesecurity.com/updates/make-onsite-911-calls-direct-locatable-locally-visible/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make every security event tell the same time > Camera, recorder, access-control, identity, alarm, and network records become difficult to correlate when clocks disagree. Build a governed time hierarchy, measure offset, alert on drift, and prove behavior through outage and reboot tests. - Canonical URL: https://update.dsesecurity.com/updates/make-every-security-event-tell-the-same-time/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know Camera, recorder, access-control, identity, alarm, and network records become difficult to correlate when clocks disagree. Build a governed time hierarchy, measure offset, alert on drift, and prove behavior through outage and reboot tests. ## Potentially affected Organizations correlating camera video, access events, alarms, intercoms, identity records, servers, switches, firewalls, and investigation logs. ## DSE recommendation Inventory every clock and time source, define an approved hierarchy and tolerance by use case, monitor drift, and run documented commissioning, failover, restart, and daylight-saving tests. ## Article ## Source fact: timestamps need a trustworthy reference NIST’s IoT cybersecurity guidance says devices should be able to timestamp audit events, synchronize with a verified time source, translate timestamps to UTC or GMT, and report when time strays beyond a defined threshold. See NIST’s [Cybersecurity Event Awareness capability](https://pages.nist.gov/FederalProfile-8259A/technical/event/). NISTIR 8161 Revision 1 likewise treats precise time and clock-offset information as important to useful surveillance-video exchange. The Internet Engineering Task Force’s [RFC 8633](https://www.rfc-editor.org/rfc/rfc8633.html) recommends keeping Network Time Protocol software current, using enough time sources, considering diversity, restricting control messages, and monitoring for out-of-sync servers and suspicious behavior. It also warns that authentication cannot prevent every delay-manipulation attack. Synchronization is therefore an operated service, not a promise that every timestamp is exact. ## DSE recommendation: define the timeline before configuring devices Create an inventory of every system that originates, changes, displays, or exports time: cameras, encoders, recorders, video clients, access panels, readers, intrusion panels, intercoms, visitor systems, domain controllers, identity platforms, hypervisors, switches, firewalls, log collectors, and cloud services. For each, record the supported protocol, configured source, time zone, daylight-saving behavior, UTC handling, sync status, expected accuracy, authentication option, and what happens when its source disappears. Then define an approved hierarchy. A common design uses authoritative external or enterprise sources feeding controlled internal time servers, with security devices acting only as clients. That is a DSE architecture recommendation, not a universal NIST topology. Some embedded devices support only SNTP, one server, an IP address instead of a hostname, or no authenticated mode. Document those limitations rather than assuming identical behavior. ## Make offset visible Set an organization-approved tolerance for each workflow. Door-event correlation may tolerate a different offset than frame-level analysis, distributed authentication, or industrial control. NIST SP 800-171 Revision 3 leaves timestamp granularity and synchronization to the organization and permits UTC, a fixed offset from UTC, or a local timestamp that includes its UTC offset. The defensible choice is the one the organization defines, verifies, and can explain. - Monitor client state, selected source, stratum or equivalent quality indicator, last successful synchronization, and measured offset where the product exposes them. - Alert when a device loses its source, changes source unexpectedly, steps its clock, crosses the approved threshold, or repeatedly restarts its time service. - Keep configuration and change logs for the time servers themselves. Restrict who can change time, time zones, and source settings. - Prefer UTC in centralized logs when supported, while preserving the offset needed to explain local wall-clock displays. ## Test the whole evidence path During commissioning, generate one authorized, harmless event that appears in several systems—for example, a test credential at a controlled door while a camera records and the access server logs. Compare the original device records, server records, video overlay, exported-file metadata, and centralized logs. Record the observed differences; do not adjust evidence after the fact to make it align. Repeat the test after a camera or panel restart, time-server outage, network interruption, recorder failover, firmware update, and daylight-saving transition where local displays are used. Check a device that has been disconnected long enough for its clock to drift. Confirm what operators see when synchronization is unavailable and whether alerts reach an accountable owner. ## Handle an incident without rewriting history If an investigation reveals a wrong clock, preserve the original records and document how the offset was measured, by whom, against which reference, and when. Do not rename files or edit overlays to create corrected evidence. A derived timeline may apply a documented correction, but it should remain traceable to the source timestamps and their uncertainty. Time synchronization cannot prove that an event occurred, that a camera saw the correct scene, or that a log remained unaltered. It makes cross-system comparison more reliable. Pair it with protected logs, controlled administration, tested exports, and custody records. ## Official sources - [IETF RFC 8633, Network Time Protocol Best Current Practices](https://www.rfc-editor.org/rfc/rfc8633.html) - [NIST Cybersecurity Event Awareness capability](https://pages.nist.gov/FederalProfile-8259A/technical/event/) - [NIST SP 800-171 Revision 3, Audit and Accountability](https://csrc.nist.gov/pubs/sp/800/171/r3/final) - [NISTIR 8161 Revision 1](https://doi.org/10.6028/NIST.IR.8161r1) ## Primary reference - Name: RFC 8633 — Network Time Protocol Best Current Practices - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8633.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Make every security event tell the same time,” DSE Security, https://update.dsesecurity.com/updates/make-every-security-event-tell-the-same-time/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make every security exception expire—or escalate > An exception without an owner, evidence, compensating control, expiry, and removal plan becomes an undocumented standard. Use a common register, risk-based approval, automatic reminders, verification, and escalation for renewal. - Canonical URL: https://update.dsesecurity.com/updates/make-every-security-exception-expire-or-escalate/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:49:00+00:00 - Modified: 2026-08-17T19:22:10+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know An exception without an owner, evidence, compensating control, expiry, and removal plan becomes an undocumented standard. Use a common register, risk-based approval, automatic reminders, verification, and escalation for renewal. ## Potentially affected Security policies and technical standards; vulnerability remediation; access and authentication; endpoint and network controls; unsupported systems; supplier requirements; change management; risk acceptance; audits; and remediation programs. ## DSE recommendation Create one exception workflow, require scope and evidence, assess residual risk, assign compensating controls and owners, set short expiry, monitor conditions, verify closure, and escalate repeated or high-impact renewals. ## Article ## Source facts: risk decisions require continuing accountability NIST [SP 800-37 Rev. 2](https://csrc.nist.gov/pubs/sp/800/37/r2/final) describes a Risk Management Framework that integrates security and privacy risk management into the system development lifecycle. The framework includes preparation, control selection and implementation, assessment, authorization, and continuous monitoring. Risk acceptance is therefore connected to accountable decision-making and current evidence, not a permanent label applied once. NIST [SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) provides security and privacy control outcomes and enhancements covering assessment, plans of action, configuration, access, vulnerability remediation, monitoring, and many other areas where exceptions arise. Organizations tailor controls based on mission, environment, requirements, and risk. Neither publication mandates one universal approval level, maximum duration, form, or compensating control for every exception. The organization must define those parameters. The common requirement is an explainable decision that remains valid only while its facts, scope, and risk treatment remain current. ## DSE recommendation: make renewal more demanding than initial approval An exception process should enable necessary work while making drift visible. Repeated renewal is evidence that the underlying design, ownership, funding, or requirement needs a higher-level decision. - Define what qualifies. Distinguish a temporary exception from a standard change, false positive, accepted product limitation, permanent architecture decision, or incident containment measure. Route each through the correct authority rather than using one generic risk-acceptance field. - Require a complete request. Record the requirement being departed from, exact assets and users, environment, business reason, technical constraint, start date, requested end date, data and service impact, threat scenario, evidence, alternatives considered, and requested control change. Reject vague scopes such as all servers or until fixed. - Evaluate residual risk. Identify the control objective that is weakened, likelihood and consequence under current exposure, dependencies, detection capability, legal or contractual limits, and whether the exception combines with others. Use qualified technical, business, privacy, safety, and compliance reviewers where relevant. - Assign treatment and authority. Specify compensating controls, implementation owner, evidence, monitoring, incident triggers, remediation owner, milestones, budget or dependency, and approval level proportionate to residual risk. The person who benefits from the exception should not be the only person accepting it. - Set expiry and automatic escalation. Choose the shortest practical duration and notify owners before expiry. Automatically disable the exception where safe or escalate it for decision. High-impact, repeatedly renewed, expanded, or overdue exceptions should require a more senior risk owner and an explicit remediation plan. - Monitor changed conditions. Reassess after exploitation activity, incidents, vendor updates, new exposure, asset transfer, architecture change, compensating-control failure, or regulatory change. Define conditions that end approval immediately rather than waiting for the calendar date. - Verify closure. Confirm the original requirement is restored, the workaround is removed from every management path, compensating measures are retired appropriately, services remain healthy, and evidence is retained. Closing a ticket without technical verification does not close the exception. Review the portfolio, not only individual requests. Several narrow exceptions affecting the same identity, application, network segment, supplier, or recovery path can combine into a larger exposure that no single approver sees. Periodic aggregation should identify concentration, recurring root causes, remediation dependencies, and standards that may need redesign. Factual boundary: NIST supplies risk-management and control frameworks; it does not set DSE or customer approval authority, exception lifespan, risk appetite, or legal sufficiency. Those decisions depend on the organization, system, contract, jurisdiction, and impact. Measure open and expired exceptions, average age, renewals, scope growth, missing compensating-control evidence, overdue remediation, concentration by system and supplier, and failed closure checks. The useful trend is not merely fewer records; it is less time spent outside the approved state and faster escalation of structural problems. ## Official references - NIST, [SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/37/r2/final). - NIST, [SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final). ## Primary reference - Name: NIST SP 800-37 Rev. 2: Risk Management Framework - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/37/r2/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Make every security exception expire—or escalate,” DSE Security, https://update.dsesecurity.com/updates/make-every-security-exception-expire-or-escalate/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make facility security response sustain critical operations and required reporting > Use 33 CFR 105.280 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/make-facility-security-response-sustain-critical-operations-and-required-reporting/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:04+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.280 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.280 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Make facility security response sustain critical operations and required reporting. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.280 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.280) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that for each MARSEC Level, the facility owner or operator ensure the Facility Security Officer and facility security personnel are able to respond to security threats or breaches of security and maintain critical facility and vessel-to-facility interface operations. The research record locates this support at 33 CFR 105.280(a), read with the unnumbered introductory paragraph of 33 CFR 105.280 (eCFR anchor p-105.280(a)). - Under 33 CFR 105, the rule requires that for each MARSEC Level, the facility owner or operator ensure the Facility Security Officer and facility security personnel are able to report security incidents as required in section 101.305 of this subchapter. The research record locates this support at 33 CFR 105.280(c), read with the unnumbered introductory paragraph of 33 CFR 105.280 (eCFR anchor p-105.280(c)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives and the conditions the source actually describes. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.280(a), read with the unnumbered introductory paragraph of 33 CFR 105.280 (eCFR anchor p-105.280(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.280(c), read with the unnumbered introductory paragraph of 33 CFR 105.280 (eCFR anchor p-105.280(c)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations 33 CFR 105.280(a), read with the unnumbered introductory paragraph of 33 CFR 105.280 (eCFR anchor p-105.280(a)); 33 CFR 105.280(c), read with the unnumbered introductory paragraph of 33 CFR 105.280 (eCFR anchor p-105.280(c)) adjacent to the sanitized artifacts used for comparison. Prefer business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [33 CFR 105.280 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.280) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.280 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.280 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Make facility security response sustain critical operations and required reporting,” DSE Security, https://update.dsesecurity.com/updates/make-facility-security-response-sustain-critical-operations-and-required-reporting/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make federation trust explicit before accepting another identity provider's assertion > Federation moves authentication information between separately administered parties. Document which provider, assertion, attributes, audience, assurance, and failure paths each relying service will accept. - Canonical URL: https://update.dsesecurity.com/updates/federation-trust-assertion-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:13+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Federation moves authentication information between separately administered parties. Document which provider, assertion, attributes, audience, assurance, and failure paths each relying service will accept. ## Potentially affected Organizations using workforce, customer, partner, or multi-tenant identity federation between independently administered identity providers and relying applications. ## DSE recommendation Create an approved federation register, constrain every assertion to its intended relying party and purpose, minimize released attributes, and test revocation and provider failure before production reliance. ## Article Bottom line: federation is a trust relationship, not merely a sign-in convenience. Before an application accepts an external identity assertion, the organization should be able to name the credential service provider, relying party, permitted attributes, intended audience, assurance expectations, validation rules, and the process for ending that trust. ## Source fact: what NIST covers [NIST SP 800-63C-4](https://csrc.nist.gov/pubs/sp/800/63/c/4/final) focuses on identity federation and the assertions used to implement it. NIST describes federation as allowing a credential service provider to provide authentication attributes and, optionally, subscriber attributes to separately administered relying parties. A relying party may also use more than one provider. The July 2025 publication supersedes the earlier SP 800-63C. That scope matters operationally. The source is about how parties exchange and rely on identity information; it is not evidence that any particular federation is correctly configured, that an upstream account remains trustworthy, or that an asserted attribute should authorize a sensitive business action. ## What the source does not establish The NIST guideline does not certify a particular identity platform, tenant, application, or implementation. It does not prove that a partner’s enrollment process matches yours, that every attribute is current, or that a relying application validates the intended recipient and context. It also does not make federation a substitute for application authorization. Applicability depends on the chosen federation pattern, assurance needs, contracts, privacy obligations, attribute sources, protocol implementation, key handling, session behavior, and the consequences of an incorrect assertion. ## Applicability questions - Which separately administered parties issue and consume each assertion? - What audience, purpose, subject, and assurance information must the relying party validate? - Which attributes are necessary, who is authoritative for them, and how quickly can they be corrected or revoked? - What happens to active sessions when the upstream account, signing key, federation agreement, or provider becomes unavailable? - Which decisions remain inside the application after authentication succeeds? ## DSE recommendation: govern the trust relationship The following steps are DSE recommendations based on the cited source. - Maintain a federation register with the business owner, technical owner, provider, relying party, protocol, environments, approved claims, key or metadata locations, assurance expectation, and review date. - Configure the narrowest practical audience and redirect boundaries. Reject assertions that are expired, improperly signed, intended for another recipient, or missing required context. - Release and retain only necessary attributes. Record the authoritative system and correction path for every claim used in access decisions. - Keep authentication and authorization distinct. After accepting an identity, evaluate current application permissions, resource policy, transaction context, and risk. - Test termination. Disable a test user, remove an entitlement, rotate federation keys or metadata, and confirm the relying application stops granting access within the documented window. - Prepare for provider or metadata failure without silently bypassing verification. Assign an owner and expiration to any emergency exception. ## Verification and evidence Retain the approved trust record, exported configuration, assertion-validation test results, sample redacted claims, key-rotation evidence, access and error logs, revocation timing results, and application authorization tests. Evidence should show both successful federation and safe rejection of invalid, stale, misdirected, or over-privileged assertions. ## Official references - [NIST SP 800-63C-4 — Digital Identity Guidelines: Federation and Assertions](https://csrc.nist.gov/pubs/sp/800/63/c/4/final) — National Institute of Standards and Technology; finalized July 31, 2025 - [NIST Digital Identity Guidelines](https://pages.nist.gov/800-63-4/) — National Institute of Standards and Technology; living online edition ## Primary reference - Name: NIST SP 800-63C-4 — Digital Identity Guidelines: Federation and Assertions - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/63/c/4/final - Source publication date: 2025-07-31 ## Citation and use Preferred citation: “Make federation trust explicit before accepting another identity provider's assertion,” DSE Security, https://update.dsesecurity.com/updates/federation-trust-assertion-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make ICF/IID emergency procedures support each client's needs > Use 42 CFR 483.475 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/make-icf-iid-emergency-procedures-support-each-client-s-needs/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:03+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 483.475 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 483.475 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Make ICF/IID emergency procedures support each client’s needs. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 483.475 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-483.475) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 483, the rule requires that the plan do all of the following: address the special needs of its client population, including, but not limited to, persons at-risk; the type of services the ICF/IID has the ability to provide in an emergency; and continuity of operations, including delegations of authority and succession plans. The research record locates this support at 42 CFR 483.475(a)(3), read with 42 CFR 483.475(a) (eCFR anchor p-483.475(a)(3)). - Under 42 CFR 483, the rule requires that the ICF/IID develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 483.475(d) (eCFR anchor p-483.475(d)). Keep the evidence boundary at these traced claims. They support a review of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish ICF/IID-specific federal condition of participation; individual support needs, staffing, transportation, guardians, state rules, and survey guidance require local planning. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 483.475(a)(3), read with 42 CFR 483.475(a) (eCFR anchor p-483.475(a)(3)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 483.475(d) (eCFR anchor p-483.475(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to 42 CFR 483.475(a)(3), read with 42 CFR 483.475(a) (eCFR anchor p-483.475(a)(3)); 42 CFR 483.475(d) (eCFR anchor p-483.475(d)) and to observable material such as business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [42 CFR 483.475 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-483.475) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 483.475 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-483.475 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Make ICF/IID emergency procedures support each client's needs,” DSE Security, https://update.dsesecurity.com/updates/make-icf-iid-emergency-procedures-support-each-client-s-needs/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make identity proofing recoverable, equitable, and evidence-based > Identity proofing establishes which real-world person is being enrolled; authentication later proves control of an authenticator. Select the needed assurance, protect proofing data, offer workable paths, and build redress for mistakes and fraud. - Canonical URL: https://update.dsesecurity.com/updates/make-identity-proofing-recoverable-equitable-evidence-based/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:37:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Identity proofing establishes which real-world person is being enrolled; authentication later proves control of an authenticator. Select the needed assurance, protect proofing data, offer workable paths, and build redress for mistakes and fraud. ## Potentially affected Customer and workforce enrollment, credential service providers, help desks, identity evidence, remote proofing, biometrics, fraud operations, accessibility, privacy, account recovery, and high-impact transactions. ## DSE recommendation Define the identity assurance needed for each service, map enrollment paths and failure cases, minimize retained evidence, test fraud and accessibility controls, and establish independent redress with auditable outcomes. ## Article ## Source facts: proofing and authentication answer different questions NIST Special Publication 800-63A-4 addresses identity proofing and enrollment for digital authentication. During proofing, an applicant presents evidence to a credential service provider so the provider can resolve the applicant to a unique identity, validate evidence, and verify that the applicant is associated with that identity. Authentication later establishes control of an authenticator. A strong authenticator does not correct a proofing process that enrolled an impostor. The publication defines three identity assurance levels. IAL1 does not require linking the applicant to a specific real-life identity. IAL2 and IAL3 apply progressively stronger requirements based on the service’s risk and need for confidence. The guideline supports remote and attended processes under stated requirements and includes controls for evidence, validation, verification, notification, records, privacy, security, fraud mitigation, and redress. NIST also emphasizes customer experience and equity. Proofing failures and inaccessible methods can prevent legitimate people from receiving a service. The provider must consider privacy risk, data minimization, notice and consent, protection of personal information, alternative methods where required, and mechanisms for resolving complaints or correcting errors. Biometrics, when used, are one part of a controlled process rather than an identity by themselves. ## DSE recommendation: choose assurance from the transaction’s harm For each service, describe what a falsely enrolled identity could authorize, learn, alter, receive, or deny. Consider harm to the applicant, other people, the organization, and external parties. Decide whether a real-world identity is necessary at all; collecting identity evidence without a defined need creates privacy and breach exposure. When proofing is required, document the target assurance level, eligible evidence, authoritative or credible sources, resolution rules, validation checks, verification methods, fraud controls, retention, and approval. Keep this decision separate from authenticator strength and federation choices so one strong layer does not conceal a weak one. ## DSE recommendation: design every enrollment path and failure path - Map the applicant journey. Cover normal remote and attended enrollment, low-connectivity conditions, name changes, limited documentation, accessibility needs, failed automated checks, duplicate records, and suspected fraud. - Minimize proofing data. Collect and retain only what the approved purpose requires. Restrict operator and system access, protect transmissions and stored records, and set defensible deletion schedules. - Separate duties for exceptions. High-risk overrides should require documented evidence and independent approval. An operator should not be able to invent, approve, and conceal an identity exception alone. - Notify through a validated channel. Give the subject a meaningful opportunity to detect an enrollment they did not initiate without exposing sensitive proofing details in the notice. - Build redress outside the failed mechanism. A person rejected because a document or biometric check failed needs a secure way to challenge the result that does not simply repeat the same test. ## DSE recommendation: measure fraud and legitimate-user harm together Test presentation attacks, forged evidence, stolen identity data, synthetic identities, insider misuse, replay, source unavailability, and account-linking errors. Also test accessibility, language, device limitations, demographic performance where legally and operationally appropriate, completion rates, abandonment, false rejection, appeal time, and correction accuracy. Protect detailed fraud signals from public disclosure that would enable evasion, but provide governance with enough evidence to compare paths. Review vendors for subcontractors, data locations, model and process changes, breach duties, evidence access, retention, and termination support. Include proofing service outages and supplier termination in continuity exercises so legitimate enrollment does not depend on an untested fallback. Record assurance decisions, test results, exception rates, complaints, redress outcomes, and approved improvements. Identity proofing is trustworthy only when it resists impersonation while giving legitimate people a safe, understandable, and correctable route to enrollment. ## Official references - National Institute of Standards and Technology, [SP 800-63A-4: Digital Identity Guidelines—Identity Proofing and Enrollment](https://csrc.nist.gov/pubs/sp/800/63/a/4/final), July 31, 2025; reviewed August 11, 2026. ## Primary reference - Name: NIST SP 800-63A-4: Identity Proofing and Enrollment - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/63/a/4/final - Source publication date: 2025-07-31 ## Citation and use Preferred citation: “Make identity proofing recoverable, equitable, and evidence-based,” DSE Security, https://update.dsesecurity.com/updates/make-identity-proofing-recoverable-equitable-evidence-based/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make incident response part of every NIST CSF 2.0 function > NIST SP 800-61 Rev. 3 integrates incident response across Govern, Identify, Protect, Detect, Respond, and Recover instead of isolating it as an emergency-only process. - Canonical URL: https://update.dsesecurity.com/updates/incident-response-across-csf-2-functions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:26:27+00:00 - Modified: 2026-07-19T21:26:27+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 2 minutes ## What you need to know NIST SP 800-61 Rev. 3 integrates incident response across Govern, Identify, Protect, Detect, Respond, and Recover instead of isolating it as an emergency-only process. ## Potentially affected Executives, incident leaders, IT and security teams, service owners, communications staff, continuity planners, counsel, and external providers with incident responsibilities. ## DSE recommendation Map incident readiness and improvement work to all six CSF functions, exercise the resulting handoffs, and feed evidence from incidents back into governance and safeguards. ## Article Incident response does not begin when an alert fires. Governance, asset knowledge, safeguards, detection design, recovery preparation, and continuous improvement determine whether a team can make sound decisions when facts are incomplete and time matters. ## The current NIST model Source fact: NIST SP 800-61 Rev. 3 supersedes Revision 2 and expresses incident-response recommendations as a NIST Cybersecurity Framework 2.0 Community Profile. NIST places incident response across all six CSF functions: Govern, Identify, Protect, Detect, Respond, and Recover. Source fact: NIST explains that integrating incident response into cybersecurity risk management can help organizations prepare, reduce the number and impact of incidents, and improve the efficiency and effectiveness of detection, response, and recovery. The publication supplies recommended outcomes and considerations; it is not a product-specific forensic runbook. ## Translate six functions into operating responsibilities DSE recommendation: build the response capability as a chain of evidence-backed responsibilities rather than a document owned only by IT. - Govern: define authority, risk decisions, policy, roles, external obligations, communications approval, evidence handling, and provider responsibilities. - Identify: know essential services, assets, data, identities, suppliers, dependencies, and the consequences of loss or manipulation. - Protect: operate safeguards that reduce likelihood or impact and preserve trusted administrative and recovery paths. - Detect: collect useful telemetry, establish analysis and escalation criteria, and validate that alerts reach accountable responders. - Respond: analyze, contain, eradicate, coordinate, communicate, preserve evidence, and make documented risk decisions. - Recover: restore prioritized services, validate integrity and function, communicate status, and manage reconstitution. ## Exercise the handoffs DSE recommendation: choose one credible scenario and walk it from detection through recovery. Record who can declare an incident, isolate a system, engage counsel or insurance, notify providers, approve public communication, accept temporary risk, and authorize restoration. Test alternate contacts and out-of-band communications instead of assuming the normal identity, email, phone, or ticketing service will remain available. After the exercise, assign each finding to a CSF function, an owner, a due date, and evidence of completion. Improvements may belong in governance, inventory, architecture, contracts, logging, training, recovery, or communications—not only in the response plan. ## Applicability and limits SP 800-61 Rev. 3 is risk-management guidance, not legal advice, a breach-notification schedule, or a substitute for sector-specific procedures. Forensic preservation, insurer notice, law-enforcement coordination, employment issues, privacy, and regulatory reporting require qualified review under the actual facts. Use NIST’s current online incident-response resources alongside the publication. ## Official reference [NIST SP 800-61 Rev. 3](https://csrc.nist.gov/pubs/sp/800/61/r3/final) — current incident-response recommendations aligned to CSF 2.0. ## Primary reference - Name: NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/61/r3/final - Source publication date: 2025-04-03 ## Citation and use Preferred citation: “Make incident response part of every NIST CSF 2.0 function,” DSE Security, https://update.dsesecurity.com/updates/incident-response-across-csf-2-functions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make memory safety a product roadmap, not a patching promise > Memory-safety flaws remain a major source of exploitable software defects. Buyers and builders should ask for an owned roadmap covering new code, legacy components, open-source dependencies, unsafe interfaces, compensating defenses, and measurable progress. - Canonical URL: https://update.dsesecurity.com/updates/memory-safety-product-roadmap-procurement/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-11T09:49:00+00:00 - Modified: 2026-08-11T14:12:10+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 4 minutes ## What you need to know Memory-safety flaws remain a major source of exploitable software defects. Buyers and builders should ask for an owned roadmap covering new code, legacy components, open-source dependencies, unsafe interfaces, compensating defenses, and measurable progress. ## Potentially affected Custom applications, commercial software, firmware, embedded devices, network appliances, security products, open-source components, and development pipelines using memory-unsafe languages. ## DSE recommendation Inventory memory-unsafe code and dependencies, require supplier roadmaps, favor memory-safe languages for new components, isolate unavoidable unsafe code, and measure defect reduction rather than accepting general assurances. ## Article ## Source fact: memory-safety defects are a persistent vulnerability class CISA, NSA, FBI, and international cybersecurity authorities describe memory-safety vulnerabilities as among the most prevalent classes of disclosed software vulnerability. Examples include buffer overflows, use-after-free errors, uninitialized memory, and double-free conditions. Successful exploitation can expose data, corrupt execution, crash a service, or allow unauthorized code execution. The joint guidance explains that memory-safe programming languages move much of the responsibility for valid memory access from individual developers to the language, compiler, or runtime. The agencies urge software manufacturers to create and publish memory-safety roadmaps rather than relying indefinitely on training, testing, and patches to compensate for the same recurring class of defect. NSA separately recommends using memory-safe languages when possible and applying code-hardening defenses when unsafe languages must remain. CISA’s analysis of critical open-source projects also emphasizes a dependency boundary: an application written in a memory-safe language may still rely on libraries or interfaces containing memory-unsafe code. ## Source fact: memory safety is not the same as complete software security A memory-safe language can prevent or sharply reduce specific memory-handling errors; it does not automatically prevent broken authorization, injection, insecure design, logic errors, weak cryptography, exposed secrets, or unsafe deployment. Native extensions, foreign-function interfaces, embedded libraries, and operating-system components may preserve memory-unsafe paths inside an otherwise safe product. A useful roadmap therefore describes boundaries and evidence. A claim that a product “uses Rust,” “uses a managed runtime,” or “has secure coding training” does not reveal which high-risk components remain unsafe, whether dependencies are covered, or whether new unsafe code is still being added. ## DSE recommendation: establish a defensible baseline For internally developed software, inventory languages by repository and component, including generated code, firmware, drivers, third-party libraries, native extensions, build tools, and transitive dependencies where evidence is available. Identify components exposed to untrusted network traffic, files, media, device input, or privilege boundaries. These are often better early targets than choosing projects only by line count. For purchased products, ask the manufacturer for a roadmap that identifies accountable leadership, scope, milestones, treatment of open-source and third-party dependencies, criteria for exceptions, and how customers will receive progress and residual-risk information. Protect legitimate proprietary details, but do not accept secrecy as a substitute for an engineering plan. ## DSE recommendation: divide the roadmap into four workstreams - New development. Define approved memory-safe languages and runtimes for new services, parsers, agents, and exposed components. Require an engineering exception before introducing new memory-unsafe code. - High-risk migration. Prioritize parsers, network-facing services, privileged components, update mechanisms, and code with a history of memory-safety defects. Rewrite bounded components through tested interfaces instead of promising an immediate whole-product rewrite. - Unsafe-code containment. Where migration is not yet practical, use supported compiler hardening, platform protections, sandboxing, least privilege, protocol isolation, fuzzing, static and dynamic analysis, and prompt vulnerability response. - Dependency governance. Track the language and maintenance status of critical dependencies, constrain unsafe interfaces, monitor vulnerabilities, and document when an upstream project—not the product team—controls remediation. ## DSE recommendation: measure outcomes that customers can verify Track the percentage of new security-sensitive components implemented without unsafe code; exposed components migrated or isolated; approved exceptions and their age; memory-safety vulnerabilities discovered in first-party and dependency code; time to remediate; fuzzing and analysis coverage; and roadmap milestones completed. Avoid rewarding raw lines rewritten if the highest-risk interfaces remain unchanged. Migration needs compatibility and rollback discipline. Define behavior, performance, resource, update, telemetry, and recovery acceptance tests before replacing a mature component. Preserve the ability to restore a supported version if the new implementation introduces operational risk. ## DSE recommendation: use procurement leverage without creating false certainty Add memory-safety questions to software and connected-device reviews. Ask whether the supplier has an executive-owned roadmap, which product layers remain memory-unsafe, how unsafe dependencies are identified, how researchers can report defects, and what support period applies to migrated and legacy components. Treat transparent residual risk as a sign of maturity. The objective is not a logo or an absolute claim that vulnerabilities are impossible. It is sustained reduction of an exploitable defect class, backed by architecture, milestones, testing, disclosure, and accountable ownership. ## Official references - [CISA and partners: The Case for Memory Safe Roadmaps](https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf) - [NSA: Software Memory Safety](https://www.nsa.gov/Press-Room/Digital-Media-Center/Document-Gallery/igphoto/2003210083/) - [CISA and partners: Exploring Memory Safety in Critical Open Source Projects](https://www.cisa.gov/sites/default/files/2024-06/joint-guidance-exploring-memory-safety-in-critical-open-source-projects-508c.pdf) - [CISA and FBI: Product Security Bad Practices update](https://www.cisa.gov/news-events/alerts/2025/01/17/cisa-and-fbi-release-updated-guidance-product-security-bad-practices) ## Primary reference - Name: CISA and international partners: The Case for Memory Safe Roadmaps - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf - Source publication date: 2023-12-06 ## Citation and use Preferred citation: “Make memory safety a product roadmap, not a patching promise,” DSE Security, https://update.dsesecurity.com/updates/memory-safety-product-roadmap-procurement/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make Microsoft Entra Connect replaceable before synchronization stops > Microsoft Entra Connect is replaceable only when its configuration, advanced exceptions, credentials, failover order, and validation evidence are ready. Staging mode lowers recovery time, but it is active-passive—not active-active. - Canonical URL: https://update.dsesecurity.com/updates/make-microsoft-entra-connect-replaceable-before-synchronization-stops/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 4 minutes ## What you need to know Microsoft Entra Connect is replaceable only when its configuration, advanced exceptions, credentials, failover order, and validation evidence are ready. Staging mode lowers recovery time, but it is active-passive—not active-active. ## Potentially affected Organizations using Microsoft Entra Connect Sync for hybrid identity, especially those relying on password hash synchronization, password writeback, Exchange hybrid writeback, custom filtering, or custom synchronization rules. ## DSE recommendation Choose a documented rebuild or staging-server strategy, export current configuration to protected storage, record settings the export omits, and rehearse a single-active-server failover with pending-export and password-sync validation. ## Article ## Source fact: staging mode is active-passive protection Microsoft’s current [staging-server and disaster-recovery guidance](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-staging-server) supports fault tolerance, testing configuration changes, and replacing an old server. A staging server imports and synchronizes data but does not export to Microsoft Entra ID or on-premises Active Directory. Password hash synchronization and password writeback also do not run while that server remains in staging mode. Microsoft is explicit: Entra Connect Sync supports active-passive high availability, not active-active, and only one server may actively export changes. A staging server still receives directory changes and maintains its own database. Microsoft recommends keeping its scheduler enabled and its synchronization recent. Before a role switch, run an initial cycle when rules or scope changed, confirm accidental-delete protection, and inspect pending exports. If the former active server is unreachable, it must be shut down or isolated so it cannot unexpectedly resume exporting. ## Source fact: password services require separate failover attention Disabling staging mode starts exports, password synchronization, and password writeback. Microsoft warns that password hash sync resumes from the staging server’s last recorded watermark. A server left staged for an extended period can have a large backlog; new password changes might not work in Microsoft Entra ID until catch-up completes. Microsoft advises monitoring the application event log during catch-up and not restarting synchronization services, because a restart can make processing resume from an earlier watermark. Password writeback can also be disrupted if two servers are active. ## Source fact: rebuild is supported, but configuration must survive Microsoft describes rebuild-on-demand as a viable disaster-recovery model. The sync engine can rebuild its object state from Active Directory and Microsoft Entra ID, using the sourceAnchor to join existing on-premises and cloud objects. What must be preserved is the applied configuration, including filters and synchronization rules. The companion [configuration import and export guidance](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-import-export-config) says wizard changes create time-stamped JSON files under the Entra Connect program-data location; changes made with PowerShell, Synchronization Service Manager, or Synchronization Rules Editor require an on-demand export. The exported JSON must not be hand-edited. Import deliberately starts the new server in staging mode, but it is not a complete machine clone. Microsoft lists settings that may require manual reapplication, including device writeback, selected object types or attributes, custom run profiles, provisioning hierarchy, and parts of federated sign-in configuration. Post-installation comparison of the imported settings with a new export is an essential verification step. ## DSE recommendation: choose the recovery model from business tolerance DSE recommends an explicit decision between rebuild-on-demand and a warm staging server. Base it on tolerated delay in directory changes, password synchronization, and real-time writeback—not simply server uptime. A straightforward environment with a tested configuration package may accept rebuild time. Complex filters, rules, multiple forests, writeback, or a short recovery objective favor a maintained staging server. In either model, treat the Windows host as replaceable and the configuration plus procedure as the durable asset. Keep a protected copy of the latest supported export away from the sync server. Maintain a separate register of Entra Connect version, sourceAnchor choice, forests and connectors, sign-in method, OU and attribute scope, custom rules and precedence, writeback features, scheduler state, service and connector account requirements, network dependencies, and every setting the export does not restore. ## DSE recommendation: rehearse this controlled handoff - Prepare. Patch the candidate server to a supported build, update configuration and advanced settings, enable its scheduler, and confirm a recent successful import and synchronization. - Inspect. Run the required full or initial cycle after scope or rule changes. Review pending adds, updates, and deletes; stop if volume or direction is unexplained. - Quiesce. Put the reachable primary into staging mode. If it failed, positively isolate it from outbound access and record how reactivation is prevented. - Promote. Disable staging mode only on the approved replacement. Verify exports, password hash sync progress, writeback where used, Entra Connect Health, and representative identity changes. - Stabilize. Keep the old server isolated or staged, document the new role assignment, export the resulting configuration, and investigate every difference from the intended build. This DSE playbook is an operational interpretation of Microsoft’s supported models. It does not replace environment-specific change approval. Its purpose is to prove that Entra Connect can be replaced without creating two writers or exporting an unreviewed directory change. ## Official sources - [Microsoft: Entra Connect staging server and disaster recovery](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-staging-server) - [Microsoft: Import and export Entra Connect configuration settings](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-import-export-config) - [Microsoft: Customize an Entra Connect installation](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-install-custom) ## Primary reference - Name: Microsoft Entra Connect: Staging server and disaster recovery - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-staging-server - Source publication date: 2026-04-02 ## Citation and use Preferred citation: “Make Microsoft Entra Connect replaceable before synchronization stops,” DSE Security, https://update.dsesecurity.com/updates/make-microsoft-entra-connect-replaceable-before-synchronization-stops/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make prohibited-items screening a written facility decision—not a guard improvisation > A screening point cannot be consistent when the prohibited list, lawful exceptions, notification, secondary screening, refusal options, evidence handling, and emergency escalation exist only in an officer’s memory. - Canonical URL: https://update.dsesecurity.com/updates/make-prohibited-items-screening-written-facility-decision/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:16:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Access Control, Business Continuity - Reading time: 3 minutes ## What you need to know A screening point cannot be consistent when the prohibited list, lawful exceptions, notification, secondary screening, refusal options, evidence handling, and emergency escalation exist only in an officer’s memory. ## Potentially affected Public entrances, employee and visitor screening, security officers, reception, event access, mail and delivery checkpoints, metal detectors and X-ray stations, posted notices, exception approvals, and incident reporting. ## DSE recommendation Approve a facility-specific prohibited and controlled-items policy, align it with applicable law, communicate it before arrival, train screeners on one response sequence, document exceptions, and test both the equipment and human decisions. ## Article ## Source facts: a prohibited-items program exists beyond the checkpoint The Interagency Security Committee’s May 2022 standard [Items Prohibited in Federal Facilities](https://www.cisa.gov/sites/default/files/2022-11/052622_Items_Prohibited_in_Federal_Facilities_508c_FINAL.pdf) establishes a federal baseline for dangerous, unlawful, or otherwise restricted items and procedures for controlling them. It is intended to increase consistency and reduce confusion at screening locations. The document applies its federal prohibitions whether or not a facility operates a screening checkpoint. The standard distinguishes prohibited items from controlled items that may have a legitimate, lawful facility purpose but require advance notification and approval. It assigns the responsible authority a role in customizing and implementing the baseline for mission needs, exceptions, and exemptions while following applicable law. This is important operationally: discovering an item and deciding whether it is authorized are separate actions. The related ISC [Facility Access Control](https://www.cisa.gov/sites/default/files/2022-11/Facility%20Access%20Control%20-%20An%20Interagency%20Security%20Committee%20Best%20Practice.pdf) best practice describes electronic, visual, and manual screening of people, vehicles, packages, and containers. It says screening personnel need established initial and follow-up procedures, documented training, and regular testing. Its federal scope and legal authorities do not automatically govern a private facility; organizations must obtain their own legal, labor, contractual, and policy review. ## DSE recommendation: decide policy before an object reaches the tray Create an owner-approved operating standard that answers what a screener must do without forcing an improvised legal or safety decision at a crowded entrance. - Define the authority and scope. Identify the facility owner, policy approver, security operator, legal reviewer, and emergency authority. State which entrances, populations, events, vehicles, bags, deliveries, and non-screened doors are covered. Do not borrow federal authority or terminology without confirming it applies. - Publish usable categories. Separate prohibited, controlled, exempt, and ordinary items. For controlled items, document who can approve them, required advance notice, identity and purpose checks, movement restrictions, storage, escort, and end-of-visit reconciliation. - Give notice before screening. Place clear, accessible notices where a person can choose not to enter and provide the same information in invitations, visitor instructions, event pages, and contractor onboarding. Include whom to contact about medical, religious, accessibility, law-enforcement, or business-purpose exceptions without forcing disclosure in public. - Design one decision path. Define initial indication, respectful rescreening, supervisor review, approved exception lookup, voluntary withdrawal or return-to-vehicle option where permitted, denial of entry, emergency notification, and incident documentation. Specify when staff should stop handling an item and create distance. - Protect people at the station. Plan queue capacity, escape and duress options, responder access, safe placement of discovered property, communications, privacy during secondary screening, and a method for summoning a supervisor without escalating the interaction. - Control records and property. Decide what screeners document, who may take custody, whether the organization has lawful authority to retain an item, how evidence is preserved for law enforcement, and how ordinary surrendered property is identified and disposed of. Never let an improvised “confiscation box” become an untracked hazard. Train with scenarios, not only equipment buttons: an employee with a newly prohibited item, a contractor carrying a controlled tool, a visitor requesting an accommodation, an off-duty officer, a credible dangerous object, a refusal to screen, a false equipment alarm, and an overwhelmed queue. Test detection equipment according to its instructions, but separately observe whether the human response follows policy. Audit exceptions and denials for consistency, not quotas. Review recurring items, unclear notices, abandoned property, equipment downtime, unauthorized bypass doors, supervisor response time, complaints, and emergency escalations. After a policy change, brief every entrance and shift before enforcement begins. A high-quality screening program is predictable: people receive notice, screeners know their limits, legitimate exceptions are controlled, and dangerous uncertainty moves quickly to the right authority. ## Official references - Cybersecurity and Infrastructure Security Agency, Interagency Security Committee, [Items Prohibited in Federal Facilities: An ISC Standard](https://www.cisa.gov/sites/default/files/2022-11/052622_Items_Prohibited_in_Federal_Facilities_508c_FINAL.pdf), May 26, 2022. - CISA Interagency Security Committee, [Facility Access Control: An ISC Best Practice](https://www.cisa.gov/sites/default/files/2022-11/Facility%20Access%20Control%20-%20An%20Interagency%20Security%20Committee%20Best%20Practice.pdf). ## Primary reference - Name: CISA Interagency Security Committee: Items Prohibited in Federal Facilities - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/2022-11/052622_Items_Prohibited_in_Federal_Facilities_508c_FINAL.pdf - Source publication date: 2022-05-26 ## Citation and use Preferred citation: “Make prohibited-items screening a written facility decision—not a guard improvisation,” DSE Security, https://update.dsesecurity.com/updates/make-prohibited-items-screening-written-facility-decision/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make regulated maritime-facility owners accountable for approved-plan operation and security coordination > Use 33 CFR 105.200 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/make-regulated-maritime-facility-owners-accountable-for-approved-plan-operation-and-security-coordin/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:22+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.200 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.200 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Make regulated maritime-facility owners accountable for approved-plan operation and security coordination. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.200 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.200) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that for each facility, the facility owner or operator ensure that adequate coordination of security issues takes place between the facility and vessels that call on it, including the execution of a Declaration of Security (DoS) as required by this part. The research record locates this support at 33 CFR 105.200(b)(8), read with 33 CFR 105.200(b) (eCFR anchor p-105.200(b)(8)). - Under 33 CFR 105, the rule requires that for each facility, the facility owner or operator ensure that a Facility Security Assessment (FSA) is conducted. The research record locates this support at 33 CFR 105.200(b)(3), read with 33 CFR 105.200(b) (eCFR anchor p-105.200(b)(3)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths only where the source and recorded environment align. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.200(b)(8), read with 33 CFR 105.200(b) (eCFR anchor p-105.200(b)(8)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.200(b)(3), read with 33 CFR 105.200(b) (eCFR anchor p-105.200(b)(3)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from 33 CFR 105.200(b)(8), read with 33 CFR 105.200(b) (eCFR anchor p-105.200(b)(8)); 33 CFR 105.200(b)(3), read with 33 CFR 105.200(b) (eCFR anchor p-105.200(b)(3)) through asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [33 CFR 105.200 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.200) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.200 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.200 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Make regulated maritime-facility owners accountable for approved-plan operation and security coordination,” DSE Security, https://update.dsesecurity.com/updates/make-regulated-maritime-facility-owners-accountable-for-approved-plan-operation-and-security-coordin/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make risk assessment inputs and assumptions reviewable > A risk assessment supports decisions only when its scope, threat and vulnerability inputs, likelihood and impact reasoning, uncertainty, assumptions, ownership, and review triggers are visible. - Canonical URL: https://update.dsesecurity.com/updates/risk-assessment-reviewable-inputs-assumptions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:33:53+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know A risk assessment supports decisions only when its scope, threat and vulnerability inputs, likelihood and impact reasoning, uncertainty, assumptions, ownership, and review triggers are visible. ## Potentially affected Organizations using cybersecurity risk assessments to choose controls, prioritize work, accept residual risk, inform budgets, or communicate with leadership and customers. ## DSE recommendation Record the decision, scope, evidence, method, uncertainty, assumptions, risk owner, response, residual condition, and reassessment triggers so another reviewer can understand and challenge the result. ## Article Bottom line: a color or score is not a durable risk assessment unless a reviewer can see what decision it supports, what was in scope, which evidence and assumptions drove it, how uncertainty was handled, who owns the response, and what change will trigger another look. ## Source fact: what NIST provides [NIST SP 800-30 Revision 1](https://csrc.nist.gov/pubs/sp/800/30/r1/final) provides guidance for conducting risk assessments for federal information systems and organizations and amplifies NIST SP 800-39. NIST places assessments at three tiers of the risk-management hierarchy and describes their role in providing leaders with information for choosing responses to identified risks. The publication supports treating assessment as an input to a decision. It does not turn a method, matrix, or numerical output into a decision on its own. ## What the source does not establish SP 800-30 does not predict a future event with certainty, prescribe one universal scoring scale, or establish that two analysts will reach identical results. A high level of formatting precision can conceal weak evidence or untested assumptions. A risk register entry can also become stale when systems, exposures, threats, dependencies, or business consequences change. The federal context does not automatically create a compliance obligation for every organization. The method should be adapted consciously to the decision, authority, sector, contract, and available evidence. ## Applicability questions - What decision, risk owner, system or business objective, and time horizon does the assessment support? - Which assets, data, services, people, facilities, suppliers, and dependencies are included or excluded? - What evidence supports the threat, vulnerability, existing-control, likelihood, and impact judgments? - Which assumptions and uncertainties could materially change the result? - What response, acceptance authority, due date, and reassessment trigger follow from the conclusion? ## DSE recommendation: write the decision record The following steps are DSE recommendations based on the cited source. - Begin with the business or mission decision and accountable risk owner. Set the scope, time horizon, criteria, and intended audience before scoring. - Identify important assets, services, data flows, people, dependencies, threat events, vulnerabilities, and existing controls. Link each material input to a source and review date. - Define the likelihood and impact method in plain language. Separate observed facts, estimates, assumptions, and unknowns. - Consider business, safety, operational, legal, customer, privacy, and recovery consequences appropriate to the scope without converting unverified possibilities into facts. - Record response options, chosen action, owner, resources, due date, residual risk, acceptance authority, and dissent or unresolved uncertainty. - Define event- and time-based triggers such as architecture change, new exposure, incident, supplier change, control failure, or material threat information. ## Verification and evidence Select a material risk and trace every significant input to evidence, owner, and date. Reperform the reasoning with a second reviewer, note sensitivity to changed assumptions, confirm the response and acceptance authority, and verify that reassessment triggers are connected to operational change or monitoring processes. ## Official references - [NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments](https://csrc.nist.gov/pubs/sp/800/30/r1/final) — National Institute of Standards and Technology; finalized September 17, 2012 - [NIST SP 800-39 — Managing Information Security Risk](https://csrc.nist.gov/pubs/sp/800/39/final) — National Institute of Standards and Technology ## Primary reference - Name: NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/30/r1/final - Source publication date: 2012-09-17 ## Citation and use Preferred citation: “Make risk assessment inputs and assumptions reviewable,” DSE Security, https://update.dsesecurity.com/updates/risk-assessment-reviewable-inputs-assumptions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make software verification a layered test plan, not a single scanner > NIST's minimum verification guidance describes multiple complementary techniques. Select, scope, and retain evidence from the techniques that address design, code, dependencies, and running behavior. - Canonical URL: https://update.dsesecurity.com/updates/layered-software-verification-plan/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:07+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know NIST's minimum verification guidance describes multiple complementary techniques. Select, scope, and retain evidence from the techniques that address design, code, dependencies, and running behavior. ## Potentially affected Software producers, internal development teams, integrators, and purchasers who need evidence that security-relevant verification occurred before release. ## DSE recommendation Create a versioned verification plan that combines design review, automated and structural tests, secret and dependency checks, fuzzing or dynamic techniques where applicable, and accountable findings disposition. ## Article Bottom line: no single scanner observes every useful class of software defect. Verification should combine techniques that examine design, source, built behavior, historical failures, included components, and relevant application interfaces, with the results tied to a specific release. ## Source fact: what NIST recommends [NIST IR 8397](https://csrc.nist.gov/pubs/ir/8397/final) describes eleven broadly applicable software verification techniques. The publication includes threat modeling, automated testing, static code scanning, tools for possible hardcoded secrets, built-in checks and protections, black-box tests, code-based structural tests, historical tests, fuzzing, web application scanning where applicable, and attention to included code such as libraries, packages, and services. NIST explicitly states that the listed techniques do not address the totality of software verification. They are presented as minimum recommendations, not as proof that software is free of defects. ## What the source does not establish The document does not prescribe one product, coverage threshold, severity gate, or test frequency. Running all eleven technique categories mechanically does not establish useful depth, correct configuration, complete scope, or responsible findings handling. A clean report may reflect a narrow test or a tool limitation. Applicability depends on language, architecture, threat model, exposed interfaces, safety and business impact, third-party components, release cadence, and whether the organization controls source or receives only a binary or hosted service. ## Applicability questions - Which security properties and abuse cases must be verified for this release? - Which techniques can observe design, code, dependency, build, and runtime failure modes? - What code, generated artifacts, infrastructure definitions, and external services are in scope? - What blocks release, who may accept residual risk, and how long can an exception remain? - Can each result be reproduced against the same revision and test environment? ## DSE recommendation: design complementary coverage The following steps are DSE recommendations based on the cited source. - Start with the threat model and intended use. Define the properties, boundaries, misuse cases, and dependencies that verification must address. - Select multiple techniques because they answer different questions. Record why each applies, its scope, configuration, known blind spots, and expected evidence. - Pin every result to source revision, dependency state, build artifact, tool and rules version, test data, environment, and timestamp. - Triage findings through an owned process. Confirm material issues, record remediation or bounded acceptance, retest fixes, and prevent silent suppression. - Turn escaped defects into regression tests when practical. Review recurring findings for a design, training, dependency, or pipeline cause. - For acquired software, request verification evidence at a useful level without treating a vendor assertion or one scan report as a warranty. ## Verification and evidence Choose a recent release and produce the approved verification plan, threat model, tool configurations, raw and normalized results, findings decisions, retest evidence, dependency record, and release approval. Confirm that another qualified reviewer can connect every artifact to the deployed version. ## Official references - [NIST IR 8397 — Guidelines on Minimum Standards for Developer Verification of Software](https://csrc.nist.gov/pubs/ir/8397/final) — National Institute of Standards and Technology; finalized October 6, 2021 - [NIST SP 800-218 — Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) — National Institute of Standards and Technology ## Primary reference - Name: NIST IR 8397 — Guidelines on Minimum Standards for Developer Verification of Software - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/ir/8397/final - Source publication date: 2021-10-06 ## Citation and use Preferred citation: “Make software verification a layered test plan, not a single scanner,” DSE Security, https://update.dsesecurity.com/updates/layered-software-verification-plan/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make the fire-prevention plan name hazards, controls, and owners > Use 29 CFR 1910.39 - Fire prevention plans to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/make-the-fire-prevention-plan-name-hazards-controls-and-owners/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:33+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.39 - Fire prevention plans to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.39 - Fire prevention plans ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Make the fire-prevention plan name hazards, controls, and owners. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.39 – Fire prevention plans](https://www.ecfr.gov/current/title-29/section-1910.39) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, the rule requires that a fire prevention plan include the name or job title of employees responsible for maintaining equipment to prevent or control sources of ignition or fires. The research record locates this support at 29 CFR 1910.39(c)(4), read with 29 CFR 1910.39(c) (eCFR anchor p-1910.39(c)(4)). - Under 29 CFR 1910, the rule requires that a fire prevention plan include the name or job title of employees responsible for the control of fuel source hazards. The research record locates this support at 29 CFR 1910.39(c)(5), read with 29 CFR 1910.39(c) (eCFR anchor p-1910.39(c)(5)). Only the traced statements above are asserted as source facts. Apply the review to essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives after confirming that the source and deployed context match. ## What the source does not establish Federal workplace rule with conditional applicability; it is not a substitute for fire code, emergency action planning, or site-specific engineering. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.39(c)(4), read with 29 CFR 1910.39(c) (eCFR anchor p-1910.39(c)(4)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.39(c)(5), read with 29 CFR 1910.39(c) (eCFR anchor p-1910.39(c)(5)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from 29 CFR 1910.39(c)(4), read with 29 CFR 1910.39(c) (eCFR anchor p-1910.39(c)(4)); 29 CFR 1910.39(c)(5), read with 29 CFR 1910.39(c) (eCFR anchor p-1910.39(c)(5)) through business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [29 CFR 1910.39 – Fire prevention plans](https://www.ecfr.gov/current/title-29/section-1910.39) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.39 - Fire prevention plans - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.39 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Make the fire-prevention plan name hazards, controls, and owners,” DSE Security, https://update.dsesecurity.com/updates/make-the-fire-prevention-plan-name-hazards-controls-and-owners/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make video analytics earn production trust > A demo proves that an analytic can work. Acceptance testing must show how the complete camera, scene, network, model, rules, operators, and response workflow behave in the conditions where the organization will rely on them. - Canonical URL: https://update.dsesecurity.com/updates/make-video-analytics-earn-production-trust/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Video Surveillance - Reading time: 4 minutes ## What you need to know A demo proves that an analytic can work. Acceptance testing must show how the complete camera, scene, network, model, rules, operators, and response workflow behave in the conditions where the organization will rely on them. ## Potentially affected Organizations deploying motion classification, line crossing, intrusion, loitering, object, people, vehicle, face, license-plate, or other video analytics. ## DSE recommendation Define scenario-specific acceptance criteria, capture labeled field trials across real operating conditions, test the human response path, document limitations, and require retesting after material change. ## Article ## Source fact: test in the intended context The [NIST AI Risk Management Framework 1.0](https://doi.org/10.6028/NIST.AI.100-1) says AI systems should be tested before deployment and regularly in operation. Its Measure function calls for objective, repeatable, documented test, evaluation, verification, and validation processes; performance should be demonstrated under conditions similar to the deployment setting, and limits on generalizing beyond tested conditions should be documented. NIST also calls for production monitoring and management of incidents and errors. NIST’s [video analytics program](https://www.nist.gov/programs-projects/video-analytics) emphasizes defined performance metrics, real-world datasets, and systematic evaluation. These sources do not prescribe one universal pass rate for a commercial security analytic. The acceptable balance of missed events, nuisance alerts, latency, privacy, and operator workload is a risk decision for the specific use. ## DSE recommendation: write the decision before the test Define what the analytic is allowed to do. Is it an operator cue, a search aid, a maintenance signal, or an input to an automated action? Identify the protected area, relevant hours, subjects or objects, response owner, and consequence of a false positive and false negative. An analytic that helps a person search recorded video is not automatically suitable for denying entry, dispatching responders, or making an employment decision. Create a scenario matrix instead of a single accuracy target. Include expected positives, expected negatives, ambiguous cases, and deliberately out-of-scope cases. Define the unit of measurement: event, track, person, vehicle, frame, or time interval. Otherwise, two impressive percentages may describe completely different tests. ## Build ground truth the system did not create Use authorized, safety-reviewed field trials and an independent record of what actually happened. A person who did not tune the analytic should label the trial when practical. Record camera model and firmware, analytic and model version, lens and view, resolution, frame rate, compression, shutter and exposure behavior, zones, thresholds, server resources, network path, date, time, weather, and lighting. Preserve the configuration with the results. - Test dawn, daylight, dusk, darkness, artificial light, glare, headlamps, shadows, and wide-dynamic-range scenes that occur at the site. - Include rain, snow, fog, wind-driven movement, seasonal foliage, insects, dirty or wet covers, and camera vibration where relevant. - Vary distance, speed, direction, dwell time, occlusion, crowding, clothing, carried objects, vehicle types, and legitimate activity near rule boundaries. - Exercise bandwidth constraint, dropped video, recorder or analytic-server restart, lost camera, delayed notification, and recovery. ## Report errors operators can understand For every scenario, count the relevant true detections, misses, nuisance detections, duplicates, and alerts with incorrect classification. Measure time from the real event to operator presentation and then to acknowledgment or action. Report the denominator, test duration, scene, and uncertainty with every rate. Do not combine a quiet indoor test and a busy outdoor test into one number that hides failure. Review error clusters, not only the average. A low overall nuisance rate can conceal repeated alerts every time headlights sweep a gate; a good daytime result can conceal unusable night performance. If people are identified or classified, involve privacy, legal, security, and affected operational stakeholders, and test representative conditions without claiming that a small local trial proves performance for every population. ## Test the human and operational system Send alerts through the production path. Confirm the correct camera and pre-event context appear, the message arrives on the staffed console or device, the operator can distinguish live from recorded material, and the response procedure is available. Measure alert bursts and simultaneous events. Have operators explain the alert and record disposition; an accurate model that overwhelms the desk is not an accepted system. ## Commission with bounded claims The acceptance record should state the tested conditions, passed and failed scenarios, known blind spots, required camera and rule settings, operator responsibilities, privacy controls, residual risk, approver, and retest triggers. Material camera movement, lighting change, construction, foliage, firmware, model, threshold, server, or integration changes should reopen the affected tests. Monitor field outcomes and maintain a simple path for users to report misses and nuisance alerts. DSE recommends a pilot or limited-use decision when evidence is incomplete. Acceptance means the system met documented criteria in defined conditions—not that an AI analytic is infallible. ## Official sources - [NIST AI 100-1, AI Risk Management Framework 1.0](https://doi.org/10.6028/NIST.AI.100-1) - [NIST AI RMF Core: Measure and Manage](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) - [NIST Video Analytics program](https://www.nist.gov/programs-projects/video-analytics) - [NIST: Test scenarios for AI must reflect real-world uses](https://www.nist.gov/news-events/news/2022/02/nist-led-panel-assesses-test-and-evaluation-industrial-ai-risk-awareness) ## Primary reference - Name: NIST AI Risk Management Framework 1.0 - Authority: Digital Object Identifier - URL: https://doi.org/10.6028/NIST.AI.100-1 - Source publication date: 2023-01-26 ## Citation and use Preferred citation: “Make video analytics earn production trust,” DSE Security, https://update.dsesecurity.com/updates/make-video-analytics-earn-production-trust/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Make visitor access a sponsored, time-bounded, fully closed loop > A visitor badge is only one moment in a longer control. Tie every non-public visit to an approved sponsor, defined destination and time window, appropriate escort, visible credential, confirmed departure, and reviewable record. - Canonical URL: https://update.dsesecurity.com/updates/make-visitor-access-sponsored-time-bounded-closed-loop/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:17:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control - Reading time: 4 minutes ## What you need to know A visitor badge is only one moment in a longer control. Tie every non-public visit to an approved sponsor, defined destination and time window, appropriate escort, visible credential, confirmed departure, and reviewable record. ## Potentially affected Reception and security desks, visitor-management procedures, temporary badges, employee sponsors, contractors and vendors, delivery entrances, controlled interior areas, physical visitor logs, and access-control operators. ## DSE recommendation Define a single visitor lifecycle covering preregistration, identity verification, authorization, zone and time limits, escort rules, badge return, overdue escalation, record review, and privacy-conscious retention. ## Article ## Source facts: visitor access extends beyond identity at the entrance The Interagency Security Committee’s December 2020 [Facility Access Control](https://www.cisa.gov/sites/default/files/2022-11/Facility%20Access%20Control%20-%20An%20Interagency%20Security%20Committee%20Best%20Practice.pdf) guide addresses the full access process for people entering federally occupied space: arrival, identity and authorization decisions, screening, movement, escort, and the first authentication point into non-public space. It treats visitor processing as part of the facility’s risk-based operating model, not a standalone badge-printing task. The guide describes alternate access procedures for a person who cannot present the ordinary accepted identification, including a prearranged visit in which the security post contacts the agency point of contact for access and escort. It states that the visit sponsor, designee, or dedicated escort is responsible for the individual in federally occupied space. Escort procedures and ratios should reflect the type of visitor, associated risk, and operational requirements. The ISC presents multiple escort levels, ranging from minimal practices for authorized personnel without local access through continuous, high-positive control for higher-risk circumstances. The chosen level drives proximity, visual or other control, briefing, and monitoring expectations. This is federal best-practice guidance; it does not prescribe a private facility’s identity documents, badge color, escort ratio, retention period, or authority. Applicable law, labor rules, accessibility needs, contracts, privacy obligations, and local facility risk govern the commercial workflow. ## DSE recommendation: close every visit from request through departure Build one workflow for guests, interview candidates, delivery personnel, technicians, auditors, temporary workers, and after-hours vendors. Different visitor classes can have different controls, but none should rely on the receptionist guessing what “normal” means. - Require a responsible sponsor. Capture the sponsor, visitor identity information actually needed, organization, purpose, date and expected times, entrance, destination, approved zones, escort requirement, equipment or material being brought in, and any advance screening or accommodation. The sponsor should affirm the request, not merely appear in a directory. - Verify the visit at arrival. Match the person to the approved request using the organization’s accepted method. Resolve misspellings, substitutions, early arrivals, groups, and unknown sponsors through a documented exception path. Front-desk pressure should not silently turn an unapproved visit into an approved one. - Issue the least-capable credential. Make the badge visibly temporary and configure only the locations and hours needed. Do not copy an employee’s access profile for convenience. Where no electronic credential is needed, use a clearly recognizable visitor badge and control the movement procedurally. - Make escort ownership explicit. State who receives the visitor, when custody transfers, where unescorted movement is allowed, and what happens if the host cannot be reached. Include restrooms, cafeterias, smoking areas, loading docks, evacuation, and emergency separation rather than assuming the visitor will remain beside the sponsor. - Close out the visit. Record departure, recover or disable the credential, reconcile loaned keys or equipment, and alert on badges still active after the approved window. A checkout kiosk is useful only if someone investigates the exceptions. - Review the record. Look for recurring overdue visits, missing badges, repeated sponsor exceptions, entries without departures, unusual after-hours activity, and attempts to reach unapproved areas. Route anomalies to a named owner and document disposition. Minimize personal data. Define which fields serve an operational or legal need, who may see them, how long they are retained, how paper logs are protected from casual viewing, and how records are disposed of. Avoid collecting identification numbers or copies merely because the software offers a field. Test the process with ordinary and difficult scenarios: a walk-in executive guest, a substitute technician, a large group, an after-hours contractor, a visitor whose sponsor is absent, a lost badge, an evacuation, and a person who declines the stated verification step. Measure time to resolve exceptions, overdue badge closure, unreturned credentials, sponsor response, and record completeness. The result should be welcoming without being vague: every non-public visitor has an owner, a purpose, a boundary, and a verified end. ## Official references - Cybersecurity and Infrastructure Security Agency, Interagency Security Committee, [Facility Access Control: An ISC Best Practice](https://www.cisa.gov/sites/default/files/2022-11/Facility%20Access%20Control%20-%20An%20Interagency%20Security%20Committee%20Best%20Practice.pdf), December 17, 2020. - CISA, [Interagency Security Committee policies, standards, and best practices](https://www.cisa.gov/about-interagency-security-committee). ## Primary reference - Name: CISA Interagency Security Committee: Facility Access Control—An ISC Best Practice - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/2022-11/Facility%20Access%20Control%20-%20An%20Interagency%20Security%20Committee%20Best%20Practice.pdf - Source publication date: 2020-12-17 ## Citation and use Preferred citation: “Make visitor access a sponsored, time-bounded, fully closed loop,” DSE Security, https://update.dsesecurity.com/updates/make-visitor-access-sponsored-time-bounded-closed-loop/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Manage Defender for Identity sensor status, health, updates, and proxy settings together > Use Manage and update Microsoft Defender for Identity sensors to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/manage-sensor-status-health-updates-and-proxy-settings-together/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:49+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Manage and update Microsoft Defender for Identity sensors to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Manage and update Microsoft Defender for Identity sensors ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Manage Defender for Identity sensor status, health, updates, and proxy settings together. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Manage and update Microsoft Defender for Identity sensors](https://learn.microsoft.com/en-us/defender-for-identity/sensor-settings) from Microsoft supports the following bounded statements: - The Sensors experience covers sensor status and health, sensor details, updates for v2.x and v3.x, and proxy configuration. The research record locates this support at Opening scope statement. - A sensor details pane exposes health information and provides paths to manage configuration or reopen closed health issues. The research record locates this support at Sensor details description. The source support ends with the statements listed above. Use them to examine Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Portal status and update controls require documented permissions and do not replace server monitoring, change records, or rollback planning. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening scope statement, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sensor details description, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening scope statement; Sensor details description. Favor sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Manage and update Microsoft Defender for Identity sensors](https://learn.microsoft.com/en-us/defender-for-identity/sensor-settings) — Microsoft ## Primary reference - Name: Manage and update Microsoft Defender for Identity sensors - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/sensor-settings - Source publication date: 2026-07-15 ## Citation and use Preferred citation: “Manage Defender for Identity sensor status, health, updates, and proxy settings together,” DSE Security, https://update.dsesecurity.com/updates/manage-sensor-status-health-updates-and-proxy-settings-together/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Manage fire-protection impairments before the valve closes > Planned maintenance and unexpected failures can leave a protected area without its normal water-based fire protection. Assign an impairment coordinator, assess the increased risk, authorize safeguards, notify the right parties, tag the condition, and prove restoration. - Canonical URL: https://update.dsesecurity.com/updates/manage-fire-protection-impairments-before-valve-closes/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:12:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know Planned maintenance and unexpected failures can leave a protected area without its normal water-based fire protection. Assign an impairment coordinator, assess the increased risk, authorize safeguards, notify the right parties, tag the condition, and prove restoration. ## Potentially affected Sprinklers, standpipes, fire pumps, water supplies, private fire mains, valves, water tanks, supervisory service, affected occupants and operations, contractors, insurers, alarm companies, fire departments, and authorities having jurisdiction. ## DSE recommendation Use one impairment permit for planned and emergency outages that records scope, duration, risk, authorization, notifications, approved temporary safeguards, tags, work status, restoration testing, and closeout notifications. ## Article ## Source facts: an impairment is a managed loss of protection [NFPA 25, 2026 edition](https://link.nfpa.org/all-publications/25/2026), establishes requirements for inspection, testing, and maintenance of water-based fire-protection systems. Its impairment provisions address systems or portions of systems taken out of service, including planned work and emergency conditions such as interrupted water supply, frozen or ruptured piping, and equipment failure. The standard assigns coordination responsibilities for impairments. For a preplanned impairment, the extent and expected duration are determined, affected areas are inspected, increased risk is evaluated, and recommendations are submitted to the owner or designated representative. Required parties can include the fire department, alarm company, insurance carrier, supervisors in affected areas, property representatives, and authorities having jurisdiction. A tagging system identifies the impairment. Depending on duration, risk, and applicable requirements, measures can include evacuation, an approved fire watch, a temporary water supply, or an approved program to eliminate ignition sources and limit available fuel. Restoration includes required inspection and testing, confirming the system is operational, notifying parties that protection is restored, and removing the impairment tag. The adopted NFPA 25 edition, fire code, insurer, and authority having jurisdiction control the actual process. ## DSE recommendation: operate one permit from authorization to restoration Name an impairment coordinator and alternates in advance. Give them authority to pause work when safeguards, notifications, competent personnel, or restoration resources are not ready. A service contractor may perform the work, but the property still needs an owner who understands the operational consequence. - Define the impaired boundary. Identify the exact system, valve, zone, floor, riser, hazard, water supply, supervisory path, and area that will lose protection. Mark the boundary on current drawings and confirm it in the field. Do not describe a multi-floor shutdown as “sprinkler work.” - Assess the changed risk. Record occupancy, people present, hazardous processes, combustible loading, hot work, temporary construction, blocked access, alternate protection, fire-department connection, weather, and the consequences of delay. Establish the expected start, duration, stop conditions, and escalation time. - Authorize safeguards before isolation. Obtain the decisions required from the owner and applicable authorities. Define fire watch or evacuation scope, ignition-source controls, temporary supply, work limits, patrol records, communication, emergency notification, and what happens if the outage exceeds the approved duration. - Notify named recipients. Use a site-specific list with primary and alternate contacts for the fire department, alarm or supervising service, insurer, affected supervisors, tenants, facilities, security, property management, contractors, and authorities. Record who was reached, when, by whom, and any instructions received. - Tag and control the work. Place required impairment tags, secure or supervise affected valves and equipment, preserve egress and fire-department access, and maintain a live status log. Shift changes must receive an explicit handoff; an open permit should never disappear with the person who started it. - Restore deliberately. Have qualified personnel return equipment and valves to the approved condition, conduct the inspections and tests required for the affected work, verify signals and supervising service where applicable, check for leaks or trouble, reconcile normal status, remove safeguards and tags, and notify every required party. Use one record for emergency impairments as soon as immediate life-safety actions are underway. Capture discovery time, cause if known, area affected, interim safeguards, repair resources, decisions, and updates. Do not postpone documentation until the failure is fixed; operations need a current shared picture. Review every impairment for duration, notification delays, unplanned scope expansion, missed shift handoffs, fire-watch findings, test failures, valve-position errors, and incomplete restoration. Repeated impairments at the same component should trigger an engineering or maintenance review. The successful outcome is not merely “water back on.” It is documented proof that protection, supervision, affected operations, and stakeholder awareness returned to the intended condition. ## Official references - National Fire Protection Association, [NFPA 25, Standard for the Inspection, Testing, and Maintenance of Water-Based Fire Protection Systems, 2026 edition](https://link.nfpa.org/all-publications/25/2026). - NFPA, [NFPA 1, Fire Code, 2024 edition](https://link.nfpa.org/all-publications/1/2024), fire-protection system impairment provisions; confirm the adopted code and local requirements. ## Primary reference - Name: NFPA 25: Standard for the Inspection, Testing, and Maintenance of Water-Based Fire Protection Systems, 2026 edition - Authority: National Fire Protection Association - URL: https://link.nfpa.org/all-publications/25/2026 - Source publication date: 2026-01-01 ## Citation and use Preferred citation: “Manage fire-protection impairments before the valve closes,” DSE Security, https://update.dsesecurity.com/updates/manage-fire-protection-impairments-before-valve-closes/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Manage mobile and BYOD security from enrollment through retirement > A secure mobile program distinguishes company-owned and personal devices, documents privacy boundaries, enrolls management before access, protects business data, and prepares for loss, reassignment, and retirement. - Canonical URL: https://update.dsesecurity.com/updates/mobile-byod-security-enrollment-retirement-lifecycle/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-28T14:22:00+00:00 - Modified: 2026-07-28T14:22:00+00:00 - Last reviewed by DSE: 2026-07-28 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know A secure mobile program distinguishes company-owned and personal devices, documents privacy boundaries, enrolls management before access, protects business data, and prepares for loss, reassignment, and retirement. ## Potentially affected Smartphones and tablets that access business mail, files, applications, identity services, Wi-Fi, VPN, certificates, physical-access credentials, messaging, or administrative systems. ## DSE recommendation Choose approved ownership models, document management and privacy boundaries, require enrollment and supported software, control business data, create a lost-device runbook, and verify secure reassignment or disposal. ## Article ## Source fact: mobile security is a lifecycle NIST SP 800-124 Rev. 2 treats mobile-device security as a lifecycle that includes identifying requirements, performing risk assessment, implementing and testing a solution, operating and maintaining it, and disposing of devices securely. The guidance covers organization-owned and personally owned devices and emphasizes that controls depend on ownership, deployment method, data sensitivity, threats, and available platform capabilities. It is a federal publication that other organizations can adapt rather than a universal mandate for one mobile platform. The full [NIST mobile-device security guidance](https://csrc.nist.gov/pubs/sp/800/124/r2/final) describes enterprise mobility management, application controls, authentication, encryption, network protections, monitoring, and incident response. Platform features differ. For example, a managed work profile can separate organizational applications and data on some Android deployments, while Apple enrollment types expose different management, privacy, lock, and erase capabilities. Confirm the behavior of the exact operating system, enrollment mode, and management service instead of promising a control that the selected model cannot perform. ## Define ownership and privacy before enrollment Publish which models are allowed: fully managed company device, company-owned device with limited personal use, or bring your own device. For each model, state what administrators can inventory, configure, monitor, lock, remove, or erase; what they cannot see; which business applications and data are allowed; and what happens during loss, investigation, departure, or legal preservation. Obtain acknowledgement before access is granted. A BYOD agreement should not imply full-device control if management can remove only the work profile. Connect enrollment to an authoritative identity and require supported software, device encryption, screen lock, secure authentication, and approved management state before issuing mail, VPN, Wi-Fi, application, or physical-access credentials. Block devices that are rooted, jailbroken, unsupported, or materially noncompliant according to the organization’s tested policy. ## DSE recommendation: operate from a controlled checklist - Record device identity, serial or management ID, ownership, assigned person, operating system, enrollment type, issued credentials, approved exceptions, and next review date. - Separate business data with managed applications, profiles, containers, or access policies appropriate to the platform. Limit unmanaged export, backup, copy, and sharing where the business risk requires it. - Deploy operating-system and application updates in measured waves. Monitor support status, compliance, failed enrollment, disabled protection, and devices that stop checking in. - Prepare a lost-device procedure that authenticates the reporter, revokes sessions and credentials, attempts the supported lock or work-data removal, preserves evidence, assesses notification duties, and records each action. - For reassignment or return, remove business identities and data, revoke certificates and tokens, confirm required preservation, perform the supported wipe, and verify the device at the setup screen before reissue. - For BYOD departure, remove organizational access and managed data without claiming that personal data was erased unless the platform evidence proves it. Test enrollment, offline behavior, lost-device response, replacement, work-data removal, and full retirement on representative devices. Keep an alternate contact and access path for employees whose phone is unavailable; a recovery process that depends on the missing device is not a complete plan. ## Primary reference - Name: NIST SP 800-124 Rev. 2: Mobile Device Security - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/124/r2/final - Source publication date: 2023-05-17 ## Citation and use Preferred citation: “Manage mobile and BYOD security from enrollment through retirement,” DSE Security, https://update.dsesecurity.com/updates/mobile-byod-security-enrollment-retirement-lifecycle/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Manage the seven-day identity alert queue with explicit filters and classifications > Use View and manage security alerts to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/manage-seven-day-identity-alert-queue-with-filters-and-classifications/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:58+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use View and manage security alerts to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of View and manage security alerts ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Manage the seven-day identity alert queue with explicit filters and classifications. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [View and manage security alerts](https://learn.microsoft.com/en-us/defender-for-identity/understanding-security-alerts) from Microsoft supports the following bounded statements: - By default, the alerts queue shows alerts seen in the previous seven days in a grouped view with the newest alerts first. The research record locates this support at Opening queue description. - The documented workflow covers viewing, filtering, investigating, classifying, and managing Defender for Identity security alerts. The research record locates this support at Opening scope statement. Only the traced statements above are asserted as source facts. Apply the review to identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions after confirming that the source and deployed context match. ## What the source does not establish Queue defaults are not a retention policy, and classification requires investigation evidence and the organization’s incident process. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening queue description, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening scope statement, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from Opening queue description; Opening scope statement through sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [View and manage security alerts](https://learn.microsoft.com/en-us/defender-for-identity/understanding-security-alerts) — Microsoft ## Primary reference - Name: View and manage security alerts - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/understanding-security-alerts - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Manage the seven-day identity alert queue with explicit filters and classifications,” DSE Security, https://update.dsesecurity.com/updates/manage-seven-day-identity-alert-queue-with-filters-and-classifications/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map a tenant virtual gateway to its routing subnet and gateway pool > Which tenant and routing references must be checked when adding an SDN virtual gateway? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-118-map-a-tenant-virtual-gateway-to-its-routing-subnet-and-gateway-pool/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:13+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which tenant and routing references must be checked when adding an SDN virtual gateway? ## Potentially affected Administrators adding site-to-site connectivity to SDN tenant virtual networks. ## DSE recommendation Have the tenant and network owners review one diagram showing the gateway, subnet, peer, and route ownership. ## Article ## Source facts A tenant virtual gateway contains network connections such as site-to-site VPN tunnels and may include BGP connections. It links the tenant network with an external network. Microsoft’s procedure first verifies the routing subnet in Network Controller. The new gateway object references both a gateway pool and the subnet used between the gateway and tenant network before the object is added for that tenant. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Add-a-Virtual-Gateway-to-a-Tenant-Virtual-Network). ## Applicability Identify the tenant, external peer, virtual network, routing subnet, gateway pool, and approved connection parameters. Replace every example value with an explicitly reviewed value for the intended deployment. ## DSE recommendation Have the tenant and network owners review one diagram showing the gateway, subnet, peer, and route ownership. Record which references belong to that tenant and which infrastructure is shared. Define the expected reachable prefixes and the routes that must remain unavailable. ## Verification After approved provisioning, inspect the gateway object’s tenant and subnet references and test the agreed traffic paths. Check routing or tunnel state appropriate to the selected connection type. Include a test of an excluded destination and preserve unexpected reachability as a finding before accepting the connection. ## Official references [Microsoft Learn: Add a Virtual Gateway to a Tenant Virtual Network](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Add-a-Virtual-Gateway-to-a-Tenant-Virtual-Network). Source reviewed September 8, 2026. ## Primary reference - Name: Add a Virtual Gateway to a Tenant Virtual Network - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Add-a-Virtual-Gateway-to-a-Tenant-Virtual-Network - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Map a tenant virtual gateway to its routing subnet and gateway pool,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-118-map-a-tenant-virtual-gateway-to-its-routing-subnet-and-gateway-pool/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map AWS dependencies to the fault boundary they actually use > Trace workload components across Availability Zones, Regions, and control or data planes before making resilience claims. - Canonical URL: https://update.dsesecurity.com/updates/map-aws-dependencies-to-fault-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:24+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Trace workload components across Availability Zones, Regions, and control or data planes before making resilience claims. ## Potentially affected Organizations designing or reviewing business-critical workloads on Amazon Web Services ## DSE recommendation Map every critical dependency to its AWS fault-isolation boundary and test the workload's behavior when that boundary is impaired. ## Article Placing compute instances in two Availability Zones does not make a workload multi-AZ if identity, data, networking, deployment, or operations still depend on one boundary. Resilience claims should follow the full request and recovery path. ## Source fact: [The AWS Fault Isolation Boundaries whitepaper](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) describes AWS isolation constructs that customers can use when designing resilient workloads. It discusses Availability Zones and Regions as important geographic and infrastructure boundaries, and it distinguishes service control planes from data planes. The whitepaper’s prescriptive guidance encourages builders to understand service dependencies and choose boundaries that align with workload resilience needs. An Availability Zone is intended as an isolated location within a Region, while a Region provides a wider boundary. Control-plane operations used to create or change resources can have different availability characteristics from the data-plane operations that handle established workload traffic. These concepts inform architecture; they do not certify a customer workload as fault tolerant or establish that every AWS service behaves identically. ## Boundary AWS service architecture, regional availability, quotas, replication modes, endpoints, and recovery features differ and evolve. A diagram showing multiple zones does not prove independent capacity, routing, data, secrets, or deployment. Multi-Region design adds consistency, failover, cost, security, and operational complexity and is not automatically required. Customer software and third-party services can introduce shared failures outside AWS boundaries. ## Applicability questions - What customer transaction or essential function is the resilience claim intended to preserve? - For each hop, which Region, Availability Zone, endpoint, control plane, data plane, and external provider is used? - Where are state, keys, DNS, identity, observability, deployment artifacts, and operator access located? - Is failover preprovisioned with tested capacity, or does it depend on creating resources during the incident? - What consistency and recovery-point tradeoffs are accepted for replicated data? ## DSE recommendation: Draw a dependency graph from user entry through DNS, network, compute, messaging, storage, database, secrets, identity, telemetry, and operational tooling. Annotate each component with its actual isolation boundary and the API operations needed for recovery. Identify supposedly redundant components that share an Availability Zone, Region, account dependency, quota, artifact store, or external service. Define the smallest credible failure for each required recovery objective and test it using supported fault-injection or controlled isolation methods. Verify traffic shifts, data behavior, capacity, operator access, monitoring, and return to normal. Prefer recovery actions that use already provisioned data-plane capability when a control-plane impairment is in scope. Document architectural gaps and narrow service claims until remediation is tested. ## Verification and evidence Keep the dated dependency graph, AWS service and Region matrix, configuration evidence, quotas and capacity assumptions, data-replication settings, fault scenario, synchronized telemetry, user-transaction results, and recovery timestamps. Evidence should show the component that failed, the boundary contained or propagated the failure, and the exact dependency used during recovery. Revisit the map after new services, regions, accounts, or deployment pipelines are introduced. ## Official references - [AWS Fault Isolation Boundaries whitepaper](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html) ## Primary reference - Name: AWS Fault Isolation Boundaries - Authority: docs.aws.amazon.com - URL: https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html - Source publication date: 2022-11-16 ## Citation and use Preferred citation: “Map AWS dependencies to the fault boundary they actually use,” DSE Security, https://update.dsesecurity.com/updates/map-aws-dependencies-to-fault-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map cloud access control to the service layer that actually makes the decision > IaaS, PaaS, and SaaS expose different components and administrative boundaries. Trace every important access decision to the identity, policy, service layer, owner, and evidence source that enforce it. - Canonical URL: https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:06+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know IaaS, PaaS, and SaaS expose different components and administrative boundaries. Trace every important access decision to the identity, policy, service layer, owner, and evidence source that enforce it. ## Potentially affected Organizations using infrastructure, platform, or software cloud services, especially where provider, tenant, application, and data-layer authorization overlap. ## DSE recommendation Create an access-decision map across provider and customer layers, define owners and authoritative policy for each decision, and test effective access with representative identities rather than relying on role names alone. ## Article Bottom line: “cloud access” is rarely one control. A request may cross provider administration, tenant identity, platform policy, application roles, resource permissions, data filtering, network boundaries, and support channels. Map the layer that makes each decision before assigning or reviewing access. ## Source fact: what NIST covers [NIST SP 800-210](https://csrc.nist.gov/pubs/sp/800/210/final) presents cloud access-control characteristics and general guidance for infrastructure, platform, and software service models. NIST notes that the models expose different types of components and access. It describes them as hierarchical in the sense that guidance for lower-level functional components can remain relevant when those components appear within higher-level models, while each service model retains its own access-control focus. This supports an important operating distinction: the provider’s controls and the customer’s controls can both matter, but they do not necessarily make the same decision or produce the same evidence. ## What the source does not establish The publication does not certify a cloud service or prescribe exact product roles. It does not prove that a provider role, tenant group, application role, and data permission align. A least-privilege name is not evidence of least-privilege behavior. The source also does not establish contractual responsibility, licensing, feature availability, or log retention for a particular service. Those facts must come from current service documentation and the customer’s agreement and configuration. ## Applicability questions - Which service model and functional components are in scope for this resource? - At which layer is authentication performed, and at which layers is authorization re-evaluated? - Which provider, tenant, application, data, automation, and support identities can affect the resource? - Where is policy configured, who can change it, and which logs show the resulting decision? - Can an alternate path bypass the intended control, such as an API, service identity, support process, or inherited permission? ## DSE recommendation: create an access-decision map The following steps are DSE recommendations based on the cited source. - For each consequential operation, record the caller, action, resource, service layer, policy decision point, enforcement point, owner, and evidence source. - Separate provider responsibilities from customer configuration and from application-specific authorization. Confirm each boundary against current official documentation and contracts. - Inventory human and non-human identities, including emergency, support, deployment, integration, and background identities. Avoid assuming one directory contains the complete access picture. - Test effective access with representative accounts at each role and boundary. Include denied operations, cross-tenant or cross-project paths, and direct API access where supported. - Protect policy change and diagnostic access as privileged operations. Record approvals and review unusual grants, bypasses, and failed authorization events. - Re-run the map after service architecture, identity integration, subscription, or application behavior changes. ## Verification and evidence Retain the architecture and decision map, official responsibility documentation, exported role and policy configuration, effective-access tests, denied-event logs, privileged-change records, exception register, and review sign-off. Evidence should identify the tenant, subscription or project, region where relevant, resource, and test identity. ## Official references - [NIST SP 800-210 — General Access Control Guidance for Cloud Systems](https://csrc.nist.gov/pubs/sp/800/210/final) — National Institute of Standards and Technology; finalized July 31, 2020 ## Primary reference - Name: NIST SP 800-210 — General Access Control Guidance for Cloud Systems - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/210/final - Source publication date: 2020-07-31 ## Citation and use Preferred citation: “Map cloud access control to the service layer that actually makes the decision,” DSE Security, https://update.dsesecurity.com/updates/cloud-access-control-service-layer-map/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map cluster fault domains to the actual rack and site layout > Which physical relationships should be represented in a cluster fault-domain hierarchy? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-061-map-cluster-fault-domains-to-the-actual-rack-and-site-layout/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:10+00:00 - Modified: 2026-09-08T18:20:21+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Which physical relationships should be represented in a cluster fault-domain hierarchy? ## Potentially affected Use this review when documenting a cluster's physical placement. ## DSE recommendation Have the facilities and server owners reconcile the logical hierarchy with the equipment inventory. ## Article ## Source facts Microsoft defines a fault domain as hardware sharing a single failure point; tolerance at a level requires multiple domains at that level. The documented hierarchy includes site, rack, chassis, and node. Nodes are discovered automatically, while additional levels are optional. Storage Spaces uses fault-domain information to place redundant copies on separate failure domains. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/failover-clustering/fault-domains). ## Applicability Use this review when documenting a cluster’s physical placement. Identify real racks, chassis, sites, and shared dependencies. Include only hierarchy levels that describe the deployment rather than inventing unused physical distinctions. ## DSE recommendation Have the facilities and server owners reconcile the logical hierarchy with the equipment inventory. Record each node’s actual placement and the failure event each level represents. Review recent equipment moves for stale mappings. Keep data-copy placement objectives separate from quorum-witness placement, and obtain storage-owner review before changing the configured hierarchy. ## Verification Compare the reported fault-domain hierarchy with a checked physical inventory. Inspect the selected storage configuration through the supported management tools and record the relevant placement evidence. Exercise only the approved failure scenario and retain the observed workload result. Update both the map and its ownership record after accepted hardware moves or site changes. ## Official references [Microsoft Learn: Fault domain awareness](https://learn.microsoft.com/en-us/windows-server/failover-clustering/fault-domains). Source reviewed September 8, 2026. ## Primary reference - Name: Fault domain awareness - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/fault-domains - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Map cluster fault domains to the actual rack and site layout,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-061-map-cluster-fault-domains-to-the-actual-rack-and-site-layout/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map container endpoint addresses onto an SDN tenant subnet > How are Windows container endpoints addressed when attached to an SDN tenant virtual network? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-094-map-container-endpoint-addresses-onto-an-sdn-tenant-subnet/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:37+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How are Windows container endpoints addressed when attached to an SDN tenant virtual network? ## Potentially affected Administrators connecting Windows container endpoints to existing SDN tenant networks. ## DSE recommendation Prepare an endpoint allocation worksheet before configuring the host. ## Article ## Source facts Microsoft’s procedure uses the l2bridge network driver, with l2tunnel as another option, for container networks within a tenant VM. For these SDN drivers, container endpoints occupy the same virtual subnet as the tenant VM that hosts them. The Host Networking Service assigns endpoint addresses through the private-cloud plugin. The endpoints have distinct IP addresses but share their host VM’s MAC address because Layer-2 address translation is used. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Connect-container-endpoints-to-a-Tenant-Virtual-Network). ## Applicability Check the existing tenant network, subnet, VM NIC resource, container host, and documented software prerequisites. Treat the source’s sample addresses as examples and substitute only addresses approved for the actual tenant subnet. ## DSE recommendation Prepare an endpoint allocation worksheet before configuring the host. Identify the tenant network, container address range, responsible network controller, and expected isolation boundary. Review the relationship between endpoint IP identities and the shared MAC identity with the operators who will investigate connectivity. ## Verification Create a controlled endpoint and compare its assigned address with the approved range and tenant subnet. Test its allowed connections and isolation from a separate tenant. Preserve the controller, host, and container observations together so address allocation and policy enforcement can be assessed for the same endpoint. ## Official references [Microsoft Learn: Connect container endpoints to a tenant virtual network](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Connect-container-endpoints-to-a-Tenant-Virtual-Network). Source reviewed September 8, 2026. ## Primary reference - Name: Connect container endpoints to a tenant virtual network - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Connect-container-endpoints-to-a-Tenant-Virtual-Network - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Map container endpoint addresses onto an SDN tenant subnet,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-094-map-container-endpoint-addresses-onto-an-sdn-tenant-subnet/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map Defender-format identity alert names by stable alert ID > Use Microsoft Defender for Identity alerts in Microsoft Defender format to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/map-defender-format-identity-alert-names-by-stable-alert-id/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:59+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Microsoft Defender for Identity alerts in Microsoft Defender format to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft Defender for Identity alerts in Microsoft Defender format ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Map Defender-format identity alert names by stable alert ID. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft Defender for Identity alerts in Microsoft Defender format](https://learn.microsoft.com/en-us/defender-for-identity/alerts-xdr) from Microsoft supports the following bounded statements: - Classic and Defender formats use the same underlying Defender for Identity sensor detections but differ in structure, naming, and categorization. The research record locates this support at Opening format comparison. - Alert names differ in the XDR structure while alert IDs remain consistent between the two formats. The research record locates this support at Alert ID note. Only the traced statements above are asserted as source facts. Apply the review to identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions after confirming that the source and deployed context match. ## What the source does not establish A stable ID supports mapping; it does not guarantee unchanged evidence, severity, detection logic, or response guidance over time. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening format comparison, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Alert ID note, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Opening format comparison; Alert ID note through sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Microsoft Defender for Identity alerts in Microsoft Defender format](https://learn.microsoft.com/en-us/defender-for-identity/alerts-xdr) — Microsoft ## Primary reference - Name: Microsoft Defender for Identity alerts in Microsoft Defender format - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/alerts-xdr - Source publication date: 2026-07-01 ## Citation and use Preferred citation: “Map Defender-format identity alert names by stable alert ID,” DSE Security, https://update.dsesecurity.com/updates/map-defender-format-identity-alert-names-by-stable-alert-id/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map DNS packet, server, and data threats to the protection each needs > Use RFC 3833 — Threat Analysis of the Domain Name System (DNS) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/map-dns-packet-server-and-data-threats-to-the-protection-each-needs/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:39+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3833 — Threat Analysis of the Domain Name System (DNS) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3833 — Threat Analysis of the Domain Name System (DNS) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Map DNS packet, server, and data threats to the protection each needs. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3833 — Threat Analysis of the Domain Name System (DNS)](https://www.rfc-editor.org/rfc/rfc3833.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - TSIG can authenticate a dynamic-update client to a server, but it protects the transaction rather than the updated zone data seen by resolvers. The research record locates this support at Section 4.2 (Securing DNS Dynamic Update). - DNSSEC provides data integrity and origin authentication for normal DNS queries, but it does not provide object security for a complete replicated zone containing unsigned delegation data. The research record locates this support at Section 4.3 (Securing DNS Zone Replication). - TSIG protection for AXFR or IXFR supplies channel security between servers, not end-to-end object security for the entire zone. The research record locates this support at Section 4.3 (Securing DNS Zone Replication), transfer boundary. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Section 4.2 (Securing DNS Dynamic Update), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4.3 (Securing DNS Zone Replication), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4.3 (Securing DNS Zone Replication), transfer boundary, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 4.2 (Securing DNS Dynamic Update); Section 4.3 (Securing DNS Zone Replication); Section 4.3 (Securing DNS Zone Replication), transfer boundary. Favor zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 3833 — Threat Analysis of the Domain Name System (DNS)](https://www.rfc-editor.org/rfc/rfc3833.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 3833 — Threat Analysis of the Domain Name System (DNS) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3833.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Map DNS packet, server, and data threats to the protection each needs,” DSE Security, https://update.dsesecurity.com/updates/map-dns-packet-server-and-data-threats-to-the-protection-each-needs/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map each six-bit DSCP to a configured per-hop behavior > Use RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:24+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Map each six-bit DSCP to a configured per-hop behavior. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers](https://www.rfc-editor.org/rfc/rfc2474.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - The DS field uses a six-bit DSCP to select per-hop behavior; the remaining two bits are excluded from that selection. The research record locates this support at Section 3 (Differentiated Services Field Definition). - A compliant node must match the entire six-bit DSCP and support a configurable mapping from codepoints to per-hop behaviors. The research record locates this support at Section 3 (Differentiated Services Field Definition), codepoint mapping. - An unrecognized codepoint should receive the Default behavior without being rewritten and must not cause the node to malfunction. The research record locates this support at Section 3 (Differentiated Services Field Definition), unrecognized codepoints. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Section 3 (Differentiated Services Field Definition), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Differentiated Services Field Definition), codepoint mapping, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 3 (Differentiated Services Field Definition), unrecognized codepoints, which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 3 (Differentiated Services Field Definition); Section 3 (Differentiated Services Field Definition), codepoint mapping; Section 3 (Differentiated Services Field Definition), unrecognized codepoints. Favor configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers](https://www.rfc-editor.org/rfc/rfc2474.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2474.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Map each six-bit DSCP to a configured per-hop behavior,” DSE Security, https://update.dsesecurity.com/updates/map-each-six-bit-dscp-to-a-configured-per-hop-behavior/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map industrial ventilation controls to the operation they actually cover > Use 29 CFR 1910.94 - Ventilation to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/map-industrial-ventilation-controls-to-the-operation-they-actually-cover/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:32+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.94 - Ventilation to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.94 - Ventilation ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Map industrial ventilation controls to the operation they actually cover. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.94 – Ventilation](https://www.ecfr.gov/current/title-29/section-1910.94) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, wherever dry grinding, dry polishing or buffing is performed, and employee exposure, without regard to the use of respirators, exceeds the permissible exposure limits prescribed in section 1910.1000 or other sections of this part, a local exhaust ventilation system must be provided and used to maintain employee exposures within the prescribed limits. The research record locates this support at 29 CFR 1910.94(b)(2) (eCFR anchor p-1910.94(b)(2)). - Under 29 CFR 1910, the rule requires that cradle grinding and polishing operations be performed within a partial enclosure similar to figure G-5. The research record locates this support at 29 CFR 1910.94(b)(5)(vi) (eCFR anchor p-1910.94(b)(5)(vi)). Only the traced statements above are asserted as source facts. Apply the review to critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths after confirming that the source and deployed context match. ## What the source does not establish Federal workplace rule; applicability and engineering performance depend on the exact process, contaminants, incorporated standards, and other exposure rules. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.94(b)(2) (eCFR anchor p-1910.94(b)(2)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.94(b)(5)(vi) (eCFR anchor p-1910.94(b)(5)(vi)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from 29 CFR 1910.94(b)(2) (eCFR anchor p-1910.94(b)(2)); 29 CFR 1910.94(b)(5)(vi) (eCFR anchor p-1910.94(b)(5)(vi)) through facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [29 CFR 1910.94 – Ventilation](https://www.ecfr.gov/current/title-29/section-1910.94) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.94 - Ventilation - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.94 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Map industrial ventilation controls to the operation they actually cover,” DSE Security, https://update.dsesecurity.com/updates/map-industrial-ventilation-controls-to-the-operation-they-actually-cover/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map native Windows LAPS cmdlets before replacing legacy scripts > Use Windows LAPS PowerShell Cmdlets Overview to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/map-native-windows-laps-cmdlets-before-replacing-legacy-scripts/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:58+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Windows LAPS PowerShell Cmdlets Overview to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Windows LAPS PowerShell Cmdlets Overview ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Map native Windows LAPS cmdlets before replacing legacy scripts. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Windows LAPS PowerShell Cmdlets Overview](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-powershell) from Microsoft supports the following bounded statements: - Get-LapsADPassword queries Active Directory, Reset-LapsPassword initiates immediate rotation, and Set-LapsADAuditing configures Windows LAPS auditing on Active Directory organizational units. The research record locates this support at Cmdlet descriptions and usage > cmdlet table. - Several native Windows LAPS cmdlets have no legacy counterpart, and the Active Directory cmdlets operate on a different set of schema extensions from legacy Microsoft LAPS. The research record locates this support at Comparing Windows LAPS and legacy Microsoft LAPS PowerShell > mapping table and following paragraph. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios and the conditions the source actually describes. ## What the source does not establish A cmdlet mapping does not prove script compatibility, authorization, or safe secret handling; protect returned passwords and test schema, permissions, and output before migration. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Cmdlet descriptions and usage > cmdlet table, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Comparing Windows LAPS and legacy Microsoft LAPS PowerShell > mapping table and following paragraph, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios are in and out of scope? - Which condition in Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Cmdlet descriptions and usage > cmdlet table; Comparing Windows LAPS and legacy Microsoft LAPS PowerShell > mapping table and following paragraph. Favor policy exports, directory access-control entries, sanitized client events, rotation tests, retrieval authorization, and exception records, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Windows LAPS PowerShell Cmdlets Overview](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-powershell) — Microsoft ## Primary reference - Name: Windows LAPS PowerShell Cmdlets Overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-powershell - Source publication date: 2025-05-06 ## Citation and use Preferred citation: “Map native Windows LAPS cmdlets before replacing legacy scripts,” DSE Security, https://update.dsesecurity.com/updates/map-native-windows-laps-cmdlets-before-replacing-legacy-scripts/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map space-weather dependencies before GPS, radio, or satellite service degrades > Use NOAA's separate geomagnetic-storm, solar-radiation-storm, and radio-blackout scales to identify operational dependencies and continuity triggers. - Canonical URL: https://update.dsesecurity.com/updates/map-space-weather-dependencies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:15+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use NOAA's separate geomagnetic-storm, solar-radiation-storm, and radio-blackout scales to identify operational dependencies and continuity triggers. ## Potentially affected Operations that depend on satellite navigation or timing, HF or low-frequency radio, satellite services, long electric-power paths, or space-based systems ## DSE recommendation Trace critical services to space-weather-sensitive dependencies, monitor authoritative NOAA products, and exercise bounded loss or degradation scenarios. ## Article Space weather is not one condition and the NOAA scales are not interchangeable. Continuity planning should connect each relevant event type to the specific power, navigation, timing, radio, satellite, or provider dependency that could affect an essential operation. ## Source fact: [The NOAA Space Weather Scales](https://www.spaceweather.gov/noaa-scales-explanation) communicate possible effects from three different kinds of environmental disturbance: geomagnetic storms, solar radiation storms, and radio blackouts. NOAA labels the scales G, S, and R respectively, with numbered severity levels and descriptions of possible effects and the physical measure behind each category. NOAA’s tables identify possible impacts across systems including electric power, spacecraft operations, high-frequency radio, low-frequency navigation, and satellite navigation. The listed effects depend on the event type and level. For example, the radio-blackout scale focuses on HF radio and navigation conditions on the sunlit side of Earth, while the geomagnetic-storm scale includes possible power-system, spacecraft, radio, and satellite-navigation effects. The scale is a communication aid; it does not report the condition of an organization’s equipment or guarantee a stated effect at a particular site. ## Boundary Space-weather consequences vary with latitude, event duration, local time, technology, receiver design, service architecture, provider response, and other conditions. A NOAA level is not by itself an instruction to shut down, fail over, or declare an outage. Utilities, aviation, satellite operators, communications providers, equipment manufacturers, and government authorities may issue more specific direction. Ordinary equipment failure, terrestrial interference, cyber incidents, and weather can produce similar symptoms, so correlation is not proof of cause. ## Applicability questions - Which essential functions use satellite-derived position, navigation, or time directly or through an upstream service? - Which backup communications depend on HF radio, satellite links, low-frequency navigation, or the same electric utility as the primary path? - Do cellular, broadcast, data-center, cloud, financial, dispatch, synchronization, surveying, or vehicle services conceal a GNSS or satellite dependency? - Which NOAA product and provider notice is authoritative for each operating decision, and who monitors it outside business hours? - What safe degraded mode exists if the service becomes inaccurate or intermittent rather than fully unavailable? ## DSE recommendation: Map each essential transaction to its time, location, power, radio, and satellite dependencies. Ask vendors and service providers which NOAA event types or conditions matter to the exact service and what telemetry exposes degradation. Record geographic scope, internal owner, provider contact, alternative source, safe operating limit, and restoration check. Do not treat two products as diverse until their upstream timing, power, satellite, antenna, carrier, and control dependencies are understood. Create an alert-to-decision matrix that keeps G, S, and R products separate. Use current SWPC watches, warnings, alerts, and scale information as inputs, then apply provider or engineering criteria for the asset. Define who validates the notice, communicates with service owners, activates a degraded mode, and returns to normal. Avoid automatic production changes based only on a public scale value unless the action has been engineered and approved for that input. Exercise representative effects through safe simulation: remove an external time source, inject an approved loss-of-lock condition, disable a test satellite or HF path, or make provider data unavailable. Verify holdover, alarms, alternative communications, transaction integrity, timestamps, operator decisions, and recovery. Never interfere with real navigation or radio services. ## Verification and evidence Keep the dependency map, vendor and provider statements, NOAA product links, alert ownership, approved thresholds, equipment telemetry, simulation design, synchronized logs, degraded-mode results, communication records, and restoration checks. Evidence should distinguish loss, degraded accuracy, intermittent service, and stale data. Review after receiver, antenna, timing, carrier, satellite, power, or provider changes and after any relevant NOAA event. ## Official references - [NOAA Space Weather Scales](https://www.spaceweather.gov/noaa-scales-explanation) - [NOAA SWPC Notifications Timeline](https://www.spaceweather.gov/products/notifications-timeline) ## Primary reference - Name: NOAA Space Weather Scales - Authority: www.spaceweather.gov - URL: https://www.spaceweather.gov/noaa-scales-explanation - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Map space-weather dependencies before GPS, radio, or satellite service degrades,” DSE Security, https://update.dsesecurity.com/updates/map-space-weather-dependencies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map supply routes and private-sector dependencies before a disaster > Include suppliers, transportation modes, access constraints, and alternative routes in continuity planning before normal supply flow is interrupted. - Canonical URL: https://update.dsesecurity.com/updates/map-supply-routes-and-dependencies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:30+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know Include suppliers, transportation modes, access constraints, and alternative routes in continuity planning before normal supply flow is interrupted. ## Potentially affected Organizations that depend on time-sensitive fuel, food, medical, technology, repair, or other physical supplies ## DSE recommendation Map critical supply chains with partners, plan alternate routes and modes, and exercise information-sharing and access decisions. ## Article A purchase order does not show whether a critical supply can reach the site after roads, ports, warehouses, fuel, staffing, or access-control procedures change. Continuity planning needs the physical and organizational path behind the supplier contract. ## Source fact: [FEMA’s Supply Chain Resilience Guide](https://www.fema.gov/sites/default/files/2020-07/supply-chain-resilience-guide.pdf) describes a process for understanding and strengthening supply chains before and during disasters. Its approach includes mapping and analyzing supply chains, engaging stakeholders, taking action, assessing results, and refining the work. The guide emphasizes collaboration with private-sector partners whose operational knowledge is necessary to understand how goods move. The guide calls attention to normal and alternative transportation routes and modes, access and re-entry considerations, and the information needed to support supply-chain decisions. The method is iterative: changing hazards, markets, facilities, and partner capabilities require continued assessment. Mapping can reveal dependencies and options; it cannot guarantee that stock, transport, staff, or infrastructure will be available during a particular incident. ## Boundary FEMA’s guide is planning guidance, not a supplier assurance, traffic authorization, or substitute for emergency-management authorities. Sharing maps, inventories, forecasts, and vulnerabilities can expose commercially or operationally sensitive information, so governance is needed. A named alternate supplier may depend on the same upstream manufacturer, warehouse, carrier, route, power system, or communications service as the primary. ## Applicability questions - Which supplies have a maximum tolerable interruption shorter than their realistic replenishment time? - What upstream facilities, carriers, routes, ports, fuel sources, labor, permits, and communications support delivery? - Which alternatives are contractually available, geographically separate, and technically compatible? - How will delivery vehicles and personnel receive current access and re-entry information? - What information may be shared with public agencies and partners, by whom, and through what protected channel? ## DSE recommendation: Select a manageable set of operationally critical supplies and map them from point of use through local inventory, distributors, carriers, warehouses, and known upstream sources. Record lead time, consumption, substitutions, transport modes, route constraints, minimum staffing, cold-chain or handling needs, and replenishment triggers. Ask partners to validate the map without demanding proprietary detail that is not needed for decisions. Identify shared choke points and develop layered options: increased or redistributed stock, compatible substitutes, alternate suppliers, alternate delivery locations, different modes or routes, and demand reduction. Coordinate access and re-entry assumptions with the relevant authorities before an event. Establish contact roles and a situation-update format. Exercise a disruption that removes the normal route and one major supplier simultaneously, then update contracts and plans from the result. ## Verification and evidence Keep the dated dependency map, partner validations, consumption and lead-time evidence, contracts or letters supporting alternatives, access assumptions, contact tests, exercise injects, decisions, and remediation owners. Confirm at least one alternate by a real order or bounded logistics test where practical. Mark uncertain upstream dependencies explicitly; absence of supplier disclosure is not evidence of diversity. ## Official references - [FEMA Supply Chain Resilience Guide](https://www.fema.gov/sites/default/files/2020-07/supply-chain-resilience-guide.pdf) ## Primary reference - Name: Supply Chain Resilience Guide - Authority: Federal Emergency Management Agency - URL: https://www.fema.gov/sites/default/files/2020-07/supply-chain-resilience-guide.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Map supply routes and private-sector dependencies before a disaster,” DSE Security, https://update.dsesecurity.com/updates/map-supply-routes-and-dependencies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map the layers behind a Storage Spaces Direct pool > Which Windows components contribute to a Storage Spaces Direct storage path? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-122-map-the-layers-behind-a-storage-spaces-direct-pool/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:09+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Which Windows components contribute to a Storage Spaces Direct storage path? ## Potentially affected Use this review when documenting the architecture of a supported Storage Spaces Direct environment. ## DSE recommendation Create a component map that follows the workload to its volume, pool, server storage, and interserver network. ## Article ## Source facts Storage Spaces Direct combines servers with internal storage into a clustered software-defined storage solution. Its overview describes pooling drives across physical servers and providing cache, tiers, and resiliency within that pool. The design uses Failover Clustering, Cluster Shared Volumes, SMB3, and Storage Spaces, together with the Software Storage Bus. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview). ## Applicability Use this review when documenting the architecture of a supported Storage Spaces Direct environment. Identify the servers, local drives, network paths, pool, and consuming workload. Review the current hardware and scale requirements separately from the conceptual diagram. ## DSE recommendation Create a component map that follows the workload to its volume, pool, server storage, and interserver network. Assign an owner for each layer and record where its health evidence is obtained. Use the map to organize incident information before changing settings. Keep architecture explanation separate from the installation procedure and from later decisions about volume size or resiliency. ## Verification Compare the map with the actual cluster, pool, and volume inventory. Trace one representative workload and verify that its documented path matches the deployment. Record discrepancies and update ownership before relying on the map during an outage. Use a separately approved failure exercise to assess availability; a component diagram alone is not an observed recovery result. ## Official references [Microsoft Learn: Storage Spaces Direct overview](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview). Source reviewed September 8, 2026. ## Primary reference - Name: Storage Spaces Direct overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-direct-overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Map the layers behind a Storage Spaces Direct pool,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-122-map-the-layers-behind-a-storage-spaces-direct-pool/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map what AD DS stores before delegating directory access > Use Active Directory Domain Services overview to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/map-ad-ds-directory-data-before-delegation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:20+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Active Directory Domain Services overview to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Active Directory Domain Services overview ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Map what AD DS stores before delegating directory access. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Active Directory Domain Services overview](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview) from Microsoft supports the following bounded statements: - AD DS stores information about network objects such as user accounts in a hierarchical directory. The research record locates this support at Opening overview. - The directory service makes stored data available to authorized network users and administrators. The research record locates this support at Opening overview. The source support ends with the statements listed above. Use them to examine forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Conceptual architecture only; use separate deployment and delegation procedures for changes. No current deployment state or change approval follows from the source alone. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Active Directory Domain Services overview](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview) — Microsoft ## Primary reference - Name: Active Directory Domain Services overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/virtual-dc/active-directory-domain-services-overview - Source publication date: 2025-03-10 ## Citation and use Preferred citation: “Map what AD DS stores before delegating directory access,” DSE Security, https://update.dsesecurity.com/updates/map-ad-ds-directory-data-before-delegation/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Map Windows DNS resolution from namespace to authoritative zone > Use DNS Architecture in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/map-windows-dns-resolution-from-namespace-to-authoritative-zone/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:27+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use DNS Architecture in Windows Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of DNS Architecture in Windows Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Map Windows DNS resolution from namespace to authoritative zone. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [DNS Architecture in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-architecture) from Microsoft supports the following bounded statements: - Windows DNS architecture distinguishes domain names, the domain namespace, resource records, and zones. The research record locates this support at Understanding the DNS domain namespace; DNS resource records; Zones and delegation. - A DNS zone is the hosted portion of a namespace that contains the records answered by an authoritative server. The research record locates this support at Understanding the DNS domain namespace; DNS resource records; Zones and delegation. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish Architecture terminology does not prove that a particular Windows DNS deployment, delegation, or Active Directory replication scope is configured correctly. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Understanding the DNS domain namespace; DNS resource records; Zones and delegation, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Understanding the DNS domain namespace; DNS resource records; Zones and delegation, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations Understanding the DNS domain namespace; DNS resource records; Zones and delegation; Understanding the DNS domain namespace; DNS resource records; Zones and delegation adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [DNS Architecture in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-architecture) — Microsoft ## Primary reference - Name: DNS Architecture in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/dns-architecture - Source publication date: 2025-03-24 ## Citation and use Preferred citation: “Map Windows DNS resolution from namespace to authoritative zone,” DSE Security, https://update.dsesecurity.com/updates/map-windows-dns-resolution-from-namespace-to-authoritative-zone/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Match Remote Desktop launch links to the intended client > Which Remote Desktop URI scheme can a managed client actually interpret? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-172-match-remote-desktop-launch-links-to-the-intended-client/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:19+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which Remote Desktop URI scheme can a managed client actually interpret? ## Potentially affected Administrators distributing links that launch Microsoft Remote Desktop clients. ## DSE recommendation Maintain a small catalog of approved link patterns with their intended client, command, and parameter names. ## Article ## Source facts Microsoft documents URI formats that invoke Remote Desktop clients with commands or preset attributes. The ms-rd scheme is documented for the Windows Desktop client, MSRDC. The legacy rdp scheme is documented for the macOS, iOS, and Android clients. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-uri). ## Applicability Identify the installed client and platform before publishing a launch link. Review the source attribute table for each target population. Keep the command being requested, the destination information, and platform support visible to the person reviewing the link. ## DSE recommendation Maintain a small catalog of approved link patterns with their intended client, command, and parameter names. Use a nonproduction destination while building the pattern. Have a second reviewer inspect encoded values and the resulting destination before distribution. Avoid embedding sensitive material in a link merely because an attribute field exists. Provide a clear owner for correcting or retiring stale links. ## Verification Open each pattern on every supported managed client and record which application launches and which settings it receives. Test an unsupported client as a negative case and document the user-facing result. Confirm the destination before completing an authorized connection. Retest the catalog when the client application or platform changes. ## Official references [Microsoft Learn: Remote Desktop URI scheme](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-uri). Source reviewed September 8, 2026. ## Primary reference - Name: Remote Desktop URI scheme - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-uri - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Match Remote Desktop launch links to the intended client,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-172-match-remote-desktop-launch-links-to-the-intended-client/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Match replies to outstanding DNS queries before accepting an answer > Use RFC 5452 — Measures for Making DNS More Resilient against Forged Answers to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/match-replies-to-outstanding-dns-queries-before-accepting-an-answer/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:38+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 5452 — Measures for Making DNS More Resilient against Forged Answers to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 5452 — Measures for Making DNS More Resilient against Forged Answers ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Match replies to outstanding DNS queries before accepting an answer. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 5452 — Measures for Making DNS More Resilient against Forged Answers](https://www.rfc-editor.org/rfc/rfc5452.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Before accepting a DNS reply, a resolver must match its addresses, destination port, query ID, query name, query class, and query type to the outstanding query. The research record locates this support at Section 9.1 (Query Matching Rules). - Resolvers must choose outgoing query IDs unpredictably across the full 16-bit range and use the largest practical unpredictable source-port range. The research record locates this support at Section 9.2 (Extending the Q-ID Space by Using Ports and Addresses). - With multiple outstanding queries, a resolver must use multiple source ports; a resolver with multiple addresses should also vary its outgoing address unpredictably. The research record locates this support at Section 9.2 (Extending the Q-ID Space by Using Ports and Addresses), concurrent queries. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Section 9.1 (Query Matching Rules), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 9.2 (Extending the Q-ID Space by Using Ports and Addresses), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 9.2 (Extending the Q-ID Space by Using Ports and Addresses), concurrent queries, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 9.1 (Query Matching Rules); Section 9.2 (Extending the Q-ID Space by Using Ports and Addresses); Section 9.2 (Extending the Q-ID Space by Using Ports and Addresses), concurrent queries. Favor zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 5452 — Measures for Making DNS More Resilient against Forged Answers](https://www.rfc-editor.org/rfc/rfc5452.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 5452 — Measures for Making DNS More Resilient against Forged Answers - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5452.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Match replies to outstanding DNS queries before accepting an answer,” DSE Security, https://update.dsesecurity.com/updates/match-replies-to-outstanding-dns-queries-before-accepting-an-answer/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Match required SIEM message syntax before standalone sensor ingestion > Use Listen for SIEM events on your Defender for Identity standalone sensor to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/match-required-siem-message-syntax-before-standalone-ingestion/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:24+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Listen for SIEM events on your Defender for Identity standalone sensor to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Listen for SIEM events on your Defender for Identity standalone sensor ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Match required SIEM message syntax before standalone sensor ingestion. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Listen for SIEM events on your Defender for Identity standalone sensor](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-event-collection) from Microsoft supports the following bounded statements: - The document defines required message syntax for a standalone sensor to listen for supported SIEM event types. The research record locates this support at Opening overview. - Its RSA Security Analytics example uses a Windows event 4776 message and treats the standard RFC 3164 syslog header prefix as optional. The research record locates this support at Raw Syslog example. Only the traced statements above are asserted as source facts. Apply the review to Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health after confirming that the source and deployed context match. ## What the source does not establish The example is not a universal parser contract for every SIEM, event type, or unsupported sensor version. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Raw Syslog example, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Raw Syslog example through sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Listen for SIEM events on your Defender for Identity standalone sensor](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-event-collection) — Microsoft ## Primary reference - Name: Listen for SIEM events on your Defender for Identity standalone sensor - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-event-collection - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Match required SIEM message syntax before standalone sensor ingestion,” DSE Security, https://update.dsesecurity.com/updates/match-required-siem-message-syntax-before-standalone-ingestion/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Match the Disk Cleanup procedure to the installed Windows Server release > When does a Disk Cleanup task require feature installation rather than just using the available tool? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-054-match-the-disk-cleanup-procedure-to-the-installed-windows-server-release/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:17+00:00 - Modified: 2026-09-08T18:20:21+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know When does a Disk Cleanup task require feature installation rather than just using the available tool? ## Potentially affected Use this review when preparing a cleanup request for an identified server. ## DSE recommendation Ask the server owner to identify the actual storage problem and the file categories proposed for cleanup. ## Article ## Source facts Microsoft states that Disk Cleanup is available by default in Windows Server 2016 and Windows Server 2019. The source distinguishes earlier releases, where cleanmgr.exe was not present by default without Desktop Experience. The tool is intended to clear unnecessary files from a Windows Server environment. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/file-server/disk-cleanup). ## Applicability Use this review when preparing a cleanup request for an identified server. Confirm the installed release and available tool before adapting instructions. Treat the source’s older-release installation sections as version-specific procedures rather than general prerequisites. ## DSE recommendation Ask the server owner to identify the actual storage problem and the file categories proposed for cleanup. Record the current free space, required recovery material, and approved exclusions. Review the selections in the tool before authorizing removal. Keep application data retention and diagnostic-log retention decisions with their respective owners instead of treating low free space as blanket deletion authority. ## Verification After an approved cleanup, compare available space with the recorded starting value and retain the categories selected. Test the workload and check that required diagnostic or recovery material remains available. Record any error or unexpected result before another cleanup attempt. If reclaimed space does not address the original capacity problem, return that problem to storage planning with the observed evidence. ## Official references [Microsoft Learn: Using Disk Cleanup on Windows Server](https://learn.microsoft.com/en-us/windows-server/storage/file-server/disk-cleanup). Source reviewed September 8, 2026. ## Primary reference - Name: Using Disk Cleanup on Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/file-server/disk-cleanup - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Match the Disk Cleanup procedure to the installed Windows Server release,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-054-match-the-disk-cleanup-procedure-to-the-installed-windows-server-release/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Match the guest-cluster floating IP to its SDN VIP and probe > How should an SDN load-balancer probe identify the active node of a guest cluster? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-125-match-the-guest-cluster-floating-ip-to-its-sdn-vip-and-probe/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:06+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How should an SDN load-balancer probe identify the active node of a guest cluster? ## Potentially affected Administrators running guest failover clusters inside SDN virtual networks. ## DSE recommendation Create a single mapping that shows the same floating address and probe port in the cluster and load-balancer configuration. ## Article ## Source facts Network Controller permits a VM to communicate using its assigned IP addresses. Microsoft therefore requires additional configuration for clustering that uses a floating address. Its design exposes that address through a Software Load Balancer VIP and a health probe that directs traffic to the node currently holding it. The cluster address and probe port must match the corresponding load-balancer settings. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/guest-clustering). ## Applicability Identify the guest nodes, virtual subnet, floating address, VIP, and intended probe port. Review the prerequisites for the guest cluster and reserve the actual address before adapting the example. ## DSE recommendation Create a single mapping that shows the same floating address and probe port in the cluster and load-balancer configuration. Have the guest-cluster and SDN owners review it together. Specify which application request will prove that the active node is reachable through the published address. ## Verification Connect through the VIP and record the responding guest node. Trigger an approved ownership move and repeat the request, checking probe state and cluster ownership during the same window. Investigate a probe mismatch or traffic reaching the wrong node before accepting the floating-address design. ## Official references [Microsoft Learn: Guest clustering in a virtual network](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/guest-clustering). Source reviewed September 8, 2026. ## Primary reference - Name: Guest clustering in a virtual network - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/guest-clustering - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Match the guest-cluster floating IP to its SDN VIP and probe,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-125-match-the-guest-cluster-floating-ip-to-its-sdn-vip-and-probe/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Measure live-video delay before operators must act > A stream can be clear and still arrive too late. Measure sensor-to-screen delay through the production camera, network, VMS, decoder, workstation, and display—under normal and stressed conditions—before live video supports a time-sensitive response. - Canonical URL: https://update.dsesecurity.com/updates/measure-sensor-to-screen-video-latency-before-response/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:39:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know A stream can be clear and still arrive too late. Measure sensor-to-screen delay through the production camera, network, VMS, decoder, workstation, and display—under normal and stressed conditions—before live video supports a time-sensitive response. ## Potentially affected Live video monitoring, remote guarding, intercom-video workflows, PTZ control, VMS clients, WAN links, camera encoders, switches, firewalls, workstations, graphics hardware, and displays. ## DSE recommendation Set a response-specific latency objective, measure end to end at each operating location, test congestion and failover, and tune the whole path without sacrificing required recorded evidence. ## Article ## Source facts: live-video latency is an end-to-end property Axis Communications’ [Latency in live network video surveillance](https://whitepapers.axis.com/en-us/latency-in-live-network-video-surveillance) white paper defines sensor-to-screen latency as the time from capture of a frame until that frame is visible on the video display. It divides the path into camera processing and encoding, network transport, and receiver-side buffering, decoding, and display. Each stage adds delay. The source says the network portion is often the most unpredictable, while a client receive buffer can add up to seconds. Resolution, frame rate, image processing, compression, bitrate, number of streams, available throughput, congestion, protocol choice, client hardware, graphics processing, and display behavior can all affect the result. Network latency alone therefore does not describe what an operator experiences. Axis also describes a practical measurement using a camera timestamp overlay and a view of the displayed stream, with accuracy bounded by the frame interval. That is one manufacturer-specific technique; the correct method depends on the installed products. The important boundary is the same: measure from a real scene change to its presentation on the actual operator display. ## DSE recommendation: make delay part of acceptance Start with the operational consequence. A receptionist checking a visitor, a remote guard assessing an alarm, and an investigator reviewing yesterday’s footage do not have the same latency need. Document a target for each time-sensitive workflow and identify who approves it. Do not invent one universal number or confuse a smooth picture with a timely picture. - Map the full path. Record camera and firmware, stream profile, encoder, switch path, VLAN, router or firewall, WAN or VPN, VMS services, transcoding or proxy stages, client version, workstation, graphics adapter, monitor, and any cloud relay. Note whether live and recorded video follow different paths. - Measure what the operator sees. Use a manufacturer-supported timestamp or another controlled visual event and compare the scene time with the displayed time. Measure several samples, report typical and worst observed delay, and retain the method so results can be repeated. - Test every operating location. Repeat at the local control room, remote office, guard station, mobile or browser client where approved, and during a PTZ or intercom workflow if those functions are in scope. A good result on the server-room console does not validate a remote user. - Exercise load and degradation. Test during normal busy periods, simultaneous multi-camera viewing, incident playback, analytics events, export activity, WAN congestion, and approved network failover. Capture packet loss, throughput, bitrate, workstation utilization, and buffering behavior alongside latency. - Verify control alignment. For PTZ, doors, speakers, or intercoms, determine whether video, audio, and control commands arrive with mismatched delay. An operator should not act on a picture that materially trails the command or conversation. - Protect forensic quality. Do not lower bitrate, resolution, or compression quality merely to improve the live display unless the change is evaluated against the recording requirement. Where supported, use separate, governed live and recording profiles instead of degrading the evidence stream. When delay exceeds the target, isolate stages instead of changing settings at random. Compare direct camera viewing with the VMS client; local with remote; one stream with a video wall; and one workstation with another. Review encoder load, unexpected transcoding, saturated links, quality-of-service behavior, client buffers, decoder and graphics capacity, monitor processing, and unsupported stream combinations. Make one controlled change at a time and repeat the measurement. Store a latency baseline with the system acceptance record and monitor material changes after camera or VMS upgrades, firewall inspection changes, WAN migrations, new proxy or cloud paths, graphics-driver updates, or expansion of a viewing wall. An alert that appears eventually may still be an operational failure. Live video earns a response role only when its delay is measured through the same path and conditions the operator will actually use. ## Official reference - Axis Communications, [Latency in live network video surveillance](https://whitepapers.axis.com/en-us/latency-in-live-network-video-surveillance), June 2024. ## Primary reference - Name: Axis Communications: Latency in live network video surveillance - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/latency-in-live-network-video-surveillance - Source publication date: 2024-06-01 ## Citation and use Preferred citation: “Measure live-video delay before operators must act,” DSE Security, https://update.dsesecurity.com/updates/measure-sensor-to-screen-video-latency-before-response/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Measure TCP throughput with the path conditions that shape it > Interpret TCP throughput with round-trip time, path MTU, bottleneck bandwidth, loss, and host window behavior in view. - Canonical URL: https://update.dsesecurity.com/updates/measure-tcp-throughput-with-path-conditions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:40+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Explainer - DSE priority: Advisory - Topics: Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Interpret TCP throughput with round-trip time, path MTU, bottleneck bandwidth, loss, and host window behavior in view. ## Potentially affected Managed IP networks where teams need to validate end-to-end TCP performance across LAN, WAN, VPN, or cloud paths ## DSE recommendation Use a repeatable end-to-end method and preserve path conditions so throughput results remain comparable and actionable. ## Article A low TCP test result does not by itself prove that a circuit is undersized. Throughput emerges from the end hosts and the entire path, including delay, loss, path MTU, bottleneck rate, TCP windows, parallel flows, and competing traffic. ## Source fact: [IETF RFC 6349](https://www.rfc-editor.org/rfc/rfc6349.html) provides an informational framework for practical end-to-end TCP throughput testing in a managed IP network. It calls for establishing path characteristics such as path MTU, round-trip time, and bottleneck bandwidth, then relating those characteristics to TCP window requirements and measured transfer performance. The framework defines metrics intended to make results more interpretable than an isolated speed number. The method recognizes that TCP performance is affected by the bandwidth-delay product and retransmissions, and that host settings can constrain a test even when network capacity is available. It is designed to evaluate TCP throughput rather than only packet-forwarding capacity. The RFC is Informational, not an IETF Standards Track mandate or a promise that every application will achieve the test result. ## Boundary Synthetic tools may use different TCP implementations, numbers of streams, buffers, and data patterns than a production application. Encryption, storage, CPU, proxies, traffic shaping, Wi-Fi, VPN encapsulation, and cloud service limits can be the bottleneck. A test can also affect users if it fills a production link. Provider service-level measurements may define different methods and demarcation points. ## Applicability questions - What exact user or application transaction is the test meant to represent? - Where are the controlled endpoints relative to firewalls, VPNs, proxies, and provider handoffs? - What are the observed path MTU, round-trip time, bottleneck rate, and loss during the test window? - Do host CPU, storage, window scaling, offload, or security inspection limit the result? - How much test traffic can the production path safely tolerate? ## DSE recommendation: Define endpoint locations, direction, duration, stream count, protocol settings, traffic class, and acceptance criteria before testing. Verify path MTU and record round-trip time under low load. Measure available link and interface rates at each likely bottleneck. Run a conservative baseline, then increase load only within an approved window while monitoring live-user impact, loss, retransmission, CPU, and queues. Repeat in both directions and at comparable times. Use a controlled host pair before introducing application servers, then compare the real application separately. When results differ, change one variable at a time rather than labeling the carrier, firewall, or server as the cause. Coordinate provider testing at the contractual demarcation when a service-level dispute is involved. ## Verification and evidence Keep tool and OS versions, endpoint specifications, topology, routing path, MTU evidence, RTT samples, interface counters, TCP statistics, test parameters, timestamps, and raw results. A useful record includes retransmissions and host resource use alongside throughput. It should also state concurrent production load and known policy limits so a later comparison is like-for-like. ## Official references - [IETF RFC 6349](https://www.rfc-editor.org/rfc/rfc6349.html) ## Primary reference - Name: RFC 6349: Framework for TCP Throughput Testing - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6349.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Measure TCP throughput with the path conditions that shape it,” DSE Security, https://update.dsesecurity.com/updates/measure-tcp-throughput-with-path-conditions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Measure TPM lockout state before attempting another authorization > Use Manage TPM lockout to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/measure-tpm-lockout-before-another-authorization/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:55+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Use Manage TPM lockout to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Manage TPM lockout ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Measure TPM lockout state before attempting another authorization. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Manage TPM lockout](https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/manage-tpm-lockout) from Microsoft supports the following bounded statements: - The TPM enters lockout to resist tampering or repeated malicious authorization attempts. The research record locates this support at Opening overview. - During lockout it rejects authorization-dependent commands but preserves at least one owner attempt to reset lockout. The research record locates this support at Opening overview. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows only where the source and recorded environment align. ## What the source does not establish Use the version-specific TPM 1.2 or 2.0 recovery method and do not clear the TPM casually. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations Opening overview; Opening overview adjacent to the sanitized artifacts used for comparison. Prefer policy and feature state, security events, test detections, administrative assignments, exception approvals, and response tickets, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Manage TPM lockout](https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/manage-tpm-lockout) — Microsoft ## Primary reference - Name: Manage TPM lockout - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/manage-tpm-lockout - Source publication date: 2025-08-15 ## Citation and use Preferred citation: “Measure TPM lockout state before attempting another authorization,” DSE Security, https://update.dsesecurity.com/updates/measure-tpm-lockout-before-another-authorization/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Measure Windows Event Forwarding health—not just collector uptime > Windows Event Forwarding can collect selected operational and administrative events through subscriptions, but a running collector does not prove every source enrolled or delivered the required events. - Canonical URL: https://update.dsesecurity.com/updates/windows-event-forwarding-delivery-health/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:09+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Windows Event Forwarding can collect selected operational and administrative events through subscriptions, but a running collector does not prove every source enrolled or delivered the required events. ## Potentially affected Organizations using Windows Event Forwarding and Windows Event Collector for detection, investigation, or central Windows logging. ## DSE recommendation Define baseline and escalation subscriptions, monitor source enrollment and delivery latency, send canary events, and reconcile expected devices with collector state. ## Article Bottom line: Windows Event Forwarding (WEF) reads selected events from Windows devices and sends them to a Windows Event Collector. Microsoft presents baseline and suspect subscriptions as a way to balance coverage and volume. Operational trust requires proof of enrollment, filtering, delivery latency, capacity, retention, and downstream ingestion. ## Source fact: what Microsoft documents Microsoft’s [WEF intrusion-detection guidance](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection) describes forwarding selected operational and administrative events from organizational devices. The reference design uses a baseline subscription for broad enrollment and a suspect subscription for devices needing more context. The document covers source-initiated subscription design, collector configuration, event-selection considerations, delivery settings, security, and collector sizing concepts. It explains that WEF forwards events already generated on sources; it does not itself enable every audit category or create missing telemetry. Subscription queries, source configuration, WinRM, permissions, network access, collector capacity, and downstream handling all affect what arrives. ## What the source does not establish WEF does not guarantee lossless delivery, normalize events into detections, protect the collector from compromise, or preserve logs for a required retention period by itself. A healthy Windows Event Collector service does not prove that every expected endpoint is enrolled. Event volume estimates from one environment do not establish capacity for another. Forwarded events also remain only as useful as source audit policy and clock quality. ## Applicability questions - Which security and operational questions must the forwarded events answer? - Which workstations, servers, domain controllers, segmented networks, remote devices, and intermittent systems are expected sources? - Are required audit policies and event channels enabled on each source class? - What delivery latency, outage buffer, collector capacity, retention, and downstream SIEM availability are required? - How will a device be promoted to and removed from a higher-volume suspect subscription? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Define the minimum event set from investigation and detection needs, then validate source audit policy generates it. - Separate broad baseline collection from time-bounded high-context collection for suspect systems. - Inventory expected sources and reconcile them with subscription runtime state. Alert on never-seen, stale, and persistently failing sources. - Generate controlled canary events on representative devices and measure source-to-collector and collector-to-SIEM delay. - Capacity-test collectors, protect administration and stored logs, and document failover, backlog, and recovery behavior. ## Verification and evidence - Preserve subscription XML, source targeting, collector configuration, query changes, and approvals. - Record expected versus active sources, last event time, delivery failures, queue state, and canary latency. - Demonstrate required events from every device class and confirm downstream parsing retains key fields. - Exercise collector outage and restoration without assuming queued events will always cover the gap. ## Official references - [Use Windows Event Forwarding to help with intrusion detection](https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection) — Microsoft ## Primary reference - Name: Use Windows Event Forwarding to help with intrusion detection - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/operating-system-security/device-management/use-windows-event-forwarding-to-assist-in-intrusion-detection - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Measure Windows Event Forwarding health—not just collector uptime,” DSE Security, https://update.dsesecurity.com/updates/windows-event-forwarding-delivery-health/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Measure zero-trust maturity across five pillars before buying more tools > CISA’s maturity model organizes zero-trust progress across Identity, Devices, Networks, Applications and Workloads, and Data with visibility, automation, and governance spanning each pillar. - Canonical URL: https://update.dsesecurity.com/updates/zero-trust-maturity-five-pillar-assessment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:26:27+00:00 - Modified: 2026-07-19T21:26:27+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Information - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know CISA’s maturity model organizes zero-trust progress across Identity, Devices, Networks, Applications and Workloads, and Data with visibility, automation, and governance spanning each pillar. ## Potentially affected Leaders, architects, identity teams, endpoint teams, network defenders, application owners, data owners, and governance teams planning a staged zero-trust program. ## DSE recommendation Rate current practices with evidence, set risk-based targets by pillar, identify dependencies, prioritize measurable improvements, and reassess after material changes. ## Article A zero-trust roadmap can become a shopping list when an organization has not described its current state or desired security outcomes. CISA’s maturity model supplies a common structure for examining progress without pretending that every pillar moves at the same speed. ## How CISA organizes maturity Source fact: CISA Zero Trust Maturity Model Version 2.0 is organized into five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Three capabilities—Visibility and Analytics, Automation and Orchestration, and Governance—cut across the pillars. Source fact: The model describes Traditional, Initial, Advanced, and Optimal stages. CISA explains that maturity can differ across pillars and that the model is intended to help federal agencies develop zero-trust strategies and implementation plans. It is a reference model, not evidence that an organization is secure merely because it selects a maturity label. ## Rate practices with evidence DSE recommendation: assess a defined service or environment before attempting an enterprise-wide score. For each pillar and cross-cutting capability, record the operating practice, scope, owner, evidence, dependencies, exceptions, and last validation date. A purchased license or enabled feature is not enough; evidence should show that the intended access decision, telemetry, automation, or governance process actually operates. - Identity: review identity lifecycle, authentication, privilege, service identities, federation, and session decisions. - Devices: review inventory, ownership, health signals, configuration, isolation, and unsupported devices. - Networks: review discovery, segmentation, encrypted paths, policy enforcement, and traffic visibility. - Applications and workloads: review inventory, access, secure delivery, workload identity, dependencies, and runtime visibility. - Data: review inventory, classification, access, encryption, rights, loss controls, lifecycle, and recovery. ## Select targets by risk DSE recommendation: choose target outcomes based on the service’s impact, credible threats, obligations, architecture, feasibility, and operational constraints. Identify which improvements benefit several pillars—for example, reliable asset and identity inventories can strengthen policy, visibility, incident response, and governance. Give every roadmap item an accountable owner, dependency, milestone, validation method, operational safeguard, and rollback approach. Reassess after implementation, incidents, major architecture changes, provider changes, or evidence that a rating is no longer accurate. ## Applicability and limits CISA designed the model for federal agencies. Other organizations may adapt it, but should not imply CISA approval or certification. “Optimal” is a model stage, not zero residual risk, and forcing every environment toward the same target can create cost or operational harm. Use NIST SP 800-207 for architecture concepts and current product documentation for implementation. ## Official reference [CISA Zero Trust Maturity Model Version 2.0](https://www.cisa.gov/sites/default/files/2023-04/CISA_Zero_Trust_Maturity_Model_Version_2_508c.pdf) — five-pillar maturity and cross-cutting capability guidance. ## Primary reference - Name: CISA Zero Trust Maturity Model, Version 2.0 - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/2023-04/CISA_Zero_Trust_Maturity_Model_Version_2_508c.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Measure zero-trust maturity across five pillars before buying more tools,” DSE Security, https://update.dsesecurity.com/updates/zero-trust-maturity-five-pillar-assessment/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # MFA, passkeys, and authentication strength: what the terms mean > Understand authentication factors, MFA, one-time codes, cryptographic authenticators, passkeys, phishing resistance, and account recovery so stronger sign-in choices can be evaluated without calling any single method unhackable. - Canonical URL: https://update.dsesecurity.com/updates/mfa-passkeys-authentication-strength/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:09+00:00 - Modified: 2026-07-19T19:03:09+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Explainer - DSE priority: Information - Topics: Cybersecurity - Reading time: 2 minutes ## What you need to know Understand authentication factors, MFA, one-time codes, cryptographic authenticators, passkeys, phishing resistance, and account recovery so stronger sign-in choices can be evaluated without calling any single method unhackable. ## Potentially affected Business leaders, users, identity administrators, application owners, and teams selecting or deploying sign-in methods. ## DSE recommendation Inventory important applications and administrators, record their available authentication and recovery methods, and prioritize phishing-resistant options where supported. ## Article Authentication strength depends on more than whether a login is labeled “MFA.” The factors, protocol, device protection, enrollment, recovery, and helpdesk process all affect the result. Clear terminology helps organizations compare options without making absolute security claims. ## What the official source says Source fact: NIST SP 800-63B-4 defines requirements and recommendations for authentication and authenticator management. It describes authentication factors as something you know, something you have, or something you are. At Authentication Assurance Level 2, two distinct factors are required, and applications assessed at that level must offer a phishing-resistant option. NIST states that passwords and manually entered one-time passwords are not phishing-resistant. ## Terms in practical language - MFA: authentication using more than one distinct factor. Two passwords are still one factor type. - One-time code: a short-lived output from an app, token, text, or other method. It can improve protection over a password alone, but manual entry can still be relayed to a fraudulent sign-in page. - Cryptographic authenticator: a key-based method that proves control of a protected key without sending that private key to the verifier. - Passkey: a consumer-facing name commonly used for a FIDO/WebAuthn cryptographic credential. Some credentials remain on one device; others can synchronize through an account or platform. - Phishing resistance: protection created by the authentication protocol, rather than relying only on a user to recognize an impostor site. ## Deployment is a lifecycle DSE recommendation: begin with privileged administrators, remote access, email, finance, and other high-impact applications. Inventory what each application supports, then pilot the strongest practical option with representative users and devices. Document enrollment, additional authenticators, lost-device handling, replacement, revocation, offboarding, emergency access, and support verification. Recovery can become the weakest path. A strong sign-in method can be undermined if an attacker can convince support to reset it through a weaker process. Use documented identity-verification steps, limit who can reset strong authenticators, log changes, and review unexpected enrollment or recovery events. ## Important distinctions Not every MFA method is phishing-resistant, and not every passkey deployment has identical risk. Synchronized credentials introduce different availability, account-recovery, and device-ecosystem considerations than device-bound credentials. Application support, licensing, accessibility, shared-device use, offline needs, and business continuity may affect the rollout. No authenticator is “unhackable,” and stronger authentication does not eliminate malicious software, session theft, excessive permissions, or unsafe recovery. It should be one layer in a broader identity program. Practical next step: choose the ten most consequential accounts, record the current authentication and recovery path for each, and remediate the most exposed administrator or remote-access path first. ## Primary reference - Name: NIST SP 800-63B-4: Authentication and Authenticator Management - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/63/b/4/final - Source publication date: 2025-07-31 ## Citation and use Preferred citation: “MFA, passkeys, and authentication strength: what the terms mean,” DSE Security, https://update.dsesecurity.com/updates/mfa-passkeys-authentication-strength/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Microsoft 365 Copilot permissions readiness: fix oversharing before rollout > Microsoft 365 Copilot works within a user's existing permissions. That boundary does not correct excessive access: content already visible to a user may become easier to discover, so SharePoint, OneDrive, Teams, ownership, labels, and sharing need review first. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-365-copilot-permissions-readiness/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:04:22+00:00 - Modified: 2026-07-19T19:04:22+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Microsoft 365 Copilot works within a user's existing permissions. That boundary does not correct excessive access: content already visible to a user may become easier to discover, so SharePoint, OneDrive, Teams, ownership, labels, and sharing need review first. ## Potentially affected Organizations considering or expanding Microsoft 365 Copilot across users who can access SharePoint, OneDrive, Teams, Exchange, connected applications, and other Microsoft 365 data. ## DSE recommendation Inventory permissions and sharing, assign valid content owners, remediate broad access, confirm data-protection licensing and behavior, and pilot Copilot with representative users before wider license assignment. ## Article ## Permission-aware is not permission-correcting Microsoft states that Microsoft 365 Copilot operates within a user’s existing permissions and honors Microsoft 365 security, privacy, and compliance controls. It does not grant a user new permission to a file merely because they ask about it. However, existing access can be broader than owners realize. Search, sharing links, group membership, inherited permissions, abandoned sites, and old project spaces can leave users able to reach information they no longer need. Copilot can make authorized content easier to discover and synthesize. The readiness question is therefore not only whether Copilot respects permissions, but whether the current permissions represent the intended business boundary. ## Review the information estate before licenses - Identify SharePoint sites, Teams, Microsoft 365 Groups, and OneDrive locations with broad internal or external access. - Confirm that every active site has accountable owners and that inactive or ownerless sites have a disposition plan. - Inspect Anyone links, organization-wide links, large groups, nested membership, guest access, and content shared outside its original project. - Prioritize executive, finance, personnel, legal, security, customer, and merger or acquisition content. - Remove obsolete access through normal governance and validate that business workflows still function. OneDrive uses SharePoint Online as its underlying platform, so tenant sharing controls also influence personal work files. Microsoft specifically recommends reviewing sharing defaults, site ownership, unused sites, potentially overshared content, and controls for business-critical sites. ## Verify protection instead of assuming it Sensitivity labels, encryption, retention, data-loss prevention, audit, eDiscovery, restricted search, and advanced SharePoint controls have different prerequisites and licenses. A label name alone does not prove that encryption or access restrictions apply. Test the actual user experience with labeled, encrypted, shared, and externally accessible content. Microsoft notes that legacy Information Rights Management content is not used for Copilot grounding and recommends modern sensitivity-labeling approaches where appropriate. Review meeting, chat, email, plugin, connector, and third-party application scenarios separately. Each connected data source has its own permissions and governance model. Confirm current Microsoft 365 Copilot and workload licenses for every pilot user; possessing a base Microsoft 365 subscription does not automatically mean every Copilot or Purview feature is included. ## Pilot for information quality and security Select representative users from different roles, not only administrators. Use approved test prompts to check whether users can surface sensitive material they should not need, whether important records are missing because of poor organization, and whether citations lead to authoritative content. Teach users to inspect citations, handle generated content according to its sensitivity, and verify important outputs. Record findings, remediate permission causes, and retest before broad assignment. Continue reviewing guests, sharing links, site owners, stale groups, and Copilot audit data after launch. Copilot readiness is an ongoing information-governance program, not a one-time license deployment. ## Primary reference - Name: Microsoft Learn: Microsoft 365 Copilot data and compliance readiness - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/microsoft-365/copilot/microsoft-365-copilot-minimum-requirements-data-compliance - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Microsoft 365 Copilot permissions readiness: fix oversharing before rollout,” DSE Security, https://update.dsesecurity.com/updates/microsoft-365-copilot-permissions-readiness/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Microsoft 365 offboarding: secure access and preserve business records in the right order > Offboarding is an identity, device, records, and continuity workflow. Blocking sign-in is urgent, while mailbox, OneDrive, ownership, legal hold, forwarding, licensing, and account deletion decisions must follow an approved sequence. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-365-offboarding-secure-preserve-sequence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:04:22+00:00 - Modified: 2026-07-19T19:04:22+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Offboarding is an identity, device, records, and continuity workflow. Blocking sign-in is urgent, while mailbox, OneDrive, ownership, legal hold, forwarding, licensing, and account deletion decisions must follow an approved sequence. ## Potentially affected Microsoft 365 users who leave an organization or change roles, including cloud-only and directory-synchronized identities, managed devices, mailboxes, OneDrive data, Teams, groups, applications, and administrative access. ## DSE recommendation Use a time-bound HR and IT checklist that blocks access first, preserves required records, transfers ownership, addresses devices and applications, and removes licenses or accounts only after retention decisions are verified. ## Article ## Start with an authorized trigger and a precise time A reliable offboarding process begins with an approved request from the accountable business or HR owner. Record the identity, effective time, manager, employment status, device ownership, special legal instructions, and people responsible for each action. Urgent termination and planned departure can use the same checklist with different timing. At the effective time, prevent sign-in, reset credentials as appropriate, revoke active sessions, and remove privileged role eligibility or assignments. Review authentication methods, application passwords, registered devices, delegated access, enterprise applications, API credentials, and shared secrets owned by the person. If the identity is synchronized from on-premises Active Directory, make the authoritative lifecycle change in the source directory; Microsoft notes that deletion and restoration cannot be managed only in Microsoft 365 in that model. ## Protect devices and preserve evidence Decide whether each device is company-owned or personal before issuing retire, wipe, or lock actions. A full wipe and a selective organizational-data removal have materially different consequences, and support varies by enrollment platform. Preserve security evidence needed for an investigation before destructive actions. Records disposition must precede license removal and account deletion. Determine whether legal hold, retention, eDiscovery, regulatory, contractual, or litigation requirements apply. Those capabilities and retention results depend on licensing and configuration. Obtain legal or records-management direction when required; an IT convenience decision is not a substitute. - Preserve or transfer required mailbox data. Decide whether to convert the mailbox, delegate access, or configure forwarding based on an approved business need. - Grant an accountable successor access to required OneDrive content and transfer ownership of business files, sites, Teams, groups, shared mailboxes, applications, automations, and service documentation. - Remove the user from groups, Teams, distribution lists, shared resources, partner portals, line-of-business systems, VPN, physical access, and vendor services. - Communicate the replacement contact without exposing private employment information. - Remove or reassign licenses only after dependent data and service behavior are confirmed. - Delete the account only when the approved retention and continuity plan permits it. ## Treat retention windows as constraints, not backups Microsoft’s current offboarding guidance describes common 30-day retention and restoration windows for deleted user mailbox and OneDrive content, with different behavior when a license is removed but the account remains. Holds, tenant settings, subscription changes, and future product changes can alter outcomes. Verify the current Microsoft documentation and the tenant’s actual configuration before deletion. A published retention window should not be the only copy of business-critical information. ## Close with evidence and a follow-up Record timestamps, successful session revocation, data custodians, forwarding expiration, license changes, device actions, exceptions, and the final account state. Schedule a follow-up to remove temporary forwarding or delegated access and confirm that no critical workflow depended on the departed identity. Offboarding is complete when access is closed, necessary records are controlled, business ownership is transferred, and temporary measures have an end date. ## Primary reference - Name: Microsoft Learn: Remove a former employee and secure data - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/microsoft-365/admin/add-users/remove-former-employee?view=o365-worldwide - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Microsoft 365 offboarding: secure access and preserve business records in the right order,” DSE Security, https://update.dsesecurity.com/updates/microsoft-365-offboarding-secure-preserve-sequence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Microsoft Defender for Business: understand the protection and the boundaries > Microsoft Defender for Business brings endpoint prevention, detection, investigation, and response capabilities to eligible organizations with up to 300 users. Onboarding, configuration, licensing, monitoring, and server coverage still require deliberate planning. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-defender-for-business-capabilities-and-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:57+00:00 - Modified: 2026-07-19T19:29:33+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Explainer - DSE priority: Information - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Microsoft Defender for Business brings endpoint prevention, detection, investigation, and response capabilities to eligible organizations with up to 300 users. Onboarding, configuration, licensing, monitoring, and server coverage still require deliberate planning. ## Potentially affected Organizations evaluating the standalone Defender for Business subscription or Microsoft 365 Business Premium, and administrators comparing it with Defender for Endpoint enterprise plans. ## DSE recommendation Confirm tenant size, user and server licensing, supported platforms, management authority, existing antivirus behavior, and required enterprise features before onboarding a representative pilot. ## Article ## Endpoint security designed for a defined market Microsoft Defender for Business is based on Defender for Endpoint and is designed for small and medium-sized organizations with up to 300 users. Microsoft describes capabilities that include next-generation protection, attack-surface reduction, an optimized endpoint detection and response experience, automated investigation and remediation, and core vulnerability-management capabilities. It is available as a standalone subscription and is included with Microsoft 365 Business Premium. The service is not identical to Defender for Endpoint Plan 2. Microsoft positions Defender for Business as a simplified experience with a mixture of Plan 1, selected Plan 2, and small-business-focused capabilities. Requirements such as advanced hunting depth, longer retention, threat-expert services, or enterprise licensing should be compared directly with the current plan documentation rather than inferred from the shared Defender portal. ## Licensing and scale boundaries matter - Microsoft states that Defender for Business is intended for organizations with no more than 300 users. - Its current FAQ permits up to five client devices per user license. - Windows and Linux servers require separate server licensing. Microsoft documents a maximum of 60 Defender for Business server add-on licenses per eligible subscription; larger server estates need another licensing approach. - Microsoft does not support a mixed Defender for Business and Defender for Endpoint experience in the same tenant in the way administrators might expect. The subscription design should be reviewed before combining plans. Licensing and product terms can change. Confirm the tenant’s active subscriptions and current Microsoft product terms before making a purchase or coverage statement. ## Onboarding is the beginning, not the outcome A device must be onboarded and reporting before the service can protect and investigate it as intended. Plan a pilot across Windows, macOS, and mobile platforms that are actually in scope. Verify sensor health, antivirus mode, cloud-delivered protection, alert flow, tamper protection, update health, and who owns investigation and remediation. Servers should never be assumed covered by a user subscription. Existing non-Microsoft antivirus can affect Microsoft real-time protection and may leave a device displayed as unprotected. Some configurations also require Intune. Microsoft notes, for example, that certain attack-surface-reduction and controlled-folder-access settings are configured through the Intune admin center. The current FAQ also documents only one uniform web-content-filtering policy per Defender for Business organization and limitations around custom ASR configuration without Intune. ## Operate the service continuously Define severity-based alert handling, escalation coverage, device-isolation authority, false-positive review, and recovery steps. Review security recommendations in the context of application compatibility and business risk instead of applying every recommendation automatically. Monitor devices that stop reporting, failed onboarding, unresolved incidents, risky software, and exclusions. Defender for Business can provide substantial endpoint-security capability, but it is neither a license for every Microsoft security workload nor a fully managed response service by default. The effective result depends on complete coverage, correct settings, supported devices, trained operators, and tested response procedures. ## Official references - [Defender for Business overview](https://learn.microsoft.com/en-us/defender-business/mdb-overview) — intended market and included protection capabilities. - [Defender for Business FAQ](https://learn.microsoft.com/en-us/defender-business/mdb-faq) — user and device limits, server licensing, web-filtering scope, ASR configuration, and mixed-license behavior. - [Defender for Endpoint subscription settings](https://learn.microsoft.com/en-us/defender-endpoint/defender-endpoint-subscription-settings) — Microsoft’s mixed-licensing boundary for Defender for Business. - [Attack surface reduction in Defender for Business](https://learn.microsoft.com/en-us/defender-business/mdb-asr) — available controls and supported configuration paths. ## Primary reference - Name: Microsoft Learn: What is Microsoft Defender for Business? - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-business/mdb-overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Microsoft Defender for Business: understand the protection and the boundaries,” DSE Security, https://update.dsesecurity.com/updates/microsoft-defender-for-business-capabilities-and-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Microsoft Entra Conditional Access: plan controls without locking out the tenant > Conditional Access can combine identity, device, application, and location signals to enforce access controls. Report-only evaluation, emergency access, test users, licensing checks, and phased activation are essential to avoid unintended lockout. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-entra-conditional-access-safe-deployment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:04:22+00:00 - Modified: 2026-07-19T19:04:22+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Conditional Access can combine identity, device, application, and location signals to enforce access controls. Report-only evaluation, emergency access, test users, licensing checks, and phased activation are essential to avoid unintended lockout. ## Potentially affected Microsoft Entra tenants planning to replace security defaults or enforce multifactor authentication, compliant devices, approved applications, authentication strength, or risk-based access decisions. ## DSE recommendation Inventory existing policies and dependencies, protect emergency access, build a test matrix, use report-only mode and sign-in logs, and enable one well-scoped control at a time. ## Article ## A powerful policy engine needs a recovery design Microsoft Entra Conditional Access evaluates signals such as user, device, application, location, authentication context, and risk to decide whether to grant, block, or require additional controls. Its flexibility is valuable, but a broad or contradictory policy can interrupt every user and administrator at once. Begin by documenting security defaults, existing Conditional Access policies, per-user multifactor authentication, authentication methods, legacy protocols, service accounts, workload identities, device enrollment, guest access, and applications that do not support modern authentication. Security defaults and Conditional Access are different approaches and are not intended to operate together; moving from one to the other requires a complete replacement plan. ## Protect access before enforcing access Maintain emergency-access accounts that are cloud-native, securely stored, monitored, and excluded from policies that could block their use. Test them on a schedule. Report-only policies do not block sign-in, so Microsoft notes that they do not need the same exclusion, but exclusions must be correct before enforcement. Do not use an ordinary daily administrator as the recovery path. - Create a nonadministrator test user and representative pilot groups. - Confirm that required authentication methods are registered before enforcing them. - Build a matrix covering administrators, standard users, guests, service scenarios, managed and unmanaged devices, mobile and desktop clients, trusted and untrusted locations, and emergency access. - Create narrowly scoped policies in report-only mode. Templates also begin in report-only mode by default. - Review sign-in logs, policy impact, and the What If tool. A simulation is helpful but does not replace real pilot sign-ins. - Communicate the change and support path, then enable one control for the pilot before broader assignment. Microsoft recommends observing report-only behavior before enforcement and currently suggests at least a week for each policy. The appropriate duration depends on sign-in frequency and business cycles; a monthly application needs a longer test than a daily one. ## Understand licensing and policy interactions Conditional Access generally requires Microsoft Entra ID P1 or an eligible suite such as Microsoft 365 Business Premium. User-risk and sign-in-risk policies require Entra ID Protection capabilities associated with P2. Controls that consume signals from Intune, Purview, workload identities, or other products require the relevant licenses and configuration. Verify entitlements for every targeted user rather than assuming that portal access proves licensing. Evaluate the combined result of all policies. An exclusion in one policy does not prevent another policy from requiring a control. Avoid broad permanent exclusions; use named ownership and review dates. For workloads that cannot satisfy an interactive control, redesign the authentication flow instead of weakening protection for all users. ## Make rollback immediate and observable Record the previous state and policy identifiers before activation. If access fails unexpectedly, disable the new policy or remove the affected assignment, confirm recovery through sign-in logs, and investigate before reenabling. Keep policy names, purpose, owner, included and excluded populations, dependencies, and last test date documented. Conditional Access is most reliable as a small set of comprehensible controls, not an accumulation of overlapping experiments. ## Primary reference - Name: Microsoft Learn: Plan a Conditional Access deployment - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/conditional-access/plan-conditional-access - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Microsoft Entra Conditional Access: plan controls without locking out the tenant,” DSE Security, https://update.dsesecurity.com/updates/microsoft-entra-conditional-access-safe-deployment/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Microsoft Entra Retires Native SMS and Voice MFA in 2027—Prepare for Passkeys Now > Beginning September 1, 2026, Microsoft will start auto-enabling passkeys and registration nudges for SMS- and voice-enabled users in public-cloud Microsoft Entra ID tenants. On February 1, 2027, Microsoft-provided SMS and voice delivery ends; organizations must migrate affected users to a phishing-resistant method or configure a customer-managed telecom provider. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-entra-native-sms-voice-retirement-passkeys-2027/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-11T20:44:46+00:00 - Modified: 2026-08-11T20:44:46+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Briefing - DSE priority: Important - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 5 minutes ## What you need to know Beginning September 1, 2026, Microsoft will start auto-enabling passkeys and registration nudges for SMS- and voice-enabled users in public-cloud Microsoft Entra ID tenants. On February 1, 2027, Microsoft-provided SMS and voice delivery ends; organizations must migrate affected users to a phishing-resistant method or configure a customer-managed telecom provider. ## Potentially affected Microsoft Entra ID and Microsoft 365 administrators; identity, security, compliance, and service-desk teams; public-cloud tenants with users enabled for SMS or voice in Authentication Methods Policy or legacy MFA settings. SSPR and B2B/internal guest scenarios also require review. ## DSE recommendation Inventory affected users, select and pilot replacement methods, communicate the change, and complete migration before February 1, 2027. ## Article Bottom line: Beginning September 1, 2026, Microsoft will start rolling out passkeys as the default authentication experience for users enabled for SMS or voice in public-cloud Microsoft Entra ID tenants. On February 1, 2027, Microsoft-provided telecom delivery for SMS and voice will end. Affected organizations should move users to a phishing-resistant method before that deadline or, where there is a documented need to retain SMS or voice, configure a customer-managed telecom provider. ## Source fact: what Microsoft is changing Microsoft is not eliminating every possible use of SMS and voice. It is retiring the native telecom delivery that Microsoft currently provides for those methods in Entra ID. Microsoft says SMS and voice provide weaker protection than phishing-resistant credentials because telephone channels can be phished, intercepted, redirected, or compromised through attacks such as SIM swapping. Microsoft recommends passkeys as the primary migration path. Entra ID supports synced passkeys and device-bound credentials, including Microsoft Authenticator passkeys, Entra passkeys on Windows, and FIDO2 security keys. Other phishing-resistant options may also fit particular environments. ## Key dates DateMicrosoft changeWhat organizations should know September 1, 2026Microsoft begins the public-cloud rollout. As it reaches an organization, users enabled for SMS or voice in the Authentication Methods Policy or legacy MFA settings are auto-enabled for passkeys. The registration campaign is placed in a Microsoft-managed state for those users, who are nudged to register after completing MFA.This is a rollout, not a claim that every Entra user changes simultaneously. The automatic cohort is users currently enabled for SMS or voice. September 18, 2026Microsoft plans to publish supported telecom providers, deployment guidance, pricing, and commercial terms in the Microsoft Security Store.Organizations with a genuine regulatory, technical, or operational need for SMS or voice can begin comparing options. October 30, 2026Admins are scheduled to be able to select and configure a supported customer-managed telecom provider.Microsoft recommends testing the provider with a pilot group before broad deployment. Partner telecom costs are the customer’s responsibility. February 1, 2027Microsoft-provided SMS and voice delivery ends in public-cloud Entra ID.Without a configured customer-managed provider, Microsoft-managed SMS or voice can no longer satisfy authentication requirements. After February 1, 2027A user whose only available MFA method is SMS or voice receives a blocking passkey-registration prompt and must register before continuing sign-in.There is no opt-out from this enforcement. ## Scope and important exceptions - The published dates apply to Microsoft Entra ID public-cloud environments only. Other cloud environments will receive separate dates and guidance. - The native SMS and voice retirement applies across Entra, including self-service password reset. - B2B and internal guest users are included in the retirement scope. Microsoft says passkey support for those users is planned by the end of calendar year 2026. - If a tenant has no users enabled for SMS or voice, Microsoft says no action is required for this change. Administrators should verify that condition rather than assume it. ## The temporary opt-out is not a migration plan Microsoft Learn documents a temporary opt-out for the automatic passkey enablement and registration-campaign rollout between September 1, 2026, and February 1, 2027. It is configured through Microsoft Graph using the passkeyDynamicMigration opt-out setting and requires the Policy.ReadWrite.AuthenticationMethod permission. Microsoft also notes that moving users out of SMS or voice in the Authentication Methods Policy before September 1 prevents the automatic passkey nudge for those users. The opt-out does not postpone retirement. Beginning February 1, 2027, the enforcement timeline applies regardless of that setting, and Microsoft provides no opt-out from the final requirement. Because the documented configuration uses a Microsoft Graph beta endpoint, administrators should confirm the current Microsoft procedure immediately before making the change. ## DSE recommendation: migration action plan The following steps are DSE recommendations for managing the transition. Microsoft’s announced requirements and dates are described above. - Inventory now. Identify every user enabled for SMS or voice in both the Authentication Methods Policy and legacy MFA settings. Review actual method-registration and usage data, SSPR dependencies, guest users, privileged roles, shared-device workflows, and recovery processes. - Choose the target experience. Prefer passkeys where supported, then document approved alternatives for devices or workflows that need a different phishing-resistant method. - Pilot before expanding. Test registration, normal sign-in, device replacement, account recovery, temporary access, and help-desk escalation with representative users and devices. - Drive enrollment deliberately. Enable the target method, use a controlled registration campaign, and give users device-specific instructions before prompts appear. Track completion instead of treating policy enablement as proof of adoption. - Prioritize privileged and high-risk users. Move administrators, executives, finance personnel, remote-access users, and other frequently targeted groups first. Apply authentication-strength controls in stages after confirming recovery paths. - Use the temporary opt-out only with an owner and exit date. It can create implementation time, but it should not become a reason to defer the project. - Retain telecom only for a documented exception. If SMS or voice is necessary, review provider information on September 18, configure and pilot beginning October 30, and complete deployment before Microsoft’s February deadline. - Finish early. DSE recommends completing production migration by December 15, 2026, leaving time to resolve exceptions and support users before enforcement. ## What users should expect Users already signing in with a passkey, Windows Hello for Business, a FIDO2 security key, or another approved phishing-resistant method can continue using it. Users who remain enabled for SMS or voice may see a prompt to register a passkey after completing MFA as the rollout reaches their organization. Microsoft currently documents unlimited snoozes during the pre-retirement registration campaign, but the post-retirement prompt for users who have no other method will be blocking. ## Related DSE guidance - [MFA, passkeys, and authentication strength](https://update.dsesecurity.com/updates/mfa-passkeys-authentication-strength/) - [Deploy phishing-resistant authentication by user and device readiness](https://update.dsesecurity.com/updates/microsoft-entra-phishing-resistant-authentication-rollout/) ## Official reference - [Passkeys by default and retirement of Microsoft-provided SMS and voice authentication](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement), Microsoft Learn, last updated August 10, 2026 - [Frequently asked questions about SMS and voice retirement](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement-faq), Microsoft Learn - [Microsoft Entra ID security updates: Passkeys are the default authentication method in Entra ID](https://www.microsoft.com/en-us/security/blog/2026/07/13/microsoft-entra-id-security-updates-passkeys-are-the-default-authentication-method-in-entra-id/), Microsoft Security Blog, published July 13, 2026 Source review completed August 11, 2026. Microsoft may revise implementation details; confirm current guidance before changing production policy. ## Primary reference - Name: Microsoft Learn: Passkeys by default and retirement of Microsoft-provided SMS and voice authentication - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement - Source publication date: 2026-08-10 ## Citation and use Preferred citation: “Microsoft Entra Retires Native SMS and Voice MFA in 2027—Prepare for Passkeys Now,” DSE Security, https://update.dsesecurity.com/updates/microsoft-entra-native-sms-voice-retirement-passkeys-2027/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Microsoft Intune compliance: design the signal before enforcing access > Intune compliance policies evaluate whether managed devices meet defined requirements. Blocking access requires a coordinated Microsoft Entra Conditional Access policy, suitable licensing, representative testing, and a supportable path back to compliance. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-intune-compliance-design-before-enforcement/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:57+00:00 - Modified: 2026-07-19T19:29:33+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Intune compliance policies evaluate whether managed devices meet defined requirements. Blocking access requires a coordinated Microsoft Entra Conditional Access policy, suitable licensing, representative testing, and a supportable path back to compliance. ## Potentially affected Organizations using Microsoft Intune to evaluate Windows, macOS, iOS, iPadOS, Android, Linux, or supported partner-managed device signals for access decisions. ## DSE recommendation Define platform-specific requirements, configure tenant compliance behavior, pilot notifications and grace periods, then test Conditional Access in report-only mode before enforcement. ## Article ## Compliance reports posture; Conditional Access enforces access An Intune compliance policy defines conditions a device must meet and reports the resulting status to Intune and Microsoft Entra ID. Examples can include operating-system version, encryption, password requirements, device health, or a threat level supplied by Microsoft Defender for Endpoint or a supported mobile-threat-defense partner. The available settings vary by platform. Compliance by itself does not automatically block a device from Microsoft 365. Microsoft Entra Conditional Access uses the compliance signal to make an access decision when a policy requires a device to be marked compliant. That separation matters during design and troubleshooting: Intune evaluates the device, while Entra enforces the sign-in control. ## Decide how unknown and failing devices should behave Review the tenant-wide compliance settings before creating platform policies. In particular, decide how devices with no assigned compliance policy should be classified. A permissive choice can admit unmanaged gaps; an immediate restrictive choice can interrupt users before enrollment and assignments are ready. Every compliance policy includes an action that marks a failing device noncompliant. Microsoft documents an immediate default, but administrators can define grace periods and add supported actions such as user email or push notifications, remote lock, or placing a device on a retire list. Not every action is available on every platform. A notification should explain the failed requirement, safe remediation steps, the enforcement time, and how to obtain support. - Inventory device platforms, ownership models, enrollment methods, and business-critical applications. - Create the minimum common requirements first, then add platform-specific controls after measuring the result. - Assign policies to a test group and examine errors, conflicts, devices without a policy, and check-in timing. - Configure noncompliance notifications and a realistic grace period for issues users can fix. - Create the corresponding Conditional Access policy in report-only mode and test managed, unmanaged, compliant, noncompliant, guest, and emergency-access scenarios. - Enforce in phases while monitoring sign-in and compliance reports. ## Confirm licensing and management boundaries Users or devices benefiting from Intune generally require an appropriate Intune license. Device-only licensing has limitations, including no Conditional Access or user-based app protection. Device-based Conditional Access requires eligible Microsoft Entra ID P1 or P2 licensing; risk-based controls require additional P2 capabilities. Exact entitlements depend on the subscriptions and workload, so verify the tenant’s current licensing before promising a control. Compliance is a point-in-time service signal, not proof that a device is permanently secure. Check-in frequency, stale records, duplicate enrollments, operating-system support, and third-party integrations affect the result. Maintain exception ownership, remove retired devices, and test the path from noncompliant back to compliant so enforcement remains both protective and recoverable. ## Official references - [Device compliance policies in Microsoft Intune](https://learn.microsoft.com/en-us/intune/device-security/compliance/overview) — compliance concepts, settings, and platform scope. - [Actions for noncompliant devices](https://learn.microsoft.com/en-us/intune/device-security/compliance/configure-noncompliance-actions) — default timing, grace periods, notifications, and supported actions. - [Microsoft Intune licensing](https://learn.microsoft.com/en-us/intune/fundamentals/licensing) — user, device, and device-only license boundaries. - [Device-based Conditional Access](https://learn.microsoft.com/en-us/intune/device-security/conditional-access-integration/device-based-policies) — Entra licensing and the compliance-signal enforcement flow. ## Primary reference - Name: Microsoft Learn: Device compliance policies in Microsoft Intune - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/intune/device-security/compliance/overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Microsoft Intune compliance: design the signal before enforcing access,” DSE Security, https://update.dsesecurity.com/updates/microsoft-intune-compliance-design-before-enforcement/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Microsoft Teams Phone readiness: validate licensing, network, calling, and emergency workflows > Teams Phone deployment combines Microsoft licensing, PSTN connectivity, number management, network quality, devices, policies, emergency calling, and support. A successful Teams pilot does not by itself prove production voice readiness. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-teams-phone-production-readiness/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:04:22+00:00 - Modified: 2026-07-19T19:29:33+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Teams Phone deployment combines Microsoft licensing, PSTN connectivity, number management, network quality, devices, policies, emergency calling, and support. A successful Teams pilot does not by itself prove production voice readiness. ## Potentially affected Organizations planning Microsoft Teams Phone for users, common areas, call queues, auto attendants, remote workers, branch offices, or migration from an existing telephone system. ## DSE recommendation Choose the PSTN and licensing model, inventory call flows and numbers, assess every network location, design emergency calling, pilot representative users and devices, and prove support and rollback before porting production numbers. ## Article ## Separate Phone System capability from telephone service Teams Phone provides cloud phone-system capabilities, but external calling also requires a Public Switched Telephone Network connection. Microsoft documents several models: Microsoft Calling Plan, Operator Connect, Teams Phone Mobile, and Direct Routing. Availability, carrier responsibility, number management, emergency calling, support, and technical complexity differ among them. A Teams Phone license does not automatically supply every user or service number, calling plan, shared-device right, conferencing feature, or resource-account requirement. Confirm the current licensing for users, shared spaces, Teams Rooms, auto attendants, call queues, and any advanced features. Assign resource-account licenses only to resource accounts, not ordinary users. ## Inventory the existing voice service Document every user number, toll-free and service number, auto attendant, call queue, hunt group, voicemail path, fax, paging endpoint, analog line, elevator or alarm dependency, contact-center workflow, recording requirement, and carrier contract. Not every legacy or life-safety device should be assumed compatible with cloud voice. Establish an approved alternative where Teams is not supported or suitable. Build and test dial plans, caller identification, outbound restrictions, delegation, forwarding, after-hours routing, holidays, overflow, voicemail, and failure behavior. Number-porting dates and letters of authorization require carrier coordination; do not cancel the previous service before the port and fallback plan are confirmed. ## Assess the network as a real-time service Microsoft’s Teams network guidance calls for reachable service endpoints, working external DNS, suitable NAT capacity, efficient routing, and support for UDP and long-lived WebSocket traffic. Evaluate bandwidth, latency, jitter, packet loss, Wi-Fi coverage, firewall inspection, proxies, VPN hairpinning, and internet resilience at every location and for remote users. The Teams Network Planner, Call Quality Dashboard, and per-user call analytics can support planning and operations. - Prefer local, efficient egress to Microsoft rather than backhauling media through a distant data center. - Evaluate split tunneling with the VPN and security teams; implementation depends on the VPN and risk design. - Use QoS on managed network segments when the design calls for it, then verify markings and queuing end to end. - Pilot wired, wireless, remote, branch, and high-call-volume scenarios with representative certified devices. ## Engineer emergency calling and continuity Emergency locations and their assignment are required parts of the design, and responsibility varies by PSTN option and jurisdiction. Dynamic emergency calling can use network topology to determine location and notify designated personnel, but it must be configured and tested according to current Microsoft, carrier, and legal guidance. Do not place unapproved live emergency test calls; use supported test methods and coordinate with the provider. Define behavior during internet, power, Microsoft service, carrier, Session Border Controller, and local network failures. Document alternate calling methods, support contacts, escalation authority, and how critical users operate during an outage. ## Use a controlled migration gate Pilot internal and external calling, emergency test workflows, transfers, queues, attendants, voicemail, device sign-in, remote use, and call-quality monitoring. Confirm help-desk procedures and user communication. Port production numbers in controlled groups with a staffed validation bridge and explicit rollback or escalation criteria. Continue monitoring quality and call-routing outcomes after migration; voice readiness is an operational commitment, not a completed setup wizard. ## Official references - [Set up Teams Phone](https://learn.microsoft.com/en-us/microsoftteams/setting-up-your-phone-system) — Microsoft’s deployment roadmap. - [PSTN connectivity options](https://learn.microsoft.com/en-us/microsoftteams/pstn-connectivity) — Calling Plan, Operator Connect, Teams Phone Mobile, and Direct Routing responsibilities. - [Prepare the network for Teams](https://learn.microsoft.com/en-us/microsoftteams/prepare-network) — endpoints, routing, NAT, VPN, monitoring, and real-time media considerations. - [Implement Quality of Service in Teams](https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams) — traffic marking and managed-network guidance. - [Plan and configure dynamic emergency calling](https://learn.microsoft.com/en-us/microsoftteams/configure-dynamic-emergency-calling) — location, routing, notification, and supported test methods. ## Primary reference - Name: Microsoft Learn: Set up Teams Phone in your organization - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/microsoftteams/setting-up-your-phone-system - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Microsoft Teams Phone readiness: validate licensing, network, calling, and emergency workflows,” DSE Security, https://update.dsesecurity.com/updates/microsoft-teams-phone-production-readiness/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Migrate eligible services to device-bound dMSA identities > Use Delegated Managed Service Accounts overview in Windows Server 2025 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/migrate-eligible-services-to-device-bound-dmsa/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:41+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Delegated Managed Service Accounts overview in Windows Server 2025 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Delegated Managed Service Accounts overview in Windows Server 2025 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Migrate eligible services to device-bound dMSA identities. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Delegated Managed Service Accounts overview in Windows Server 2025](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-overview) from Microsoft supports the following bounded statements: - A dMSA can migrate a traditional service account to managed randomized keys while disabling the original password. The research record locates this support at Opening overview. - dMSA authentication is bound to machine identities explicitly mapped in Active Directory. The research record locates this support at Opening overview. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles only where the source and recorded environment align. ## What the source does not establish dMSA requires Windows Server 2025 support and application compatibility; migration must be reversible. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from Opening overview; Opening overview to the observed environment. Useful domain evidence includes directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Delegated Managed Service Accounts overview in Windows Server 2025](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-overview) — Microsoft ## Primary reference - Name: Delegated Managed Service Accounts overview in Windows Server 2025 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-overview - Source publication date: 2025-05-30 ## Citation and use Preferred citation: “Migrate eligible services to device-bound dMSA identities,” DSE Security, https://update.dsesecurity.com/updates/migrate-eligible-services-to-device-bound-dmsa/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Migrate legacy LAPS with bounded side-by-side coexistence > Use Prepare for Windows Local Administrator Password Solution (LAPS) Deployment and Migration to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/migrate-legacy-laps-with-bounded-coexistence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:59+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Prepare for Windows Local Administrator Password Solution (LAPS) Deployment and Migration to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Prepare for Windows Local Administrator Password Solution (LAPS) Deployment and Migration ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Migrate legacy LAPS with bounded side-by-side coexistence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Prepare for Windows Local Administrator Password Solution (LAPS) Deployment and Migration](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-migration) from Microsoft supports the following bounded statements: - Microsoft documents migration from legacy Microsoft LAPS to Windows LAPS. The research record locates this support at Opening overview. - Side-by-side coexistence is possible only when the two policies target different local accounts, and migration away from legacy LAPS remains the goal. The research record locates this support at Opening overview. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios and the conditions the source actually describes. ## What the source does not establish Monitor successful transition before removing legacy software or policy. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios are in and out of scope? - Which condition in Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Opening overview. Favor policy exports, directory access-control entries, sanitized client events, rotation tests, retrieval authorization, and exception records, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Prepare for Windows Local Administrator Password Solution (LAPS) Deployment and Migration](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-migration) — Microsoft ## Primary reference - Name: Prepare for Windows Local Administrator Password Solution (LAPS) Deployment and Migration - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-scenarios-migration - Source publication date: 2025-05-16 ## Citation and use Preferred citation: “Migrate legacy LAPS with bounded side-by-side coexistence,” DSE Security, https://update.dsesecurity.com/updates/migrate-legacy-laps-with-bounded-coexistence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Migrate monitoring to SNMPv3 without losing the alerts operations depend on > SNMPv3 can add authentication, integrity, privacy, and scoped access, but a rushed cutover can silently drop polling or notifications. Migrate by device class, verify manager support, test both directions, and retain rollback. - Canonical URL: https://update.dsesecurity.com/updates/migrate-monitoring-to-snmpv3-without-losing-alerts/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:54:00+00:00 - Modified: 2026-08-17T19:22:10+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know SNMPv3 can add authentication, integrity, privacy, and scoped access, but a rushed cutover can silently drop polling or notifications. Migrate by device class, verify manager support, test both directions, and retain rollback. ## Potentially affected Network and infrastructure monitoring; switches, routers, firewalls, wireless, UPS and environmental systems; network-management stations; credentials; access views; polling; traps and informs; dashboards; and alert routing. ## DSE recommendation Inventory SNMP dependencies, choose supported security levels, define scoped views, prepare credential custody, pilot polling and notifications, compare results in parallel, cut over by class, and verify removal of legacy access. ## Article ## Source facts: SNMPv3 separates security and access decisions [RFC 3414](https://www.rfc-editor.org/rfc/rfc3414.html) defines the User-based Security Model for SNMPv3. It describes mechanisms for data integrity, data-origin authentication, protection against certain replay and delay conditions through timeliness checks, and data confidentiality when privacy is used. SNMPv3 supports different security levels, so simply selecting version 3 does not prove that authentication or privacy is enabled. [RFC 3415](https://www.rfc-editor.org/rfc/rfc3415.html) defines the View-based Access Control Model. VACM can control which management information a principal may read, write, or receive through notifications based on security model, name, level, context, and configured views. The security model and the access-control model address related but different decisions. The RFCs define protocol architecture. They do not certify that every device implements the same authentication and privacy algorithms, supports the same notification behavior, exposes the same objects, or interoperates with a chosen network-management platform. A migration therefore needs device-specific evidence and operational comparison. ## DSE recommendation: migrate one verified monitoring contract at a time Treat each monitored device class as a contract: which objects are polled, which notifications are sent, which security level protects them, who owns credentials, and what constitutes healthy coverage. - Inventory the current dependency. Record device model, firmware, management address, SNMP version, communities or users, manager addresses, transport filtering, polling intervals, object identifiers, write use if any, traps or informs, dashboards, alert thresholds, escalation paths, and business service dependency. - Verify implementation support. Check current vendor and monitoring-platform documentation for supported security levels, authentication and privacy algorithms, engine-ID behavior, user provisioning, access views, contexts, traps, informs, and credential handling. Do not assume the strongest configuration shown by one device exists on another. - Design least-access views. Separate read-only monitoring from any administrative write use. Limit management sources at the network layer and expose only the management information needed for the approved workflow where the platform permits. Document exceptions for devices with coarse access control. - Protect the credentials. Generate unique, strong secrets according to platform limits, store them in an approved secrets system, restrict retrieval, avoid command histories and tickets, define rotation, and identify how localized keys or engine-ID changes affect recovery and replacement. - Pilot both directions. Test manager-to-device polling and device-to-manager notifications. Confirm authentication, privacy, time synchronization, object values, interface identity, notification source, alert creation, acknowledgement, and escalation. Include device reboot, manager restart, credential failure, and network interruption. - Run a measured parallel period. Where supported and safe, compare legacy and SNMPv3 polling for gaps, error rates, latency, counters, missing objects, duplicate alerts, and notification delivery. Define acceptance criteria and a rollback window before changing production monitoring. - Cut over and remove old trust. Move by device class or site, verify dashboards and alerts with operations, then disable old communities, users, access lists, and firewall paths. Search configuration backups and monitoring exports for residual shared secrets and document any temporary exception with an expiry. Notification migration deserves its own acceptance record. Polling can appear healthy while traps or informs fail because of destination, credentials, engine identity, network policy, source addressing, or receiver configuration. Generate approved test notifications and prove they create the expected incident, routing, escalation, and acknowledgement rather than stopping at packet receipt. Factual boundary: The cited RFCs define SNMPv3 USM and VACM; they do not prove that a particular device, cipher, manager, polling module, trap receiver, or firmware is compatible. Some platforms implement different security models. Validate supported algorithms and recovery behavior for each class. Measure devices still using legacy access, polls without authentication and privacy where required, notification test success, stale credentials, excessive views, parallel-run differences, and exceptions past due. Security has not improved if the migration removes the alerts needed to operate the environment. ## Official references - RFC Editor, [RFC 3414: User-based Security Model for version 3 of the Simple Network Management Protocol](https://www.rfc-editor.org/rfc/rfc3414.html). - RFC Editor, [RFC 3415: View-based Access Control Model for the Simple Network Management Protocol](https://www.rfc-editor.org/rfc/rfc3415.html). ## Primary reference - Name: RFC 3414: User-based Security Model for SNMPv3 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3414.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Migrate monitoring to SNMPv3 without losing the alerts operations depend on,” DSE Security, https://update.dsesecurity.com/updates/migrate-monitoring-to-snmpv3-without-losing-alerts/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Migrate sensor v2 only after checking sensor v3 feature limits > Use Migrate from Defender for Identity sensor v2 to sensor v3.x to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/migrate-sensor-v2-after-checking-v3-feature-limits/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:22+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Migrate from Defender for Identity sensor v2 to sensor v3.x to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Migrate from Defender for Identity sensor v2 to sensor v3.x ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Migrate sensor v2 only after checking sensor v3 feature limits. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Migrate from Defender for Identity sensor v2 to sensor v3.x](https://learn.microsoft.com/en-us/defender-for-identity/deploy/migrate-to-sensor-v3) from Microsoft supports the following bounded statements: - Portal-based migration from sensor v2.x to v3.x automatically completes switchover while retaining server configuration and monitoring without downtime or duplicate data. The research record locates this support at Opening overview. - Microsoft directs administrators to review prerequisites and version limits, including that v3.x does not support VPN integration or Syslog notifications. The research record locates this support at Pre-migration warning. Only the traced statements above are asserted as source facts. Apply the review to Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health after confirming that the source and deployed context match. ## What the source does not establish Confirm every documented v3 limitation and recovery path; the stated automated behavior is not a substitute for local change validation. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Pre-migration warning, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Pre-migration warning through sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Migrate from Defender for Identity sensor v2 to sensor v3.x](https://learn.microsoft.com/en-us/defender-for-identity/deploy/migrate-to-sensor-v3) — Microsoft ## Primary reference - Name: Migrate from Defender for Identity sensor v2 to sensor v3.x - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/migrate-to-sensor-v3 - Source publication date: 2026-07-15 ## Citation and use Preferred citation: “Migrate sensor v2 only after checking sensor v3 feature limits,” DSE Security, https://update.dsesecurity.com/updates/migrate-sensor-v2-after-checking-v3-feature-limits/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Mirror every monitored domain controller to a standalone identity sensor > Use Configure port mirroring to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/mirror-every-monitored-domain-controller-to-standalone-sensor/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:26+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Configure port mirroring to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Configure port mirroring ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Mirror every monitored domain controller to a standalone identity sensor. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Configure port mirroring](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-port-mirroring) from Microsoft supports the following bounded statements: - A standalone sensor needs port mirroring or a network TAP to see domain-controller network traffic. The research record locates this support at Opening overview. - Microsoft directs organizations using port mirroring to configure each monitored domain controller as a traffic source and coordinate with networking or virtualization teams. The research record locates this support at Port-mirroring scope paragraph. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health only where the source and recorded environment align. ## What the source does not establish Mirrored traffic does not supply the ETW coverage unavailable to standalone sensors, and switch-specific configuration remains vendor dependent. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Port-mirroring scope paragraph, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations Opening overview; Port-mirroring scope paragraph adjacent to the sanitized artifacts used for comparison. Prefer sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Configure port mirroring](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-port-mirroring) — Microsoft ## Primary reference - Name: Configure port mirroring - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-port-mirroring - Source publication date: 2026-06-15 ## Citation and use Preferred citation: “Mirror every monitored domain controller to a standalone identity sensor,” DSE Security, https://update.dsesecurity.com/updates/mirror-every-monitored-domain-controller-to-standalone-sensor/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Mirror trusted and disallowed CTLs for disconnected Windows systems > Use Configure trusted roots and disallowed certificates in Windows to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/mirror-trusted-and-disallowed-ctls-for-disconnected-windows/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:08+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Configure trusted roots and disallowed certificates in Windows to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Configure trusted roots and disallowed certificates in Windows ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Mirror trusted and disallowed CTLs for disconnected Windows systems. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Configure trusted roots and disallowed certificates in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/configure-trusted-roots-disallowed-certificates) from Microsoft supports the following bounded statements: - Windows can redirect automatic certificate-list retrieval to an internal file or web server. The research record locates this support at Opening overview. - The documented mirror can host trusted CTLs, untrusted CTLs, or a selected subset for disconnected environments. The research record locates this support at Opening overview. Keep the evidence boundary at these traced claims. They support a review of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Protect mirror integrity and monitor freshness; a stale trust list can preserve revoked or remove needed trust. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles are in and out of scope? - Which condition in Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Opening overview through CA and template exports, enrollment tests, certificate chains, access-control entries, event logs, and revocation-path checks. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Configure trusted roots and disallowed certificates in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/configure-trusted-roots-disallowed-certificates) — Microsoft ## Primary reference - Name: Configure trusted roots and disallowed certificates in Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/configure-trusted-roots-disallowed-certificates - Source publication date: 2025-05-15 ## Citation and use Preferred citation: “Mirror trusted and disallowed CTLs for disconnected Windows systems,” DSE Security, https://update.dsesecurity.com/updates/mirror-trusted-and-disallowed-ctls-for-disconnected-windows/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Model AD replication objects before changing site topology > Use Active Directory Replication Concepts to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/model-ad-replication-objects-before-site-topology/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:08+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Active Directory Replication Concepts to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Active Directory Replication Concepts ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Model AD replication objects before changing site topology. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Active Directory Replication Concepts](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts) from Microsoft supports the following bounded statements: - Microsoft positions replication concepts as prerequisite knowledge for site-topology design. The research record locates this support at Opening overview. - The model includes connection objects, the KCC, subnets, sites, site links, bridges, and global catalog servers. The research record locates this support at Sections: Connection object through Global catalog server. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles only where the source and recorded environment align. ## What the source does not establish Concepts alone do not authorize topology changes; model and test the exact replication paths. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: Connection object through Global catalog server, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from Opening overview; Sections: Connection object through Global catalog server to the observed environment. Useful domain evidence includes directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Active Directory Replication Concepts](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts) — Microsoft ## Primary reference - Name: Active Directory Replication Concepts - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Model AD replication objects before changing site topology,” DSE Security, https://update.dsesecurity.com/updates/model-ad-replication-objects-before-site-topology/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Model every Active Directory forest in one Defender for Identity monitoring plan > Use Microsoft Defender for Identity multi-forest considerations to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/model-every-ad-forest-in-defender-for-identity-plan/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:36+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Microsoft Defender for Identity multi-forest considerations to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft Defender for Identity multi-forest considerations ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Model every Active Directory forest in one Defender for Identity monitoring plan. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft Defender for Identity multi-forest considerations](https://learn.microsoft.com/en-us/defender-for-identity/deploy/multi-forest) from Microsoft supports the following bounded statements: - Defender for Identity supports multiple Active Directory forests and can monitor activity and profile users across them. The research record locates this support at Opening overview. - Each Defender for Identity sensor can report to only one Defender for Identity workspace. The research record locates this support at Multi-forest considerations. The source support ends with the statements listed above. Use them to examine Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Multi-forest support does not establish trust, connectivity, sensor coverage, or data residency for a specific environment. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Multi-forest considerations, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Multi-forest considerations. Favor sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Microsoft Defender for Identity multi-forest considerations](https://learn.microsoft.com/en-us/defender-for-identity/deploy/multi-forest) — Microsoft ## Primary reference - Name: Microsoft Defender for Identity multi-forest considerations - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/multi-forest - Source publication date: 2023-08-10 ## Citation and use Preferred citation: “Model every Active Directory forest in one Defender for Identity monitoring plan,” DSE Security, https://update.dsesecurity.com/updates/model-every-ad-forest-in-defender-for-identity-plan/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Model privacy risk around data actions and effects on people > Privacy risk is not limited to unauthorized disclosure. Use a common vocabulary to examine data actions, context, potential effects on individuals, organizational consequences, and system design choices. - Canonical URL: https://update.dsesecurity.com/updates/privacy-risk-data-actions-effects-people/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:33:49+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, IT, Video Surveillance - Reading time: 3 minutes ## What you need to know Privacy risk is not limited to unauthorized disclosure. Use a common vocabulary to examine data actions, context, potential effects on individuals, organizational consequences, and system design choices. ## Potentially affected Organizations designing or operating systems that observe, identify, classify, locate, record, infer, combine, share, retain, or make decisions about people. ## DSE recommendation Identify data actions and affected people early, assess problematic effects and context separately from cybersecurity events, translate risk into design requirements, and revisit the model when use changes. ## Article Bottom line: privacy problems can arise from authorized data processing, not only from breaches. Describe what the system does with data, who can be affected, how context changes the effect, and which design choices can reduce risk while preserving the intended service. ## Source fact: what NIST IR 8062 introduces [NIST IR 8062](https://csrc.nist.gov/pubs/ir/8062/final) introduces privacy engineering and privacy risk-management concepts for federal systems. NIST identifies a common vocabulary as a way to improve communication about privacy risk and introduces privacy engineering objectives and a privacy risk model as two key components. The publication’s federal context and introductory purpose are important boundaries. It provides a way to structure analysis; it does not determine every acceptable outcome or legal obligation. ## What the source does not establish The NIST report does not certify a system, calculate a universal privacy score, or prove that consent, a notice, encryption, or access control resolves every effect on individuals. Cybersecurity and privacy overlap, but they are not identical: a fully authorized use can still create an unwanted or disproportionate consequence. This draft is not legal advice. Statutory definitions, rights, duties, sensitive categories, employee rules, biometric restrictions, public-sector obligations, and contract terms require context-specific review. ## Applicability questions - What data actions does the system perform, including collection, generation, inference, transformation, combination, use, disclosure, retention, and deletion? - Which individuals and groups can be affected, including people who are not direct users? - What contextual factors—location, power relationship, expectation, accuracy, scale, duration, and ability to contest—change the effect? - Which effects can arise even when every operator is authorized and the system works as designed? - What technical and nontechnical choices can reduce the problematic action or its impact? ## DSE recommendation: bring privacy into system design The following steps are DSE recommendations based on the cited source. - Diagram data actions from the perspective of the people represented, not only the databases and network flows. Include inference, correlation, human review, automated decisions, sharing, and deletion. - Identify affected populations and context. Seek input from appropriate privacy, legal, operational, security, product, and stakeholder representatives. - Describe plausible problematic effects and organizational consequences with evidence and uncertainty. Do not label a speculative outcome as an observed fact. - Translate priorities into design requirements: minimization, separation, aggregation, accuracy checks, human review, access, transparency, correction, retention, deletion, monitoring, and response as appropriate. - Test the requirements against realistic workflows and misuse, including authorized but unexpected use. Record residual risk and decision authority. - Reassess when purpose, data sources, analytics, models, recipients, retention, scale, or affected populations change. ## Verification and evidence Retain the data-action map, affected-population analysis, assumptions and evidence, risk model, design requirements, decisions, test results, notices and user or operator workflows where applicable, residual-risk acceptance, and change triggers. Confirm that actual telemetry and retention match the approved design. ## Official references - [NIST IR 8062 — An Introduction to Privacy Engineering and Risk Management in Federal Systems](https://csrc.nist.gov/pubs/ir/8062/final) — National Institute of Standards and Technology; finalized January 4, 2017 - [NIST Privacy Engineering Program](https://www.nist.gov/itl/applied-cybersecurity/privacy-engineering) — National Institute of Standards and Technology; living program page ## Primary reference - Name: NIST IR 8062 — An Introduction to Privacy Engineering and Risk Management in Federal Systems - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/ir/8062/final - Source publication date: 2017-01-04 ## Citation and use Preferred citation: “Model privacy risk around data actions and effects on people,” DSE Security, https://update.dsesecurity.com/updates/privacy-risk-data-actions-effects-people/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Modern password policy: strengthen sign-in without weakening account recovery > Modern password policy emphasizes length, compromised-password screening, rate limiting, password-manager compatibility, and evidence-based changes while treating account recovery as a separate high-risk control. - Canonical URL: https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-28T14:22:00+00:00 - Modified: 2026-07-28T14:22:00+00:00 - Last reviewed by DSE: 2026-07-28 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Modern password policy emphasizes length, compromised-password screening, rate limiting, password-manager compatibility, and evidence-based changes while treating account recovery as a separate high-risk control. ## Potentially affected Identity providers, business applications, remote-access services, local accounts, password managers, help-desk reset processes, recovery contacts, privileged users, and legacy systems with limited password support. ## DSE recommendation Inventory password and recovery behavior, remove counterproductive rules where supported, block known-compromised choices, permit password managers, strengthen recovery verification, and test lost-authenticator scenarios. ## Article ## Source fact: current password guidance has changed NIST SP 800-63B-4 says a password used as the only authentication factor must contain at least 15 characters. A password used only within multifactor authentication may be at least eight characters, and verifiers should permit at least 64 characters. NIST says verifiers should not impose composition rules, such as requiring mixtures of character types, and should not require periodic password changes unless there is evidence that an authenticator has been compromised. These requirements are written for federal digital identity systems; other organizations can use them as an evidence-based design reference while still checking applicable contracts, regulations, and product limits. NIST requires prospective passwords to be compared with a blocklist containing commonly used, expected, or compromised values. It also calls for rate limiting of failed attempts and permits password managers, autofill, and paste. The complete requirements and implementation notes are in [NIST SP 800-63B-4](https://csrc.nist.gov/pubs/sp/800/63/b/4/final). The guidance does not mean that a long password alone is phishing-resistant or that every legacy system can safely accept a policy change without testing. ## Treat recovery as another authentication path A strong primary authenticator can be undermined by weak recovery. NIST describes recovery methods with different assurance properties and requires notification when account recovery occurs. Knowledge-based questions are not an acceptable authentication factor because answers can often be discovered, guessed, or reused. Help-desk staff should not approve a reset merely because a caller knows information available in company directories, prior email, or public records. Document the recovery paths for a forgotten password, lost authenticator, replaced phone, departed administrator, unavailable identity provider, and suspected compromise. Identify which records establish identity, who may approve an exception, how the event is logged, and which independent channel receives notification. Recovery codes and spare authenticators need controlled issuance, storage, use, and revocation. ## DSE recommendation: migrate policy by system - Inventory identity stores and applications, including maximum length, unsupported characters, silent truncation, lockout behavior, password-history rules, and synchronization dependencies. - For compatible systems, favor length and blocklist screening over predictable composition and routine expiration rules. Allow password-manager generation, paste, and autofill. - Apply rate limits and monitoring that slow automated guessing without enabling easy denial of service. Protect reset endpoints as carefully as sign-in. - Require a password change after credible compromise, exposure in a validated breach source, or an administrator-directed recovery—not merely because a calendar interval elapsed. - Separate help-desk verification from approval for privileged or high-impact recovery. Notify the account owner through an independent registered channel and retain the event record. - Test password changes, synchronization, service accounts, emergency access, lost-device recovery, and rollback in a pilot group before broad enforcement. Measure compromised-password blocks, recovery attempts, exception use, lockouts, failed synchronization, and confirmed takeover. Preserve stricter rules where a governing authority requires them, and record systems that cannot yet support the target policy with an owner and remediation plan. ## Primary reference - Name: NIST SP 800-63B-4: Authentication and Authenticator Management - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/63/b/4/final - Source publication date: 2025-07-31 ## Citation and use Preferred citation: “Modern password policy: strengthen sign-in without weakening account recovery,” DSE Security, https://update.dsesecurity.com/updates/modern-password-policy-account-recovery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Monitor DNSSEC trust-anchor rollover as a resolver lifecycle > Verify that validating resolvers can maintain DNSSEC trust anchors through updates, restarts, and extended offline periods. - Canonical URL: https://update.dsesecurity.com/updates/monitor-dnssec-trust-anchor-rollover/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:47+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Verify that validating resolvers can maintain DNSSEC trust anchors through updates, restarts, and extended offline periods. ## Potentially affected Recursive DNS resolvers that perform DNSSEC validation using locally maintained trust anchors ## DSE recommendation Inventory trust-anchor mechanisms, observe RFC 5011 state, and rehearse resolver recovery without bypassing validation. ## Article A validating resolver can be healthy today yet fail after a trust-anchor change if its update state is stale, unwritable, or lost during replacement. Trust-anchor maintenance belongs in resolver operations, backup design, and upgrade testing. ## Source fact: [IETF RFC 5011](https://www.rfc-editor.org/rfc/rfc5011.html) defines a method for automated, authenticated updates of DNSSEC trust anchors. The method lets a resolver learn a new anchor through DNSKEY records authenticated by an existing trust anchor, hold the new key for a defined acceptance period, and recognize revocation through protocol state. It is specifically a trust-anchor management mechanism rather than a change to normal DNS name resolution. The process depends on a correctly configured starting anchor and persistent state across observations. The RFC describes timing, add and remove hold-down behavior, revocation, and recovery considerations. It does not solve initial trust-anchor installation, and its operational corner cases can still require informed manual intervention. ## Boundary Resolver products expose RFC 5011 status differently, and some deployments use packaged, vendor-managed, or manually pinned anchors instead. Container replacement, immutable images, read-only filesystems, restore points, and long offline periods may affect state. DNSSEC validation failure can have causes unrelated to the root anchor, including bad signatures, time errors, or middleboxes. Disabling validation may restore apparent reachability while removing the security property being investigated. ## Applicability questions - Which recursive resolvers validate DNSSEC, and what trust-anchor update method does each use? - Where is the anchor and its update state stored, backed up, and restored? - Can operators see pending, valid, revoked, or missing anchor state through supported telemetry? - How long can a standby or disaster-recovery resolver remain offline before its state requires review? - Who is authorized to perform manual recovery, and what trusted source will they use? ## DSE recommendation: Create a resolver inventory that records product, version, validation mode, bootstrap source, update method, state location, ownership, and monitoring. Confirm that service accounts can persist state and that image or configuration-management processes do not repeatedly replace it with an old copy. Alert on validation failures, clock problems, unwritable state, and anchor-status changes. In a nonproduction resolver, exercise restart, backup restore, image replacement, and an extended-offline scenario using the product’s supported test method. Rehearse how operators distinguish a trust-anchor problem from an ordinary signed-zone failure. Document a recovery procedure that authenticates anchor material independently, preserves evidence, uses two-person review for manual changes, and restores validation promptly. ## Verification and evidence Keep inventory exports, resolver status output, configured bootstrap source, state-file permissions and persistence settings, backup/restore test records, versioned recovery instructions, and sample DNSSEC validation probes. Evidence should show both successful validation of a signed name and expected failure for a deliberately invalid test domain supplied by a trusted testing authority. Recheck standby instances before activation. ## Official references - [IETF RFC 5011](https://www.rfc-editor.org/rfc/rfc5011.html) - [IANA DNSSEC Trust Anchors and Rollovers](https://www.iana.org/dnssec/files) ## Primary reference - Name: RFC 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5011.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Monitor DNSSEC trust-anchor rollover as a resolver lifecycle,” DSE Security, https://update.dsesecurity.com/updates/monitor-dnssec-trust-anchor-rollover/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Monitor LDAP cookie-pool pressure from large result sets > Use How LDAP server cookies are handled to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/monitor-ldap-cookie-pool-pressure/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:18+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use How LDAP server cookies are handled to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of How LDAP server cookies are handled ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Monitor LDAP cookie-pool pressure from large result sets. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [How LDAP server cookies are handled](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/how-ldap-server-cookies-are-handled) from Microsoft supports the following bounded statements: - Large LDAP result sets impose significant server work, including conversion to LDAP wire formats. The research record locates this support at Opening overview. - Windows Server manages paged-query cookies in a server-side pool that administrators can report on and monitor. The research record locates this support at Sections: Server-side Cookie handling; Reporting on the cookie pool; Monitoring the cookie pool. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps only where the source and recorded environment align. ## What the source does not establish Correlate cookie pressure with the requesting client and query before changing server limits. A correct source interpretation can still be inapplicable to a particular design. Confirm offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: Server-side Cookie handling; Reporting on the cookie pool; Monitoring the cookie pool, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Opening overview; Sections: Server-side Cookie handling; Reporting on the cookie pool; Monitoring the cookie pool to the observed environment. Useful domain evidence includes backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [How LDAP server cookies are handled](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/how-ldap-server-cookies-are-handled) — Microsoft ## Primary reference - Name: How LDAP server cookies are handled - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/how-ldap-server-cookies-are-handled - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Monitor LDAP cookie-pool pressure from large result sets,” DSE Security, https://update.dsesecurity.com/updates/monitor-ldap-cookie-pool-pressure/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Monitor maritime approaches, access points, restricted areas, and waterside activity > Use 33 CFR 105.275 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/monitor-maritime-approaches-access-points-restricted-areas-and-waterside-activity/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:05+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.275 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.275 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Monitor maritime approaches, access points, restricted areas, and waterside activity. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.275 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.275) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the approved FSP must provide continuous monitoring of the facility and its landward and waterside approaches through the specified combination of lighting, personnel, patrols, intrusion detection, or surveillance equipment. The research record locates this support at 33 CFR 105.275(a)(1), read with 33 CFR 105.275(a) (eCFR anchor p-105.275(a)(1)). - Under 33 CFR 105, the approved FSP’s continuous-monitoring capability must cover restricted areas within the facility. The research record locates this support at 33 CFR 105.275(a)(2), read with 33 CFR 105.275(a) (eCFR anchor p-105.275(a)(2)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving cameras, encoders, recorders, video-management services, storage, users, exports, analytics, and monitoring workflows and the conditions the source actually describes. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity, DNS where used, time, networks, storage, certificates, power, privacy controls, and monitoring, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.275(a)(1), read with 33 CFR 105.275(a) (eCFR anchor p-105.275(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.275(a)(2), read with 33 CFR 105.275(a) (eCFR anchor p-105.275(a)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of cameras, encoders, recorders, video-management services, storage, users, exports, analytics, and monitoring workflows, including exceptions? - What baseline for identity, DNS where used, time, networks, storage, certificates, power, privacy controls, and monitoring must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of cameras, encoders, recorders, video-management services, storage, users, exports, analytics, and monitoring workflows, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS where used, time, networks, storage, certificates, power, privacy controls, and monitoring and sanitize protected material before retention. ## Verification and evidence Keep the source locations 33 CFR 105.275(a)(1), read with 33 CFR 105.275(a) (eCFR anchor p-105.275(a)(1)); 33 CFR 105.275(a)(2), read with 33 CFR 105.275(a) (eCFR anchor p-105.275(a)(2)) adjacent to the sanitized artifacts used for comparison. Prefer device and firmware inventory, stream tests, retention observations, access logs, export tests, time alignment, and failure alarms, with enough identity and timing data for an independent recheck. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [33 CFR 105.275 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.275) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.275 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.275 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Monitor maritime approaches, access points, restricted areas, and waterside activity,” DSE Security, https://update.dsesecurity.com/updates/monitor-maritime-approaches-access-points-restricted-areas-and-waterside-activity/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Monitor persistent memory beyond ordinary disk charts > Which observations should be collected when persistent-memory health is uncertain? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-182-monitor-persistent-memory-beyond-ordinary-disk-charts/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:09+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Which observations should be collected when persistent-memory health is uncertain? ## Potentially affected Administrators monitoring persistent-memory devices used with Windows storage. ## DSE recommendation Add persistent-memory-specific health queries to the storage runbook. ## Article ## Source facts Microsoft says persistent memory does not produce Physical Disk performance counters, so it does not appear in the corresponding Windows Admin Center charts. It also does not produce Storport 505 data for proactive outlier detection. The UnsafeShutdownCount value totals shutdowns of underlying persistent-memory devices that may have caused data loss. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/persistent-memory-health). ## Applicability Confirm that the investigated device is persistent memory and identify its actual storage role. Review the documented operating-system limitations before interpreting missing chart data. Keep a missing metric, a warning state, and an unhealthy device as different observations. ## DSE recommendation Add persistent-memory-specific health queries to the storage runbook. Capture device identity, health, operational status, physical location, and unsafe-shutdown observations in a single record. Assign a hardware owner to interpret warnings alongside the vendor guidance. Avoid reinitializing an unfamiliar or unhealthy device merely to make a dashboard look normal. Preserve the initial state for investigation. ## Verification Compare the query output with the physical inventory and the relevant operational events. Verify that monitoring can detect the documented warning or unhealthy state in an approved test or reviewed incident sample. Record unavailable metrics as monitoring limitations and confirm that the escalation path reaches the correct hardware owner. ## Official references [Microsoft Learn: Persistent memory health management for Storage Spaces Direct in Windows Server](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/persistent-memory-health). Source reviewed September 8, 2026. ## Primary reference - Name: Persistent memory health management for Storage Spaces Direct in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/persistent-memory-health - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Monitor persistent memory beyond ordinary disk charts,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-182-monitor-persistent-memory-beyond-ordinary-disk-charts/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Monitor the dedicated Windows LAPS operational log > Use Use Windows LAPS event logs to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/monitor-windows-laps-operational-log/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:57+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Use Windows LAPS event logs to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Use Windows LAPS event logs ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Monitor the dedicated Windows LAPS operational log. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Use Windows LAPS event logs](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-event-log) from Microsoft supports the following bounded statements: - Windows LAPS records its operations in a dedicated LAPS Operational event-log channel. The research record locates this support at Opening overview. - Key events cover policy processing, configuration, password updates, blocked external changes, and post-authentication actions. The research record locates this support at Section: Key events. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios and the conditions the source actually describes. ## What the source does not establish Centralize only the event fields required for operations and avoid collecting recoverable passwords. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section: Key events, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios are in and out of scope? - Which condition in Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of managed accounts, policy assignment, password storage, directory permissions, retrieval roles, rotation, and recovery scenarios, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory or Entra ID, Windows DNS, policy processing, device identity, time, and protected administrative workstations, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Section: Key events. Favor policy exports, directory access-control entries, sanitized client events, rotation tests, retrieval authorization, and exception records, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Use Windows LAPS event logs](https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-event-log) — Microsoft ## Primary reference - Name: Use Windows LAPS event logs - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-management-event-log - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Monitor the dedicated Windows LAPS operational log,” DSE Security, https://update.dsesecurity.com/updates/monitor-windows-laps-operational-log/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Move an identified cluster disk from Available Storage into CSV > What should be verified before an existing cluster disk becomes a Cluster Shared Volume? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-031-move-an-identified-cluster-disk-from-available-storage-into-csv/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:40+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What should be verified before an existing cluster disk becomes a Cluster Shared Volume? ## Potentially affected Use this review for an existing disk that should be added to CSV storage. ## DSE recommendation Have a second administrator verify the exact disk resource and its present use before adding it. ## Article ## Source facts Cluster Shared Volumes allow multiple cluster nodes to access the same NTFS or ReFS volume concurrently. Microsoft requires a disk to enter the cluster’s Available Storage group before adding it as a CSV. Available Storage holds recognized disks not yet assigned to a specific cluster role. The documented PowerShell verification uses Get-ClusterSharedVolume to list the resulting CSV resources. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-cluster-manage-cluster-shared-volumes). ## Applicability Use this review for an existing disk that should be added to CSV storage. Identify the cluster, disk resource, current assignment, and intended workload. Keep creation of a new storage volume as a separate operation. ## DSE recommendation Have a second administrator verify the exact disk resource and its present use before adding it. Record the approved target and avoid selecting every available disk merely because the tool offers that operation. Coordinate the change with the storage and workload owners. Preserve the starting inventory and the intended resource name in the change record. ## Verification After the authorized addition, inspect the CSV inventory and confirm that only the intended disk was added. Verify its resulting access path and perform the agreed workload-access test. Compare the final resource assignment with the initial record. Investigate an unexpected disk, name, or path before assigning production data or repeating the operation. ## Official references [Microsoft Learn: Manage Cluster Shared Volumes](https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-cluster-manage-cluster-shared-volumes). Source reviewed September 8, 2026. ## Primary reference - Name: Manage Cluster Shared Volumes - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/failover-cluster-manage-cluster-shared-volumes - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Move an identified cluster disk from Available Storage into CSV,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-031-move-an-identified-cluster-disk-from-available-storage-into-csv/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Move Defender ASR rules from audit to block through controlled rings > Attack surface reduction rules can block behaviors used by malware, but safe enforcement requires application inventory, representative champions, audit evidence, narrow exclusions, and ring-by-ring expansion. - Canonical URL: https://update.dsesecurity.com/updates/microsoft-defender-asr-audit-to-block-rings/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:53+00:00 - Modified: 2026-07-19T21:27:53+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Attack surface reduction rules can block behaviors used by malware, but safe enforcement requires application inventory, representative champions, audit evidence, narrow exclusions, and ring-by-ring expansion. ## Potentially affected Supported Windows devices using Microsoft Defender Antivirus and organizations managing ASR through Microsoft Intune or another documented management method. ## DSE recommendation Inventory applications and scripts, select a representative first ring, evaluate applicable rules in Audit, use Warn where supported, document narrow exclusions, and move to Block one rule and ring at a time. ## Article ## Source fact: what Microsoft documents Microsoft Defender attack surface reduction rules target software behaviors commonly abused by malware, including risky script, Office, credential, and process activity. Microsoft’s deployment guide applies to Defender for Endpoint Plan 1 and Plan 2 and recommends planning around business units, representative users, approved software, shared folders, scripts, Office macros, internally developed applications, reporting ownership, and deployment rings. Microsoft states that standard protection rules can typically begin in Block or Warn without testing, but recommends testing other rules in Audit before moving them to Block or Warn. The implementation sequence begins with the rule producing the fewest events, reviews activity and champion feedback, refines exclusions, and then expands to the next ring. Warn is available only for supported rules and allows a user to bypass a warning while the event is captured. Microsoft says a specific exclusion is preferable to turning off an entire rule or returning all affected devices to Audit. ## Licensing and applicability Individual ASR capabilities apply to supported Windows versions and Defender Antivirus configurations, while the documented Intune, Entra, reporting, and hunting experience has additional licensing requirements. Microsoft’s guide notes that taking full advantage of ASR reporting uses eligible Microsoft 365 E5, Windows E5, or Microsoft 365 A5 licensing. Rule prerequisites, management precedence, Warn support, exclusions, event visibility, and behavior with non-Microsoft antivirus vary. Unsigned internal applications and scripts can make rollout more difficult. ## DSE recommendation: production-safe operational steps - Inventory Windows versions, Defender mode, management authorities, business applications, scripts, macros, shared paths, developer tools, and code-signing practices. - Select a small but representative first ring and named champions who can report disruption quickly. Include important workflows rather than only new IT laptops. - Define who reviews events, approves exclusions, responds to unwanted blocks, and can pause or roll back a rule. - Enable each non-standard rule in Audit for the pilot. Review events for sufficient business cycles and reproduce the affected workflow before classifying a false positive. - Create the narrowest supported exclusion, with owner, rationale, scope, approval, expiration, and review date. Avoid broad path or process exclusions. - Move the least disruptive applicable rule to Warn or Block for ring one. Review telemetry and champion feedback before the next rule or ring. - Pause on unexplained business impact. Preserve the event, revert the specific rule or assignment, and investigate before reenforcement. DSE recommends separate success criteria for protection and compatibility. A quiet Audit report may mean a compatible estate, missing telemetry, incorrect assignment, or an inactive rule. Verify effective policy and test a safe, documented validation scenario before treating silence as proof. ## Official references - [Plan your attack surface reduction rules deployment](https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-deployment-plan) — requirements, business inventory, champions, roles, and rings. - [Enable your attack surface reduction rules deployment](https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-deployment-implement) — Audit, Warn, Block, exclusions, and expansion sequence. ## Primary reference - Name: Microsoft Learn: Plan your attack surface reduction rules deployment - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-endpoint/attack-surface-reduction-rules-deployment-plan - Source publication date: 2026-05-22 ## Citation and use Preferred citation: “Move Defender ASR rules from audit to block through controlled rings,” DSE Security, https://update.dsesecurity.com/updates/microsoft-defender-asr-audit-to-block-rings/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Move Defender for Identity access to least-privileged unified RBAC roles > Use Microsoft Defender for Identity role groups to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/move-defender-for-identity-access-to-least-privileged-unified-rbac/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:53+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Microsoft Defender for Identity role groups to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft Defender for Identity role groups ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Move Defender for Identity access to least-privileged unified RBAC roles. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft Defender for Identity role groups](https://learn.microsoft.com/en-us/defender-for-identity/role-groups) from Microsoft supports the following bounded statements: - Microsoft recommends role groups that segregate security-team responsibilities and grant only the access needed for each job. The research record locates this support at Opening least-privilege guidance. - New Defender for Identity tenants from March 2, 2025 can configure permissions only through Microsoft Defender XDR Unified RBAC, while earlier role assignments are retained. The research record locates this support at Unified RBAC transition note. Keep the evidence boundary at these traced claims. They support a review of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Map current duties and emergency access before changing roles; inherited tenant roles and legacy assignments require explicit review. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening least-privilege guidance, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Unified RBAC transition note, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to Opening least-privilege guidance; Unified RBAC transition note and to observable material such as sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Microsoft Defender for Identity role groups](https://learn.microsoft.com/en-us/defender-for-identity/role-groups) — Microsoft ## Primary reference - Name: Microsoft Defender for Identity role groups - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/role-groups - Source publication date: 2024-01-15 ## Citation and use Preferred citation: “Move Defender for Identity access to least-privileged unified RBAC roles,” DSE Security, https://update.dsesecurity.com/updates/move-defender-for-identity-access-to-least-privileged-unified-rbac/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Move Exchange Online SMTP AUTH clients off Basic authentication with evidence > Microsoft now plans to disable SMTP AUTH Basic authentication by default for existing Exchange Online tenants at the end of December 2026. Find every sender, choose a supported replacement, pilot it, and prove the legacy path is quiet. - Canonical URL: https://update.dsesecurity.com/updates/exchange-online-smtp-auth-basic-auth-migration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:05:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Microsoft now plans to disable SMTP AUTH Basic authentication by default for existing Exchange Online tenants at the end of December 2026. Find every sender, choose a supported replacement, pilot it, and prove the legacy path is quiet. ## Potentially affected Exchange Online tenants; scanners, multifunction devices, alerting platforms, applications, scripts, line-of-business systems, service accounts, connectors, relay services, and mail operations. ## DSE recommendation Correlate tenant and application evidence to inventory SMTP AUTH Basic clients, assign each an owner and replacement pattern, pilot OAuth or another documented route, then remove legacy credentials and verify delivery and monitoring. ## Article ## Source facts: the milestone changed, but the destination did not In its [January 2026 timeline update](https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-smtp-auth-basic-authentication-deprecation-timeline/4489835), the Microsoft Exchange Team says SMTP AUTH Basic authentication behavior remains unchanged through December 2026. At the end of December 2026, it will be disabled by default for existing Exchange Online tenants, although administrators will still be able to enable it if needed. New tenants created after December 2026 will have Basic authentication unavailable by default and OAuth will be the supported authentication method. Microsoft plans to announce the final removal date in the second half of 2027. This is specifically about the Basic authentication method for SMTP AUTH client submission. It is not a statement that every device must be made to speak OAuth regardless of capability, nor does it make a connector, relay, or direct-send design interchangeable with authenticated client submission. Each alternative has different sender, recipient, network, authentication, and operational boundaries. Microsoft’s Exchange developer documentation supports OAuth for SMTP AUTH, including delegated and application access patterns. An OAuth migration involves an identity application, appropriate permissions and consent, token acquisition, and the SMTP protocol’s OAuth mechanism. A successful token request does not prove that the application sends the intended message, and a test email does not prove the old password is no longer used elsewhere. ## DSE recommendation: migrate workloads, not just credentials Create an inventory in which every observed sender maps to a business service and a technical owner. Gather Exchange Online sign-in and mail evidence, source addresses, message headers, service-account usage, application configuration, network flows, and help-desk history. Include low-volume systems that send only monthly, quarterly, at year end, or during an incident; a thirty-day sample can miss the sender that matters most. - Classify the requirement. Record who or what sends, envelope and visible sender, internal or external recipients, volume, attachment size, delivery urgency, source network, high-availability need, and whether replies, non-delivery reports, or compliance retention matter. - Select a documented pattern. Prefer OAuth-capable SMTP AUTH when the product supports it and that pattern fits. Evaluate Microsoft-documented relay or submission alternatives where a device cannot use OAuth. Do not expose a broad unauthenticated relay or assume an IP address alone establishes trustworthy identity. - Build least privilege. Use a dedicated identity or application boundary, restrict allowed sender behavior where the chosen design permits it, minimize cloud and mailbox permissions, protect configuration, and assign both credential and application ownership. - Test the full mail contract. Exercise internal and external recipients as permitted, attachments, expected From and Reply-To behavior, non-delivery handling, throttling, retry after interruption, monitoring, and the recipient system that consumes the message. Capture message trace and application evidence. - Remove the legacy path. Disable or replace the stored password, update secret stores and recovery documentation, and observe long enough to cover the workload’s real schedule. Search again for Basic SMTP AUTH activity and investigate every recurrence before calling migration complete. - Keep an exception register. For any temporary re-enable, record the exact workload, approval, reason, risk, owner, compensating controls, expiry, and tested migration date. A tenant-wide switch without workload evidence is not an exception process. Track known senders, owners assigned, target patterns, completed end-to-end tests, Basic activity by workload, failed authentication, delivery failures, and exception age. Recheck Microsoft’s timeline during each program review because the final removal date is intentionally not yet specified. The strong outcome is a smaller, observable mail surface whose identity and delivery behavior are understood before the default changes. Before the tenant default changes, run a tabletop for a newly discovered legacy sender: who may re-enable Basic authentication, at what scope, for how long, and with which monitoring. Test the approval and rollback steps in advance. That prevents an urgent payroll, alarm, or facilities message from turning into an undocumented tenant-wide exception. ## Official references - Microsoft Exchange Team, [Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline](https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-smtp-auth-basic-authentication-deprecation-timeline/4489835), updated January 29, 2026. - Microsoft Learn, [Authenticate an IMAP, POP or SMTP connection using OAuth](https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth). ## Primary reference - Name: Microsoft Exchange Team: Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline - Authority: Microsoft - URL: https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-smtp-auth-basic-authentication-deprecation-timeline/4489835 - Source publication date: 2026-01-29 ## Citation and use Preferred citation: “Move Exchange Online SMTP AUTH clients off Basic authentication with evidence,” DSE Security, https://update.dsesecurity.com/updates/exchange-online-smtp-auth-basic-auth-migration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Move Windows known folders to OneDrive without creating an empty desktop > OneDrive Known Folder Move can redirect familiar Windows folders to the cloud, but prior redirection, other tenants, unsupported files, storage, bandwidth, and sync health must be resolved first. - Canonical URL: https://update.dsesecurity.com/updates/onedrive-known-folder-move-controlled-rollout/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:15+00:00 - Modified: 2026-07-19T21:28:15+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know OneDrive Known Folder Move can redirect familiar Windows folders to the cloud, but prior redirection, other tenants, unsupported files, storage, bandwidth, and sync health must be resolved first. ## Potentially affected Windows users whose Desktop, Documents, Pictures, Screenshots, or Camera Roll data will move through the OneDrive sync app, including migrations from Folder Redirection or another tenant. ## DSE recommendation Inventory current folder locations and data, update OneDrive, test a small representative group, validate files and sync health, and expand within Microsoft rollout guidance. ## Article ## Source fact: what Microsoft documents OneDrive Known Folder Move redirects supported Windows folders such as Desktop, Documents, Pictures, Screenshots, and Camera Roll into the user’s OneDrive. Users continue working in familiar locations while the OneDrive sync app uploads the content and makes it available from other devices. Administrators can prompt users to move folders or silently redirect supported folders through Group Policy, Intune administrative templates, or documented registry policy. Microsoft recommends upgrading to the latest OneDrive build and rolling out slowly to control upload demand. For existing devices, Microsoft currently recommends limiting silent Known Folder Move deployment to 1,000 devices per day and 4,000 per week across Windows and macOS. For the prompt policy, Microsoft recommends no more than 5,000 devices per day and 20,000 per week. Existing Folder Redirection requires a transition process. Known Folder Move does not work when the user is syncing OneDrive files in SharePoint Server. If folders are already redirected to another organization’s OneDrive, redirecting immediately to the new tenant creates new folders and can leave the user viewing an empty desktop until data is migrated. Microsoft documents separate steps for local paths, file shares, and previous OneDrive redirection. ## Licensing and applicability The user needs an eligible OneDrive for work or school service, supported sync application, sufficient cloud storage, and supported Windows configuration. File names, paths, open files, policies, network proxies, tenant restrictions, unsupported content, and previous folder ownership can block migration. Syncing content to OneDrive improves service availability but is not a complete independent backup, legal retention, or offline recovery strategy. ## DSE recommendation: production-safe operational steps - Inventory each user’s current Desktop, Documents, and Pictures paths, prior Folder Redirection, tenant association, file count and size, storage quota, unsupported files, permissions, and sync errors. - Define the supported transition for local folders, network shares, or another OneDrive tenant. Preserve authoritative source data until destination validation is complete. - Update the OneDrive sync app and verify required Microsoft 365 network endpoints, disk capacity, user identity, and Files On-Demand behavior. - Pilot representative users with large data sets, laptops, remote connections, specialized applications, multiple devices, and redirected folders. - Validate folder contents, timestamps where important, application save paths, desktop appearance, synchronization, conflict handling, web access, new-device recovery, and user support. - Throttle or schedule upload where required and expand within Microsoft’s current daily and weekly rollout guidance. - Monitor sync health and storage continuously. Remove the source only after documented acceptance and the applicable retention period. DSE recommends communicating the visual changes and error-resolution path before policy assignment. If a user sees an empty folder, stop further moves for that cohort, preserve both source locations, identify tenant and redirection state, and reconcile files before continuing. ## Official reference [Redirect and move Windows known folders to OneDrive](https://learn.microsoft.com/en-us/sharepoint/redirect-known-folders) — supported folders, policies, rollout rates, prior redirection, bandwidth, and migration behavior. ## Primary reference - Name: Microsoft Learn: Redirect and move Windows known folders to OneDrive - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/sharepoint/redirect-known-folders - Source publication date: 2025-03-27 ## Citation and use Preferred citation: “Move Windows known folders to OneDrive without creating an empty desktop,” DSE Security, https://update.dsesecurity.com/updates/onedrive-known-folder-move-controlled-rollout/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Move Windows services from reusable passwords to managed service identities where supported > Group Managed Service Accounts let supported domain services use domain-managed passwords and simplified SPN management. Migration still requires application support, dependency discovery, least privilege, host authorization, staged testing, and rollback. - Canonical URL: https://update.dsesecurity.com/updates/move-windows-services-to-managed-service-identities-where-supported/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:00:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Group Managed Service Accounts let supported domain services use domain-managed passwords and simplified SPN management. Migration still requires application support, dependency discovery, least privilege, host authorization, staged testing, and rollback. ## Potentially affected Windows Server domain services, scheduled tasks and application pools that support managed service accounts, Active Directory and KDS, gMSA host authorization, SPNs, service dependencies, local and network rights, clustering or farms, monitoring, backup, and disaster recovery. ## DSE recommendation Inventory service-account dependencies and owners, confirm gMSA support and domain prerequisites, design host retrieval and least privilege, pilot one noncritical service, test startup and every dependency including recovery, rotate or retire the old credential, then monitor for misuse and drift. ## Article ## Source facts: a gMSA moves password management to the domain Microsoft’s [group Managed Service Account management guidance](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/manage-group-managed-service-accounts) describes gMSAs as domain accounts usable by services on multiple domain-joined servers. The domain controller manages the password and authorized hosts retrieve it, removing ordinary administrator handling of a reusable service-account password. Microsoft also describes simplified service principal name management. The [gMSA overview](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/group-managed-service-accounts-overview) explains the role of the Key Distribution Service and the use of one service principal across a server farm where mutual authentication is required. It lists operating-system and Active Directory prerequisites and distinguishes group managed, standalone managed, virtual, and ordinary user accounts. A gMSA is not supported by every Windows service, installer, scheduled task, cluster, application, database, or third-party product. It does not automatically remove excessive privileges, insecure delegation, weak file permissions, exposed connection strings, or application secrets. Domain version, KDS configuration, product support, backup, and recovery must be verified for the environment. ## DSE recommendation: migrate an identity as an application change Build a service-identity register before creating accounts. For each current account, identify owner, services and tasks, hosts, SPNs, logon rights, local groups, file and registry access, shares, databases, certificates, APIs, scheduled jobs, dependent systems, password-change method, recovery process, and last verified use. Do not infer scope from the account name. - Confirm support. Obtain current vendor documentation for the exact application and version. Verify whether it accepts a gMSA, how the account is entered, whether a blank password is supported, and any limitations for clusters, services, tasks, application pools, installers, upgrades, or remote resources. - Prepare the domain. Have qualified Active Directory administrators verify forest and domain prerequisites, KDS root-key state, time and replication, naming, DNS, and supported management tools. Avoid recreating or manipulating KDS material merely to accelerate a deployment. - Limit retrieval. Authorize only the computer accounts or controlled group of hosts that must retrieve the gMSA password. Protect the membership and monitor changes. An attacker controlling an authorized host may be able to use the service identity. - Rebuild least privilege. Grant only required logon rights, local membership, file, registry, share, database, network, and application permissions. Register only required SPNs and review delegation. Do not clone all permissions from an overprivileged legacy account for convenience. - Pilot and exercise. Migrate a supported noncritical instance in a change window. Test start, stop, restart, reboot, patching, dependency access, Kerberos authentication, failover, backup, restore, monitoring, log collection, and vendor upgrade. Preserve a time-bounded rollback. - Retire the legacy secret. After verification, remove the old account from service configuration, scheduled tasks, scripts, vaults, documentation, and permissions. Rotate its password to invalidate undiscovered copies, monitor attempted use, then disable and delete only under the approved retention and rollback policy. Monitor service starts, failed logons, SPN conflicts, host-retrieval authorization changes, group membership, privilege changes, and use from unexpected systems. Include the gMSA in tiering and disaster-recovery plans: a restored service must still have domain connectivity, correct authorization, and required dependencies. Do not force migration where the vendor does not support it. A vault-managed, narrowly privileged account with automated rotation may be the safer interim design. Success is not the presence of a dollar sign in an account name; it is removal of human-managed reusable credentials without breaking support, containment, or recovery. Maintain an explicit noncandidate list with the vendor limitation, current protective controls, credential owner, rotation evidence, and next review trigger. Stop a pilot on unsupported installer behavior, inability to restore service, unexpected host retrieval, SPN conflict, or a permission request broader than the documented dependency. Return to the prior identity under the change plan and correct the design before attempting another service. ## Official references - Microsoft, [Manage group Managed Service Accounts](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/manage-group-managed-service-accounts). - Microsoft, [Group Managed Service Accounts overview](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/group-managed-service-accounts-overview). ## Primary reference - Name: Microsoft Learn: Manage group Managed Service Accounts - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/manage-group-managed-service-accounts - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Move Windows services from reusable passwords to managed service identities where supported,” DSE Security, https://update.dsesecurity.com/updates/move-windows-services-to-managed-service-identities-where-supported/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Move-ADDirectoryServer: move addirectory server with bounded evidence > Use Move-ADDirectoryServer to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/move-addirectoryserver-move-addirectory-server-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:11+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Move-ADDirectoryServer to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Move-ADDirectoryServer ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Move-ADDirectoryServer: move addirectory server with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Move-ADDirectoryServer](https://learn.microsoft.com/en-us/powershell/module/activedirectory/move-addirectoryserver?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Moves a directory server in Active Directory to a new site.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Move-ADDirectoryServer cmdlet moves a directory server in Active Directory to a new site within the same domain.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to SYNOPSIS; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-195 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Move-ADDirectoryServer](https://learn.microsoft.com/en-us/powershell/module/activedirectory/move-addirectoryserver?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Move-ADDirectoryServer - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/move-addirectoryserver?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Move-ADDirectoryServer: move addirectory server with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/move-addirectoryserver-move-addirectory-server-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Move-ADDirectoryServerOperationMasterRole: move addirectory server operation master role with before-and-after evidence > Use Move-ADDirectoryServerOperationMasterRole to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/move-addirectoryserveroperationmasterrole-move-addirectory-server-operation-master-role-with-before/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:32+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Move-ADDirectoryServerOperationMasterRole to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Move-ADDirectoryServerOperationMasterRole ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Move-ADDirectoryServerOperationMasterRole: move addirectory server operation master role with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Move-ADDirectoryServerOperationMasterRole](https://learn.microsoft.com/en-us/powershell/module/activedirectory/move-addirectoryserveroperationmasterrole?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Moves operation master roles to an Active Directory directory server.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Move-ADDirectoryServerOperationMasterRole cmdlet moves one or more operation master roles to a directory server.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations SYNOPSIS; DESCRIPTION. Favor sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-174 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Move-ADDirectoryServerOperationMasterRole](https://learn.microsoft.com/en-us/powershell/module/activedirectory/move-addirectoryserveroperationmasterrole?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Move-ADDirectoryServerOperationMasterRole - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/move-addirectoryserveroperationmasterrole?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Move-ADDirectoryServerOperationMasterRole: move addirectory server operation master role with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/move-addirectoryserveroperationmasterrole-move-addirectory-server-operation-master-role-with-before/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Negotiate Add-Path before advertising multiple paths for one prefix > Use RFC 7911 — Advertisement of Multiple Paths in BGP to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/negotiate-add-path-before-advertising-multiple-paths-for-one-prefix/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:23+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 7911 — Advertisement of Multiple Paths in BGP to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 7911 — Advertisement of Multiple Paths in BGP ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Negotiate Add-Path before advertising multiple paths for one prefix. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 7911 — Advertisement of Multiple Paths in BGP](https://www.rfc-editor.org/rfc/rfc7911.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - The ADD-PATH capability declares, separately for each AFI/SAFI, whether the sender can receive paths, send paths, or do both. The research record locates this support at Section 4 (ADD-PATH Capability). - A speaker may send multiple paths for an AFI/SAFI only when it advertised send capability and its peer advertised receive capability for that same AFI/SAFI. The research record locates this support at Section 5 (Operation), capability negotiation rule. - The sender assigns a path identifier so prefix plus identifier uniquely selects one advertised path; a receiver must not infer semantics from that local identifier. The research record locates this support at Section 2 (How to Identify a Path). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Section 4 (ADD-PATH Capability), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 5 (Operation), capability negotiation rule, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2 (How to Identify a Path), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 4 (ADD-PATH Capability); Section 5 (Operation), capability negotiation rule; Section 2 (How to Identify a Path). Favor configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 7911 — Advertisement of Multiple Paths in BGP](https://www.rfc-editor.org/rfc/rfc7911.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 7911 — Advertisement of Multiple Paths in BGP - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc7911.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Negotiate Add-Path before advertising multiple paths for one prefix,” DSE Security, https://update.dsesecurity.com/updates/negotiate-add-path-before-advertising-multiple-paths-for-one-prefix/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Negotiate each BGP address family before exchanging reachability > Use RFC 4760 — Multiprotocol Extensions for BGP-4 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/negotiate-each-bgp-address-family-before-exchanging-reachability/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:21+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4760 — Multiprotocol Extensions for BGP-4 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4760 — Multiprotocol Extensions for BGP-4 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Negotiate each BGP address family before exchanging reachability. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4760 — Multiprotocol Extensions for BGP-4](https://www.rfc-editor.org/rfc/rfc4760.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - MP_REACH_NLRI advertises reachable prefixes and their next hop, with AFI and SAFI identifying the address-family semantics. The research record locates this support at Section 3 (Multiprotocol Reachable NLRI – MP_REACH_NLRI). - MP_UNREACH_NLRI withdraws multiple routes for the AFI and SAFI carried in that attribute. The research record locates this support at Section 4 (Multiprotocol Unreachable NLRI – MP_UNREACH_NLRI). - Bidirectional route exchange for an AFI/SAFI requires both peers to advertise support for that exact tuple through BGP Capability Advertisement. The research record locates this support at Section 8 (Use of BGP Capability Advertisement). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Section 3 (Multiprotocol Reachable NLRI – MP_REACH_NLRI), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4 (Multiprotocol Unreachable NLRI – MP_UNREACH_NLRI), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 8 (Use of BGP Capability Advertisement), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 3 (Multiprotocol Reachable NLRI – MP_REACH_NLRI); Section 4 (Multiprotocol Unreachable NLRI – MP_UNREACH_NLRI); Section 8 (Use of BGP Capability Advertisement). Favor configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 4760 — Multiprotocol Extensions for BGP-4](https://www.rfc-editor.org/rfc/rfc4760.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4760 — Multiprotocol Extensions for BGP-4 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4760.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Negotiate each BGP address family before exchanging reachability,” DSE Security, https://update.dsesecurity.com/updates/negotiate-each-bgp-address-family-before-exchanging-reachability/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Negotiate ECN before treating congestion marks as transport signals > Use RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/negotiate-ecn-before-treating-congestion-marks-as-transport-signals/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:22+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Negotiate ECN before treating congestion marks as transport signals. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP](https://www.rfc-editor.org/rfc/rfc3168.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - TCP negotiates ECN with ECE and CWR set on the initiating SYN and only ECE set on the responding SYN-ACK; neither endpoint may set ECT on data until both directions complete ECN setup. The research record locates this support at Section 6.1.1 (TCP Initialization). - A receiver echoes a received CE mark with ECE acknowledgments until it receives CWR from the sender. The research record locates this support at Section 6.1.3 (The TCP Receiver). - An ECE acknowledgment makes the sender respond as it would to congestion loss by reducing its congestion window, then marking the first new data packet after reduction with CWR. The research record locates this support at Section 6.1.2 (The TCP Sender). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Section 6.1.1 (TCP Initialization), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 6.1.3 (The TCP Receiver), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 6.1.2 (The TCP Sender), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 6.1.1 (TCP Initialization); Section 6.1.3 (The TCP Receiver); Section 6.1.2 (The TCP Sender). Favor configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP](https://www.rfc-editor.org/rfc/rfc3168.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3168.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Negotiate ECN before treating congestion marks as transport signals,” DSE Security, https://update.dsesecurity.com/updates/negotiate-ecn-before-treating-congestion-marks-as-transport-signals/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Negotiate EDNS UDP size and extended fields through the OPT pseudo-record > Use RFC 6891 — Extension Mechanisms for DNS (EDNS(0)) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/negotiate-edns-udp-size-and-extended-fields-through-the-opt-pseudo-record/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:37+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6891 — Extension Mechanisms for DNS (EDNS(0)) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6891 — Extension Mechanisms for DNS (EDNS(0)) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Negotiate EDNS UDP size and extended fields through the OPT pseudo-record. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6891 — Extension Mechanisms for DNS (EDNS(0))](https://www.rfc-editor.org/rfc/rfc6891.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - EDNS uses an OPT pseudo-record to carry the sender’s UDP payload size plus extended response-code, version, flag, and option fields. The research record locates this support at Section 6.1 (OPT Record Definition). - A requestor advertises the maximum UDP payload it can reassemble in the OPT CLASS field, and responders must limit replies to that advertised size. The research record locates this support at Section 6.2.3 (OPT Record TTL Field Use), requestor payload size. - A responder that implements EDNS includes OPT in a response only when the request contained OPT. The research record locates this support at Section 6.1.1 (Basic Elements), request-response rule. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Section 6.1 (OPT Record Definition), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 6.2.3 (OPT Record TTL Field Use), requestor payload size, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 6.1.1 (Basic Elements), request-response rule, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 6.1 (OPT Record Definition); Section 6.2.3 (OPT Record TTL Field Use), requestor payload size; Section 6.1.1 (Basic Elements), request-response rule. Favor zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 6891 — Extension Mechanisms for DNS (EDNS(0))](https://www.rfc-editor.org/rfc/rfc6891.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6891 — Extension Mechanisms for DNS (EDNS(0)) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6891.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Negotiate EDNS UDP size and extended fields through the OPT pseudo-record,” DSE Security, https://update.dsesecurity.com/updates/negotiate-edns-udp-size-and-extended-fields-through-the-opt-pseudo-record/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Negotiate requested DSN outcomes and returned content at SMTP time > Use RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:57+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Negotiate requested DSN outcomes and returned content at SMTP time. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)](https://www.rfc-editor.org/rfc/rfc3461.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - The RCPT NOTIFY parameter requests DSNs for SUCCESS, FAILURE, or DELAY; NEVER must appear alone and requests no DSN for that recipient. The research record locates this support at Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command). - The RCPT ORCPT parameter preserves the original recipient address that corresponds to the actual delivery recipient. The research record locates this support at Section 4.2 (The ORCPT parameter to the ESMTP RCPT command). - The MAIL RET parameter requests either the full message or only its headers in a failed DSN; it does not apply when no recipient failed. The research record locates this support at Section 4.3 (The RET parameter of the ESMTP MAIL command). The source support ends with the statements listed above. Use them to examine sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4.2 (The ORCPT parameter to the ESMTP RCPT command), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4.3 (The RET parameter of the ESMTP MAIL command), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Section 4.1 (The NOTIFY parameter of the ESMTP RCPT command); Section 4.2 (The ORCPT parameter to the ESMTP RCPT command); Section 4.3 (The RET parameter of the ESMTP MAIL command) through sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)](https://www.rfc-editor.org/rfc/rfc3461.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3461.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Negotiate requested DSN outcomes and returned content at SMTP time,” DSE Security, https://update.dsesecurity.com/updates/negotiate-requested-dsn-outcomes-and-returned-content-at-smtp-time/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Negotiate SMTP STARTTLS without implying authenticated delivery > Use RFC 3207 — SMTP Service Extension for Secure SMTP over Transport Layer Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/negotiate-smtp-starttls-without-implying-authenticated-delivery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:59+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3207 — SMTP Service Extension for Secure SMTP over Transport Layer Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3207 — SMTP Service Extension for Secure SMTP over Transport Layer Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Negotiate SMTP STARTTLS without implying authenticated delivery. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3207 — SMTP Service Extension for Secure SMTP over Transport Layer Security](https://www.rfc-editor.org/rfc/rfc3207.html) from RFC Editor supports the following bounded statements: - After a 220 response to STARTTLS, the client begins the TLS handshake before sending any further SMTP command. The research record locates this support at Section 4 (The STARTTLS Command). - A successful TLS handshake resets SMTP to its initial state; both peers discard pre-TLS protocol knowledge and the client sends a new EHLO. The research record locates this support at Section 4.2 (Result of the STARTTLS Command). - A public MX on port 25 cannot require STARTTLS for local delivery, although relay policy may depend on authentication obtained during TLS. The research record locates this support at Section 4 (The STARTTLS Command), public-server rule. The source support ends with the statements listed above. Use them to examine sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 4 (The STARTTLS Command), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4.2 (Result of the STARTTLS Command), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4 (The STARTTLS Command), public-server rule, which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Section 4 (The STARTTLS Command); Section 4.2 (Result of the STARTTLS Command); Section 4 (The STARTTLS Command), public-server rule through sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 3207 — SMTP Service Extension for Secure SMTP over Transport Layer Security](https://www.rfc-editor.org/rfc/rfc3207.html) — RFC Editor ## Primary reference - Name: RFC 3207 — SMTP Service Extension for Secure SMTP over Transport Layer Security - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3207.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Negotiate SMTP STARTTLS without implying authenticated delivery,” DSE Security, https://update.dsesecurity.com/updates/negotiate-smtp-starttls-without-implying-authenticated-delivery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Negotiate SMTPUTF8 before transporting internationalized addresses > Use RFC 6531 — SMTP Extension for Internationalized Email to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/negotiate-smtputf8-before-transporting-internationalized-addresses/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:58+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6531 — SMTP Extension for Internationalized Email to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6531 — SMTP Extension for Internationalized Email ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Negotiate SMTPUTF8 before transporting internationalized addresses. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6531 — SMTP Extension for Internationalized Email](https://www.rfc-editor.org/rfc/rfc6531.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An SMTP server advertising SMTPUTF8 accepts UTF-8 wherever the SMTP mailbox grammar permits a mailbox value. The research record locates this support at Section 3.2 (The SMTPUTF8 Extension). - A client may send internationalized mailbox names and UTF-8 headers only after the server advertises SMTPUTF8 in its EHLO response. The research record locates this support at Section 3.2 (The SMTPUTF8 Extension), negotiation rule. - If the next SMTP server lacks SMTPUTF8, the client must not transmit the internationalized message and instead transforms, rejects, requeues, or tries another MX as permitted. The research record locates this support at Sections 3.2 (The SMTPUTF8 Extension) and 3.5 (Non-ASCII Addresses and Reply-Codes). The source support ends with the statements listed above. Use them to examine sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 3.2 (The SMTPUTF8 Extension), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3.2 (The SMTPUTF8 Extension), negotiation rule, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 3.2 (The SMTPUTF8 Extension) and 3.5 (Non-ASCII Addresses and Reply-Codes), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from Section 3.2 (The SMTPUTF8 Extension); Section 3.2 (The SMTPUTF8 Extension), negotiation rule; Sections 3.2 (The SMTPUTF8 Extension) and 3.5 (Non-ASCII Addresses and Reply-Codes) through sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 6531 — SMTP Extension for Internationalized Email](https://www.rfc-editor.org/rfc/rfc6531.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6531 — SMTP Extension for Internationalized Email - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6531.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Negotiate SMTPUTF8 before transporting internationalized addresses,” DSE Security, https://update.dsesecurity.com/updates/negotiate-smtputf8-before-transporting-internationalized-addresses/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADAuthenticationPolicy: create adauthentication policy with bounded evidence > Use New-ADAuthenticationPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adauthenticationpolicy-create-adauthentication-policy-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:11+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADAuthenticationPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADAuthenticationPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: New-ADAuthenticationPolicy: create adauthentication policy with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADAuthenticationPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adauthenticationpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The New-ADAuthenticationPolicy creates an authentication policy object in Active Directory® Domain Services.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “Commonly used attributes of the object can be specified by the parameters of this cmdlet.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations DESCRIPTION; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-135 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [New-ADAuthenticationPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adauthenticationpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADAuthenticationPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adauthenticationpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADAuthenticationPolicy: create adauthentication policy with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/new-adauthenticationpolicy-create-adauthentication-policy-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADCentralAccessRule: create adcentral access rule with rollback checks > Use New-ADCentralAccessRule to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adcentralaccessrule-create-adcentral-access-rule-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:09+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADCentralAccessRule to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADCentralAccessRule ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: New-ADCentralAccessRule: create adcentral access rule with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADCentralAccessRule](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adcentralaccessrule?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The New-ADCentralAccessRule cmdlet creates a central access rule in Active Directory.” The research record locates this support at DESCRIPTION. - At Example 1: Create a new named central access rule, Microsoft states: “This command creates a new central access rule named Finance Documents Rule.” The research record locates this support at Example 1: Create a new named central access rule. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Create a new named central access rule, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; Example 1: Create a new named central access rule. Favor sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-197 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [New-ADCentralAccessRule](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adcentralaccessrule?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADCentralAccessRule - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adcentralaccessrule?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADCentralAccessRule: create adcentral access rule with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/new-adcentralaccessrule-create-adcentral-access-rule-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADClaimTransformPolicy: create adclaim transform policy with rollback checks > Use New-ADClaimTransformPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adclaimtransformpolicy-create-adclaim-transform-policy-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:14+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADClaimTransformPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADClaimTransformPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: New-ADClaimTransformPolicy: create adclaim transform policy with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADClaimTransformPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adclaimtransformpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Creates a new claim transformation policy object in Active Directory.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The New-ADClaimTransformPolicy cmdlet creates a new claims transformation policy object in Active Directory.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations SYNOPSIS; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-132 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [New-ADClaimTransformPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adclaimtransformpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADClaimTransformPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adclaimtransformpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADClaimTransformPolicy: create adclaim transform policy with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/new-adclaimtransformpolicy-create-adclaim-transform-policy-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADClaimType: create adclaim type with rollback checks > Use New-ADClaimType to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adclaimtype-create-adclaim-type-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:44+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADClaimType to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADClaimType ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: New-ADClaimType: create adclaim type with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADClaimType](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adclaimtype?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The New-ADClaimType cmdlet creates a new claim type in Active Directory.” The research record locates this support at DESCRIPTION. - At Example 1: Create a new user claim type with a display name, Microsoft states: “This command creates a new user claim type with display name Title that is sourced from the Active Directory attribute Title.” The research record locates this support at Example 1: Create a new user claim type with a display name. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Create a new user claim type with a display name, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; Example 1: Create a new user claim type with a display name through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-162 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [New-ADClaimType](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adclaimtype?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADClaimType - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adclaimtype?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADClaimType: create adclaim type with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/new-adclaimtype-create-adclaim-type-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADComputer: create adcomputer with bounded evidence > Use New-ADComputer to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adcomputer-create-adcomputer-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:21+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADComputer to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADComputer ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: New-ADComputer: create adcomputer with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADComputer](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adcomputer?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The New-ADComputer cmdlet creates a new Active Directory computer object.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “This cmdlet does not join a computer to a domain.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Within Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, which versions, roles, and configuration states define the review population? - Could Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-125 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [New-ADComputer](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adcomputer?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADComputer - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adcomputer?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADComputer: create adcomputer with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/new-adcomputer-create-adcomputer-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADDCCloneConfigFile: create addcclone config file with before-and-after evidence > Use New-ADDCCloneConfigFile to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-addccloneconfigfile-create-addcclone-config-file-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:17+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADDCCloneConfigFile to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADDCCloneConfigFile ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: New-ADDCCloneConfigFile: create addcclone config file with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADDCCloneConfigFile](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-addccloneconfigfile?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Performs prerequisite checks for cloning a domain controller and generates a clone configuration file if all checks succeed.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The New-ADDCCloneConfigFile cmdlet performs prerequisite checks for cloning a domain controller when run locally on the domain controller being prepared for cloning.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from SYNOPSIS; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-189 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [New-ADDCCloneConfigFile](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-addccloneconfigfile?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADDCCloneConfigFile - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-addccloneconfigfile?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADDCCloneConfigFile: create addcclone config file with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/new-addccloneconfigfile-create-addcclone-config-file-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADGroup: create adgroup with rollback checks > Use New-ADGroup to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adgroup-create-adgroup-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:54+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADGroup to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADGroup ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: New-ADGroup: create adgroup with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADGroup](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adgroup?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “Properties that cannot be set by cmdlet parameters can be set using the OtherAttributes parameter.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Name and GroupScope parameters specify the name and scope of the group and are required to create a new group.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from DESCRIPTION; DESCRIPTION to the observed environment. Useful domain evidence includes sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-152 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [New-ADGroup](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adgroup?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADGroup - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adgroup?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADGroup: create adgroup with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/new-adgroup-create-adgroup-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADObject: create adobject under AD/DNS change control > Use New-ADObject to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adobject-create-adobject-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:45+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADObject to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADObject ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: New-ADObject: create adobject under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADObject](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adobject?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The New-ADObject cmdlet creates an Active Directory object such as a new organizational unit (OU) or new user account.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can use this cmdlet to create any type of Active Directory object.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-161 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [New-ADObject](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adobject?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADObject - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adobject?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADObject: create adobject under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/new-adobject-create-adobject-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADOrganizationalUnit: create adorganizational unit against recorded identity and DNS state > Use New-ADOrganizationalUnit to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adorganizationalunit-create-adorganizational-unit-against-recorded-identity-and-dns-state/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:53+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADOrganizationalUnit to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADOrganizationalUnit ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: New-ADOrganizationalUnit: create adorganizational unit against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADOrganizationalUnit](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adorganizationalunit?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The New-ADOrganizationalUnit cmdlet creates an Active Directory organizational unit (OU).” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can set commonly used OU property values by using the cmdlet parameters.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from DESCRIPTION; DESCRIPTION to the observed environment. Useful domain evidence includes sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-153 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [New-ADOrganizationalUnit](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adorganizationalunit?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADOrganizationalUnit - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adorganizationalunit?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADOrganizationalUnit: create adorganizational unit against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/new-adorganizationalunit-create-adorganizational-unit-against-recorded-identity-and-dns-state/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADReplicationSite: create adreplication site under AD/DNS change control > Use New-ADReplicationSite to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adreplicationsite-create-adreplication-site-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:35+00:00 - Modified: 2026-08-27T17:14:53+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADReplicationSite to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADReplicationSite ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: New-ADReplicationSite: create adreplication site under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADReplicationSite](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adreplicationsite?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The New-ADReplicationSite cmdlet is used to create sites in Active Directory replication.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “Sites can also be used to optimize replication between domain controllers.” The research record locates this support at DESCRIPTION. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Within Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, which versions, roles, and configuration states define the review population? - Could Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations DESCRIPTION; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-111 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [New-ADReplicationSite](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adreplicationsite?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADReplicationSite - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adreplicationsite?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADReplicationSite: create adreplication site under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/new-adreplicationsite-create-adreplication-site-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADReplicationSiteLink: create adreplication site link with before-and-after evidence > Use New-ADReplicationSiteLink to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adreplicationsitelink-create-adreplication-site-link-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:27+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADReplicationSiteLink to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADReplicationSiteLink ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: New-ADReplicationSiteLink: create adreplication site link with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADReplicationSiteLink](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adreplicationsitelink?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Creates a new Active Directory site link for in managing replication.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The New-ADReplicationSiteLink cmdlet can be used to create a new Active Directory site link.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Within Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, which versions, roles, and configuration states define the review population? - Could Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from SYNOPSIS; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-119 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [New-ADReplicationSiteLink](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adreplicationsitelink?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADReplicationSiteLink - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adreplicationsitelink?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADReplicationSiteLink: create adreplication site link with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/new-adreplicationsitelink-create-adreplication-site-link-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADResourceProperty: create adresource property under AD/DNS change control > Use New-ADResourceProperty to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adresourceproperty-create-adresource-property-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:35+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADResourceProperty to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADResourceProperty ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: New-ADResourceProperty: create adresource property under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADResourceProperty](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adresourceproperty?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The New-ADResourceProperty cmdlet creates a resource property in the directory.” The research record locates this support at DESCRIPTION. - At Example 1: Create a resource property, Microsoft states: “This command creates a resource property with the display name Authors.” The research record locates this support at Example 1: Create a resource property. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Create a resource property, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; Example 1: Create a resource property. Favor sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-171 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [New-ADResourceProperty](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adresourceproperty?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADResourceProperty - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adresourceproperty?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADResourceProperty: create adresource property under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/new-adresourceproperty-create-adresource-property-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADServiceAccount: create adservice account under AD/DNS change control > Use New-ADServiceAccount to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-adserviceaccount-create-adservice-account-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:20+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADServiceAccount to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADServiceAccount ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: New-ADServiceAccount: create adservice account under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADServiceAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adserviceaccount?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Creates a new Active Directory managed service account or group managed service account object.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The New-ADServiceAccount cmdlet creates a new Active Directory managed service account.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from SYNOPSIS; DESCRIPTION to the observed environment. Useful domain evidence includes sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-126 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [New-ADServiceAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adserviceaccount?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADServiceAccount - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-adserviceaccount?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADServiceAccount: create adservice account under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/new-adserviceaccount-create-adservice-account-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # New-ADUser: create aduser against recorded identity and DNS state > Use New-ADUser to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/new-aduser-create-aduser-against-recorded-identity-and-dns-state/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:23+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use New-ADUser to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of New-ADUser ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: New-ADUser: create aduser against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [New-ADUser](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-aduser?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “You can set commonly used user property values by using the cmdlet parameters.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can set property values that are not associated with cmdlet parameters by using the OtherAttributes parameter.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Within Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, which versions, roles, and configuration states define the review population? - Could Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to DESCRIPTION; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-123 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [New-ADUser](https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-aduser?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: New-ADUser - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/new-aduser?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “New-ADUser: create aduser against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/new-aduser-create-aduser-against-recorded-identity-and-dns-state/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # NIST CSF 2.0 in plain English: a six-function roadmap > Use the six functions in NIST Cybersecurity Framework 2.0 to organize cyber risk decisions, assign ownership, identify gaps, and build a practical improvement roadmap without treating the framework as a one-size-fits-all checklist. - Canonical URL: https://update.dsesecurity.com/updates/nist-csf-2-six-function-roadmap/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:09+00:00 - Modified: 2026-07-19T19:03:09+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, Cybersecurity - Reading time: 2 minutes ## What you need to know Use the six functions in NIST Cybersecurity Framework 2.0 to organize cyber risk decisions, assign ownership, identify gaps, and build a practical improvement roadmap without treating the framework as a one-size-fits-all checklist. ## Potentially affected Business owners, executives, IT leaders, security leaders, and teams creating or refreshing a cybersecurity roadmap. ## DSE recommendation Name an owner for each CSF function, record current practices and evidence, then select a small set of risk-based improvements. ## Article The NIST Cybersecurity Framework 2.0 gives organizations a common language for managing cybersecurity risk. It describes outcomes rather than prescribing a particular product, vendor, or technical architecture. That makes it useful for a small organization beginning a program and for a mature organization aligning security work with business risk. ## What the official source says Source fact: NIST says CSF 2.0 is intended for organizations of all sizes and sectors. Its Core is organized around six functions: Govern, Identify, Protect, Detect, Respond, and Recover. NIST also states that implementation is not one-size-fits-all; each organization has different missions, risks, obligations, and risk tolerances. - Govern: establish risk-management strategy, policy, roles, oversight, and supply-chain expectations. - Identify: understand assets, dependencies, vulnerabilities, threats, and business impact. - Protect: apply safeguards such as identity controls, awareness, data protection, maintenance, and resilient technology. - Detect: find and analyze possible attacks, compromises, and abnormal activity. - Respond: manage, contain, communicate, analyze, and mitigate an incident. - Recover: restore affected operations and communicate during recovery. ## How to turn the framework into a roadmap DSE recommendation: begin with a business conversation, not a control spreadsheet. List the services that must continue, the data and systems they depend on, the people accountable for them, and the consequences of disruption. Then map existing policies, tools, contracts, diagrams, test results, and operating procedures to the six functions. - Assign an accountable business owner and an operational owner for each function. - Record what is actually performed today and link to evidence; do not count an unwritten intention as an operating practice. - Identify important gaps and dependencies, including suppliers and cloud services. - Prioritize improvements by business impact, credible threat, feasibility, and obligation. - Set a review date and define what evidence will show that each improvement works. NIST also supports the use of Organizational Profiles to describe selected current and target cybersecurity outcomes. DSE recommendation: keep the first profile focused. Record the present outcome, the desired outcome, the evidence used, and the reason the gap matters to the business. A target should be an informed risk decision, not an assumption that every possible outcome must be implemented at the same level. ## What the framework does not prove Using the CSF does not by itself establish regulatory compliance, certification, a particular maturity level, or protection from every incident. A completed worksheet is not the same as an implemented and tested safeguard. Legal, contractual, insurance, and sector requirements still need their own qualified review. Practical next step: choose one essential business service and trace it across all six functions. This narrow pilot usually exposes unclear ownership, undocumented dependencies, and untested recovery assumptions without requiring a disruptive organization-wide exercise. ## Primary reference - Name: NIST Cybersecurity Framework (CSF) 2.0 - Authority: National Institute of Standards and Technology - URL: https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20 - Source publication date: 2024-02-26 ## Citation and use Preferred citation: “NIST CSF 2.0 in plain English: a six-function roadmap,” DSE Security, https://update.dsesecurity.com/updates/nist-csf-2-six-function-roadmap/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Notify the NRC within 15 minutes of specified physical-security threats > Use 10 CFR 73.1200 - Notification of physical security events to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/notify-the-nrc-within-15-minutes-of-specified-physical-security-threats/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:53+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.1200 - Notification of physical security events to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.1200 - Notification of physical security events ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Notify the NRC within 15 minutes of specified physical-security threats. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.1200 – Notification of physical security events](https://www.ecfr.gov/current/title-10/section-73.1200) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - A covered facility licensee must notify the NRC Headquarters Operations Center as soon as possible, but within 15 minutes, after initiating a security response to imminent or actual hostile action. The research record locates this support at 10 CFR 73.1200(a)(1), read with 10 CFR 73.1200(a) (eCFR anchor p-73.1200(a)(1)). - That NRC notification must identify the facility and briefly state the event type and whether the threat is imminent, in progress, or neutralized. The research record locates this support at 10 CFR 73.1200(a)(3)(i) and 73.1200(a)(3)(ii), read with 10 CFR 73.1200(a)(3) (eCFR anchors p-73.1200(a)(3)(i) and p-73.1200(a)(3)(ii)). The source support ends with the statements listed above. Use them to examine access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This covers only facility events and licensees within 10 CFR 73.1200(a). Other subsections, written follow-up duties, emergency actions, and agency instructions remain separate. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 10 CFR 73.1200(a)(1), read with 10 CFR 73.1200(a) (eCFR anchor p-73.1200(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.1200(a)(3)(i) and 73.1200(a)(3)(ii), read with 10 CFR 73.1200(a)(3) (eCFR anchors p-73.1200(a)(3)(i) and p-73.1200(a)(3)(ii)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from 10 CFR 73.1200(a)(1), read with 10 CFR 73.1200(a) (eCFR anchor p-73.1200(a)(1)); 10 CFR 73.1200(a)(3)(i) and 73.1200(a)(3)(ii), read with 10 CFR 73.1200(a)(3) (eCFR anchors p-73.1200(a)(3)(i) and p-73.1200(a)(3)(ii)) to the observed environment. Useful domain evidence includes asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [10 CFR 73.1200 – Notification of physical security events](https://www.ecfr.gov/current/title-10/section-73.1200) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.1200 - Notification of physical security events - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.1200 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Notify the NRC within 15 minutes of specified physical-security threats,” DSE Security, https://update.dsesecurity.com/updates/notify-the-nrc-within-15-minutes-of-specified-physical-security-threats/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Notify TSA and protect operations when changed conditions affect airport security > Use 49 CFR 1542.107 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/notify-tsa-and-protect-operations-when-changed-conditions-affect-airport-security/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:37+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.107 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.107 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Notify TSA and protect operations when changed conditions affect airport security. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.107 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.107) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, the rule requires that for changed conditions expected to be less than 60 days duration, each airport operator forward the information required in paragraph (b) of this section in writing to TSA within 72 hours of the original notification of the change condition(s). The research record locates this support at 49 CFR 1542.107(c) (eCFR anchor p-1542.107(c)). - Under 49 CFR 1542, the rule requires that after approval of the security program, each airport operator notify TSA when changes have occurred to the: operations of an aircraft operator or foreign air carrier that would require modifications to the security program as required under section 1542.103. The research record locates this support at 49 CFR 1542.107(a)(2), read with 49 CFR 1542.107(a) (eCFR anchor p-1542.107(a)(2)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives and the conditions the source actually describes. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 49 CFR 1542.107(c) (eCFR anchor p-1542.107(c)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.107(a)(2), read with 49 CFR 1542.107(a) (eCFR anchor p-1542.107(a)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations 49 CFR 1542.107(c) (eCFR anchor p-1542.107(c)); 49 CFR 1542.107(a)(2), read with 49 CFR 1542.107(a) (eCFR anchor p-1542.107(a)(2)) adjacent to the sanitized artifacts used for comparison. Prefer business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [49 CFR 1542.107 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.107) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.107 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.107 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Notify TSA and protect operations when changed conditions affect airport security,” DSE Security, https://update.dsesecurity.com/updates/notify-tsa-and-protect-operations-when-changed-conditions-affect-airport-security/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Obtain TSA approval before implementing airport security-program amendments > Use 49 CFR 1542.105 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/obtain-tsa-approval-before-implementing-airport-security-program-amendments/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:38+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.105 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.105 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Obtain TSA approval before implementing airport security-program amendments. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.105 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.105) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, the airport operator may either submit a modified security program to the designated official for approval, or petition the Administrator to reconsider the notice to modify within 30 days of receiving a notice to modify. The research record locates this support at 49 CFR 1542.105(a)(2) (eCFR anchor p-1542.105(a)(2)). - Under 49 CFR 1542, the designated official, within 30 days after receiving the proposed security program, will either approve the program or give the airport operator written notice to modify the program to comply with the applicable requirements of this part. The research record locates this support at 49 CFR 1542.105(a)(1) (eCFR anchor p-1542.105(a)(1)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths and the conditions the source actually describes. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 49 CFR 1542.105(a)(2) (eCFR anchor p-1542.105(a)(2)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.105(a)(1) (eCFR anchor p-1542.105(a)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations 49 CFR 1542.105(a)(2) (eCFR anchor p-1542.105(a)(2)); 49 CFR 1542.105(a)(1) (eCFR anchor p-1542.105(a)(1)) adjacent to the sanitized artifacts used for comparison. Prefer asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [49 CFR 1542.105 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.105) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.105 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.105 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Obtain TSA approval before implementing airport security-program amendments,” DSE Security, https://update.dsesecurity.com/updates/obtain-tsa-approval-before-implementing-airport-security-program-amendments/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Onboard connected security devices without lending trust first > NIST SP 1800-36 demonstrates how an IP network and IoT device can establish identity and posture before the device receives operational network credentials—and how that trust can be renewed across its lifecycle. - Canonical URL: https://update.dsesecurity.com/updates/onboard-connected-security-devices-without-lending-trust-first/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Explainer - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Networks & Infrastructure, Video Surveillance - Reading time: 4 minutes ## What you need to know NIST SP 1800-36 demonstrates how an IP network and IoT device can establish identity and posture before the device receives operational network credentials—and how that trust can be renewed across its lifecycle. ## Potentially affected Organizations procuring and operating IP cameras, intercoms, access-control appliances, sensors, gateways, and other connected security devices whose products and network support trusted onboarding mechanisms. ## DSE recommendation Map the current onboarding path, define device and network trust anchors, require exact vendor evidence, pilot a quarantine-to-production workflow, and prove credential rotation, revocation, reset, and re-onboarding. ## Article ## Source fact: onboarding is a security decision [NIST SP 1800-36](https://csrc.nist.gov/pubs/sp/1800/36/final), finalized in November 2025, defines network-layer onboarding as provisioning an IoT device with the credentials it needs to join an IP network. NIST describes two risks in an untrusted process: a malicious device may enter an authorized network, or a legitimate device may be induced to join an unauthorized network. Trusted onboarding lets the device and network establish trust before operational credentials are issued. [NISTIR 8350](https://csrc.nist.gov/pubs/ir/8350/final) describes trusted onboarding as providing each device unique network credentials, giving device and network an opportunity to authenticate each other, using an encrypted channel, keeping people from learning the network credentials, and allowing the process to be repeated so credentials can be replaced. SP 1800-36 demonstrates example architectures using standards, best practices, and commercial technology. It is a practice guide, not a claim that every camera or access device supports every demonstrated method. ## Understand the boundary Network-layer onboarding answers how a device earns network credentials. Application-layer onboarding answers how it enrolls into a video manager, access platform, cloud service, or mobile app. Asset authorization answers whether that exact model, serial number, owner, location, firmware, and purpose were approved. These controls can reinforce one another, but completing one does not complete the others. Likewise, onboarding is not permanent trust. A correctly identified device can later become vulnerable, misconfigured, stolen, reassigned, or unsupported. NIST pairs onboarding with lifecycle capabilities such as posture checks, credential management, device intent enforcement, and secure management. ## DSE recommendation: design six explicit states - Expected: Procurement records the supported identity, trust anchor, onboarding protocol, credential type, attestation or posture evidence, reset behavior, ownership transfer, and end-of-support commitments for the exact product and firmware. - Untrusted: A new or reset device reaches only the tightly limited services needed to identify and onboard it. It does not inherit ordinary camera, controller, server, or internet access from the jack. - Validated: The onboarding service validates device evidence and the device validates the authorized network according to the selected mechanism. Failed or ambiguous validation creates an actionable record. - Provisioned: Unique credentials are delivered through the protected onboarding exchange. The asset record binds the credential to device, owner, site, policy, and issuance event without exposing secret material. - Authorized: Network policy grants only the production flows required for the approved role. Application enrollment, hardening, updates, logging, and acceptance tests still occur separately. - Removed: Loss, replacement, compromise, factory reset, reassignment, or retirement revokes credentials and policy, removes application trust, and prevents silent return. ## Build prerequisites before buying an onboarding product Inventory the switches, wireless infrastructure, network-access control, identity and certificate services, device-management platforms, DNS, time, logging, and recovery dependencies involved. Decide who can approve a device, which trust anchors are accepted, what evidence is stored, how certificate or credential expiry is monitored, and what happens when a validation service is unavailable. Ask manufacturers to demonstrate the exact model and software path. Marketing terms such as secure onboarding, zero touch, certificate-based, or zero trust do not establish mutual authentication, unique credentials, protected delivery, posture evidence, or rotation. Require protocol and certificate details, failure behavior, renewal, reset, transfer, revocation, audit output, supported infrastructure, and licensing in writing. ## Pilot the failure paths Use a lab or isolated production pilot with representative devices. Attempt an unknown device, a device with invalid or expired evidence, a duplicated identity, an unauthorized onboarding service, interrupted provisioning, wrong network policy, failed credential rotation, factory reset, and return after revocation. Confirm that failure is closed or intentionally quarantined, visible to operations, and recoverable without sharing a fleet-wide credential. Measure operational cost as well as technical success: deployment time, exception rate, certificate renewal, replacement workflow, inventory accuracy, help-desk visibility, and recovery during identity-service or network outage. An architecture that only a specialist can repair may create availability risk for doors and video. ## Adopt the pattern, not an assumption Trusted onboarding can reduce reliance on shared secrets and manual provisioning, but it does not eliminate segmentation, secure configuration, software updates, vulnerability response, application authorization, backups, or monitoring. Where legacy devices cannot participate, document compensating controls and a replacement plan. DSE recommends using SP 1800-36 as a requirements and pilot guide, then validating every capability against the products actually deployed. ## Official sources - [NIST SP 1800-36, complete practice guide](https://doi.org/10.6028/NIST.SP.1800-36) - [NISTIR 8350, Foundational Concepts in Trusted IoT Device Network-Layer Onboarding](https://csrc.nist.gov/pubs/ir/8350/final) - [NIST CSWP 42, Towards Automating IoT Security](https://csrc.nist.gov/pubs/cswp/42/towards-automating-iot-security-implementing-trust/final) - [NCCoE project page and component volumes](https://www.nccoe.nist.gov/projects/trusted-iot-device-network-layer-onboarding-and-lifecycle-management) ## Primary reference - Name: NIST SP 1800-36 — Trusted IoT Device Network-Layer Onboarding and Lifecycle Management - Authority: Digital Object Identifier - URL: https://doi.org/10.6028/NIST.SP.1800-36 - Source publication date: 2025-11-25 ## Citation and use Preferred citation: “Onboard connected security devices without lending trust first,” DSE Security, https://update.dsesecurity.com/updates/onboard-connected-security-devices-without-lending-trust-first/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # ONVIF Profile D: keep access decisions in the right place when integrating peripherals > Profile D standardizes communication between access peripherals and a securely located client. It does not certify the complete door, credential, or life-safety design. - Canonical URL: https://update.dsesecurity.com/updates/onvif-profile-d-access-peripheral-decision-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:39+00:00 - Modified: 2026-07-19T21:28:39+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Networks & Infrastructure, Video Surveillance - Reading time: 2 minutes ## What you need to know Profile D standardizes communication between access peripherals and a securely located client. It does not certify the complete door, credential, or life-safety design. ## Potentially affected Organizations integrating readers, biometric devices, keypads, locks, sensors, displays, door phones, recognition cameras, access-control units, or management platforms. ## DSE recommendation Document where credentials, rules, and decisions reside, verify exact Profile D conformance, and separately test network, door, credential, and life-safety behavior. ## Article ## What Profile D connects Source fact: ONVIF Profile D addresses interfaces for access-control peripheral devices. The official scope includes token readers for cards, keys, mobile phones, or bar codes; biometric readers; keypads; sensors; locks; displays; LEDs; and cameras used for iris, facial, or license-plate recognition. The profile separates capture from the access decision. A peripheral device captures a credential identifier and passes it to a securely located Profile D client, such as an access-control unit or management system. The client holds the access rules, schedules, and credentials, decides whether access should be granted, and can command the peripheral to grant or deny access, show a message, or request another input such as a PIN. A conformant client can configure information such as the door or access point for which a device is responsible. It can also configure allowed or blocked credential identifiers when the device supports that capability. Profile D complements Profiles A and C and can be combined with Profiles M and T in an integrated video and access-control design. ## Where the profile stops Profile D defines an interface; it does not certify a complete opening. It does not establish lock suitability, egress behavior, fire-code compliance, power capacity, battery runtime, cable condition, credential cryptography, biometric accuracy, network segmentation, or the security of every stored record. A profile claim also belongs to an exact product and firmware or software version. Conditional capability matters. A product type appearing in the Profile D scope does not mean every conformant device provides every recognition, local-list, display, or integrated-video function. Project requirements must be matched to the official feature documents and then tested with the intended client. ## DSE integration checklist DSE recommendation: This is DSE operational synthesis, not an ONVIF door-hardware or code-compliance procedure. - Diagram each peripheral, securely located client, controller, server, door, network path, and stored-data location. - Identify which component captures an identifier, stores rules, makes the decision, and operates the output. - Verify exact Profile D records and feature documents for both client and device. - Test valid, invalid, expired, blocked, and unknown credentials plus any PIN or second-input workflow. - Test loss and restoration of the client or network, including documented offline behavior. - Verify lock, sensor, message, audit, and video association functions required by the design. - Validate power, wiring, egress, fire alarm, accessibility, and life-safety behavior through the appropriate qualified process. - Retain the tested versions, results, exceptions, and recovery steps with commissioning records. ## Official references - [Profile D](https://www.onvif.org/profiles/profile-d/) — current peripheral, client, decision, and configuration scope. - [ONVIF Releases Profile D for Access Control Peripherals](https://www.onvif.org/pressrelease/onvif-releases-profile-d-for-access-control-peripherals/) — the July 14, 2021 release and architecture examples. - [Conformant Products](https://www.onvif.org/conformant-products/) — exact model, version, and profile verification. ## Primary reference - Name: ONVIF — Profile D - Authority: ONVIF - URL: https://www.onvif.org/profiles/profile-d/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “ONVIF Profile D: keep access decisions in the right place when integrating peripherals,” DSE Security, https://update.dsesecurity.com/updates/onvif-profile-d-access-peripheral-decision-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # ONVIF Profile G acceptance testing for edge recording and retrieval > Profile G standardizes important recording and retrieval interfaces, but a resilient edge-recording design still needs capacity, outage, recovery, and evidence tests. - Canonical URL: https://update.dsesecurity.com/updates/onvif-profile-g-edge-recording-acceptance-testing/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:39+00:00 - Modified: 2026-07-19T21:28:39+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Networks & Infrastructure, Video Surveillance - Reading time: 2 minutes ## What you need to know Profile G standardizes important recording and retrieval interfaces, but a resilient edge-recording design still needs capacity, outage, recovery, and evidence tests. ## Potentially affected Video systems using camera or encoder storage, recording-capable devices, NVRs, VMS clients, or edge recording as a primary recorder or network-outage safeguard. ## DSE recommendation Verify exact Profile G conformance and run controlled storage, outage, retrieval, and reintegration tests against the real camera, media, and VMS combination. ## Article ## What Profile G covers Source fact: ONVIF Profile G is designed for IP-based video storage and retrieval. A conformant device, such as a network camera or encoder, can record video over the network or on the device itself. A conformant client, such as VMS software, can configure, request, and control recording from a Profile G device. ONVIF’s 2014 release announcement describes a broader recording workflow that includes on-board storage, search, retrieval, and media playback. The current profile page also identifies receipt of audio and metadata streams when the client supports those features. That conditional wording is important: a Profile G label alone does not establish that every client accepts audio or metadata. Profile G provides standardized interfaces, not a storage-service guarantee. It does not assign an SD-card endurance rating, calculate retention, promise uninterrupted capture for every outage, validate timestamps, or certify that a VMS will reconcile every edge recording after connectivity returns. Those outcomes depend on the exact device, media, client, configuration, clock source, network behavior, and supported features. ## Define the recovery use case First decide why edge storage exists. It may be the primary recording destination, a short network-failure buffer, or a secondary evidence source. Define the expected recording mode, event triggers, frame rate, bitrate, audio and metadata needs, retention target, and maximum anticipated outage. Use manufacturer endurance and compatibility information for the actual media rather than deriving capacity from Profile G. Conformance must be checked for both sides of the intended workflow and for their exact installed versions. A feature list should be reviewed before testing so a conditional function is not mistaken for a universal requirement. ## DSE acceptance checklist DSE recommendation: This checklist is DSE operational synthesis; ONVIF does not prescribe this site-test sequence. - Verify the exact device and client versions in ONVIF’s registry and retain their feature documents. - Confirm supported media, health monitoring, usable capacity, overwrite behavior, and time synchronization from current manufacturer guidance. - Create known recordings and prove search, retrieval, playback, timestamps, and export from the client. - Where required, confirm that audio and metadata survive the complete recording and retrieval path. - Simulate an approved network interruption, keep it within the designed duration, and document device behavior. - Restore connectivity and verify discovery, backlog availability, chronology, duplicates, gaps, and VMS reconciliation. - Test full, removed, failed, or replaced media using safe procedures supported by the manufacturer. - Record the tested limits and schedule periodic health and retrieval checks. ## Official references - [Profile G](https://www.onvif.org/profiles/profile-g/) — current device, client, recording, audio, and metadata scope. - [ONVIF Releases Profile G for Video Storage and Recording](https://www.onvif.org/pressrelease/onvif-releases-profile-g-for-video-storage-and-recording/) — the July 2, 2014 storage, search, retrieval, and playback release scope. - [Conformant Products](https://www.onvif.org/conformant-products/) — exact product and version verification. ## Primary reference - Name: ONVIF — Profile G - Authority: ONVIF - URL: https://www.onvif.org/profiles/profile-g/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “ONVIF Profile G acceptance testing for edge recording and retrieval,” DSE Security, https://update.dsesecurity.com/updates/onvif-profile-g-edge-recording-acceptance-testing/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # ONVIF Profile M: what analytics metadata interoperability does—and does not—prove > Profile M standardizes analytics metadata and events between products. It does not certify analytic accuracy, lawful use, model quality, or every conditional feature. - Canonical URL: https://update.dsesecurity.com/updates/onvif-profile-m-analytics-metadata-boundaries/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:39+00:00 - Modified: 2026-07-19T21:28:39+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Explainer - DSE priority: Information - Topics: Cybersecurity, Networks & Infrastructure, Video Surveillance - Reading time: 2 minutes ## What you need to know Profile M standardizes analytics metadata and events between products. It does not certify analytic accuracy, lawful use, model quality, or every conditional feature. ## Potentially affected Organizations evaluating or operating cameras, analytics services, VMS platforms, NVRs, cloud services, MQTT integrations, or access workflows that exchange analytics metadata. ## DSE recommendation Specify the exact metadata and events required, verify both producer and consumer conformance, and test interoperability separately from analytic performance and privacy. ## Article ## What Profile M standardizes Source fact: ONVIF Profile M addresses metadata and events for analytics applications. Its defined interfaces include analytics configuration and information queries, metadata configuration and streaming, filtering, generic object classification, and specified metadata for geolocation, vehicles, license plates, human faces, and human bodies. The profile also includes event interfaces for object counting, face recognition, and license-plate recognition. ONVIF explains that these interfaces apply when a conformant product natively supports the corresponding feature. Events can travel through a metadata stream, the ONVIF event service, or MQTT when MQTT is supported. Rule configuration and images in metadata are also subject to the product’s supported capabilities. A Profile M producer can be an edge device such as an IP camera or a server- or cloud-based analytics service. A client can be a VMS, NVR, analytics application, or server/cloud service that consumes or controls metadata. Profile M can be combined with video and access-control profiles, but each claimed profile and exact software version must be verified independently. ## What conformance does not measure Profile M defines interfaces and data structures. It does not certify detection accuracy, false-alarm rate, demographic performance, training data, model security, image suitability, evidentiary value, or compliance with privacy law. It also does not mean every possible object, event, MQTT function, or rule is present; the distinction between mandatory and conditional features still applies. Two conformant products can exchange metadata and still produce different operator experiences, search results, event timing, or analytic outcomes. Accuracy and suitability must therefore be evaluated with representative scenes and a documented purpose, separate from the protocol test. ## DSE evaluation checklist DSE recommendation: The following is DSE operational synthesis, not an ONVIF accuracy or privacy standard. - Write the security or operational use case before selecting object classes or events. - List required fields, event transports, images, rules, timestamps, identifiers, and downstream actions. - Verify the exact Profile M record and feature documents for every producer and consumer. - Bench-test configuration, filtering, event delivery, metadata preservation, time alignment, reconnect behavior, and search. - Measure false positives and false negatives with representative site conditions; do not infer accuracy from conformance. - Complete a privacy assessment covering purpose, notice, access, retention, sharing, and any biometric or identifying data. - Require human review and a safe failure path before metadata triggers a consequential physical or business action. - Retest after model, camera, VMS, rule, or firmware changes. ## Official references - [Profile M](https://www.onvif.org/profiles/profile-m/) — current feature, producer, client, event, and conditional-capability scope. - [ONVIF announces the release of Profile M](https://www.onvif.org/blog/2021/06/30/onvif-announces-the-release-of-profile-m/) — the June 30, 2021 release and interoperability use cases. - [Conformant Products](https://www.onvif.org/conformant-products/) — authoritative model and version verification. ## Primary reference - Name: ONVIF — Profile M - Authority: ONVIF - URL: https://www.onvif.org/profiles/profile-m/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “ONVIF Profile M: what analytics metadata interoperability does—and does not—prove,” DSE Security, https://update.dsesecurity.com/updates/onvif-profile-m-analytics-metadata-boundaries/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # ONVIF Profile S support ends March 31, 2027: plan a tested move to Profile T > ONVIF will end Profile S support on March 31, 2027, but deployed systems do not simply stop on that date. Inventory authentication and codec dependencies before testing Profile T. - Canonical URL: https://update.dsesecurity.com/updates/onvif-profile-s-support-end-profile-t-migration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:15+00:00 - Modified: 2026-07-19T21:28:15+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Briefing - DSE priority: Important - Topics: Cybersecurity, Networks & Infrastructure, Video Surveillance - Reading time: 2 minutes ## What you need to know ONVIF will end Profile S support on March 31, 2027, but deployed systems do not simply stop on that date. Inventory authentication and codec dependencies before testing Profile T. ## Potentially affected Organizations operating or procuring ONVIF Profile S cameras, encoders, recorders, video management systems, or integrations, especially those using username-token authentication. ## DSE recommendation Identify Profile-S-only dependencies, verify exact product and firmware conformance, and test stronger authentication and Profile T workflows before making production changes. ## Article ## What ONVIF has announced Source fact: ONVIF states that support for Profile S will end on March 31, 2027. After that date, manufacturers will not be able to submit new products, or older products with new firmware or software versions, for Profile S conformance. The June 2026 release of ONVIF’s conformance test tools is the last release that permits Profile S claims during its validity period. The date is a conformance-lifecycle milestone, not a remote shutdown. ONVIF says deployed Profile S devices and clients can continue basic video streaming. A specific registered firmware or software version remains conformant unless its manufacturer withdraws the Declaration of Conformance. ONVIF also notes that existing integrations can be affected later if a vendor removes an implementation or authentication method in newer software. The security reason matters. Profile S mandates username-token authentication, which ONVIF now regards as too weak to protect against unauthorized access. ONVIF encourages users to discontinue that method where possible and use stronger mechanisms, including digest authentication in Profile T or TLS in HTTPS mode. Profile T contains virtually all Profile S features and adds capabilities such as H.264/H.265, imaging configuration, alarms, metadata, and conditional HTTPS media transport. ## Compatibility boundaries Profile T is not an exact feature-for-feature declaration. ONVIF’s Q&A says username-token authentication, IP-address filtering, MJPEG, and MPEG-4 are not covered by Profile T, even though an individual product might still support some of them natively. Conformance must also be checked against the exact model and firmware or software version. None of this authorizes a fleet-wide upgrade without the camera, VMS, recorder, analytics, and export paths being tested together. ## DSE operational checklist DSE recommendation: The following is DSE operational synthesis based on the ONVIF material, not an ONVIF-mandated migration sequence. - Inventory devices and clients that are Profile S only, dual Profile S/Profile T, or not found in the official database. - Record exact firmware, software, authentication method, codecs, and any IP-filter or legacy-stream dependency. - Verify each exact version in the ONVIF Conformant Products database and retain its feature list. - Ask manufacturers which supported release and authentication path they recommend after Profile S support ends. - Bench-test digest authentication, HTTPS, live and recorded video, PTZ, audio, metadata, events, analytics, and export. - Stage production changes in coverage-aware groups with a documented recovery path. - Assign an owner and replacement date to any dependency that cannot move safely. ## Official references - [Profile S Deprecation Q&A](https://www.onvif.org/profiles/profile-s/profile-s-deprecation-qna/) — the March 31, 2027 date, continuing-use boundary, authentication guidance, and feature comparison. - [ONVIF to End Support for Profile S; Recommends Profile T as Replacement](https://www.onvif.org/pressrelease/onvif-to-end-support-for-profile-s/) — the October 9, 2025 announcement and conformance-tool timeline. - [Profile T](https://www.onvif.org/profiles/profile-t/) — the current official Profile T capability summary. ## Primary reference - Name: ONVIF — Profile S Deprecation Q&A - Authority: ONVIF - URL: https://www.onvif.org/profiles/profile-s/profile-s-deprecation-qna/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “ONVIF Profile S support ends March 31, 2027: plan a tested move to Profile T,” DSE Security, https://update.dsesecurity.com/updates/onvif-profile-s-support-end-profile-t-migration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # ONVIF TLS Configuration Add-on v1.0: manage the transition without guessing > ONVIF is ending new v1.0 conformance submissions on March 31, 2027. Version 2.0 is scheduled, not yet a final conformance target, so plans need vendor evidence. - Canonical URL: https://update.dsesecurity.com/updates/onvif-tls-configuration-addon-v1-transition/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:39+00:00 - Modified: 2026-07-19T21:28:39+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Briefing - DSE priority: Important - Topics: Access Control, Cybersecurity, Networks & Infrastructure, Video Surveillance - Reading time: 2 minutes ## What you need to know ONVIF is ending new v1.0 conformance submissions on March 31, 2027. Version 2.0 is scheduled, not yet a final conformance target, so plans need vendor evidence. ## Potentially affected Organizations procuring or operating ONVIF clients and devices that claim the TLS Configuration Add-on, or that depend on centrally configured TLS for physical-security traffic. ## DSE recommendation Inventory exact add-on claims, certificate and trust dependencies, and vendor transition plans while testing current TLS behavior without assuming a future specification. ## Article ## What version 1.0 establishes Source fact: The ONVIF TLS Configuration Add-on provides a standardized way for a conformant client to perform the initial configuration and later update of TLS settings on a conformant device. It addresses encrypted communication between ONVIF clients and devices using Transport Layer Security. Support is required on both sides. A client with the add-on can configure a device only when that device supports the same add-on. The version 1.0 specification, dated December 2023, also states that ONVIF Network Interface Specifications version 22.06 or later are required for conformance. ONVIF’s current lifecycle notice says the last date for product conformance submissions for version 1.0 is March 31, 2027. The page says version 2.0 is scheduled for early 2027 to replace it. As of this review, that is schedule information, not a final version 2.0 specification or a confirmed product capability. Procurement and migration decisions should not invent requirements for an unpublished final release. ## What the add-on does not prove Add-on conformance does not establish that every physical-security protocol or media stream is encrypted. It does not validate an organization’s certificate authority, trust-store distribution, certificate names, renewal process, cipher policy, or operational response to expiration. Those outcomes depend on product implementation, configuration, client/device compatibility, and the wider architecture. A product’s general TLS capability is also not the same as an official add-on claim. Exact model and firmware or software records should be checked in ONVIF’s database. Version 1.0 deployments remain real systems to manage; the submission deadline does not itself disable them. ## DSE transition checklist DSE recommendation: This is DSE operational synthesis. It does not predict the content or release date of version 2.0. - Inventory each client and device, exact firmware or software, claimed add-on version, and official database record. - Map which control, event, configuration, and media paths actually use TLS and which do not. - Record certificate issuer, subject names, trust stores, expiry, renewal owner, and recovery access. - Ask manufacturers for documented support and transition plans; separate commitments from roadmaps. - Test initial configuration, renewal, expired or untrusted certificates, reconnect behavior, and client compatibility in a lab. - Avoid specifying version 2.0 details until ONVIF publishes a final specification and conformant products are listed. - Review ONVIF and manufacturer notices on a defined cadence and update the plan when evidence changes. ## Official references - [TLS Configuration Add-on](https://www.onvif.org/add-on/tls-configuration-add-on/) — current purpose and lifecycle notice. - [TLS Configuration Add-on Specification v1.0](https://www.onvif.org/wp-content/uploads/2024/01/tls-configuration-addon-spec-v1-0.pdf) — December 2023 requirements. - [Conformant Products](https://www.onvif.org/conformant-products/) — authoritative product, version, profile, and add-on claims. ## Primary reference - Name: ONVIF — TLS Configuration Add-on - Authority: ONVIF - URL: https://www.onvif.org/add-on/tls-configuration-add-on/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “ONVIF TLS Configuration Add-on v1.0: manage the transition without guessing,” DSE Security, https://update.dsesecurity.com/updates/onvif-tls-configuration-addon-v1-transition/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Operate a TSA-approved airport security program for covered operations > Use 49 CFR 1542.101 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/operate-a-tsa-approved-airport-security-program-for-covered-operations/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:40+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.101 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.101 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Operate a TSA-approved airport security program for covered operations. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.101 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.101) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, the rule requires that each airport operator subject to section 1542.103 maintain one current and complete copy of its security program and provide a copy to TSA upon request. The research record locates this support at 49 CFR 1542.101(b) (eCFR anchor p-1542.101(b)). - Under 49 CFR 1542, no person may operate an airport subject to section 1542.103 unless it adopts and carries out a security program that includes the applicable items listed in section 1542.103. The research record locates this support at 49 CFR 1542.101(a)(3), read with 49 CFR 1542.101(a) (eCFR anchor p-1542.101(a)(3)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths and the conditions the source actually describes. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 49 CFR 1542.101(b) (eCFR anchor p-1542.101(b)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.101(a)(3), read with 49 CFR 1542.101(a) (eCFR anchor p-1542.101(a)(3)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations 49 CFR 1542.101(b) (eCFR anchor p-1542.101(b)); 49 CFR 1542.101(a)(3), read with 49 CFR 1542.101(a) (eCFR anchor p-1542.101(a)(3)) adjacent to the sanitized artifacts used for comparison. Prefer asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [49 CFR 1542.101 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.101) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.101 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.101 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Operate a TSA-approved airport security program for covered operations,” DSE Security, https://update.dsesecurity.com/updates/operate-a-tsa-approved-airport-security-program-for-covered-operations/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Operate Windows certificate trust lists in disconnected networks > Use Certificates and Trust Management in Windows to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/operate-certificate-trust-lists-in-disconnected-networks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:10+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Certificates and Trust Management in Windows to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Certificates and Trust Management in Windows ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Operate Windows certificate trust lists in disconnected networks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Certificates and Trust Management in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-trust) from Microsoft supports the following bounded statements: - The Microsoft Root Certificate Program distributes trusted and untrusted root information used by Windows trust decisions. The research record locates this support at Opening overview. - Trusted and untrusted certificate-list functionality is designed for connected and disconnected environments. The research record locates this support at Opening overview. Keep the evidence boundary at these traced claims. They support a review of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish A disconnected trust-store process must include authenticated distribution, expiry monitoring, and rollback. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles are in and out of scope? - Which condition in Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Opening overview through CA and template exports, enrollment tests, certificate chains, access-control entries, event logs, and revocation-path checks. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Certificates and Trust Management in Windows](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-trust) — Microsoft ## Primary reference - Name: Certificates and Trust Management in Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-trust - Source publication date: 2025-05-21 ## Citation and use Preferred citation: “Operate Windows certificate trust lists in disconnected networks,” DSE Security, https://update.dsesecurity.com/updates/operate-certificate-trust-lists-in-disconnected-networks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Operate Windows Server 2025 Hotpatch without pretending reboots disappeared > Windows Server 2025 Hotpatch can remove restarts from many monthly Windows update cycles, but planned and unplanned baselines, .NET, drivers, firmware, and other updates still need maintenance. Build the service around the complete reboot calendar. - Canonical URL: https://update.dsesecurity.com/updates/operate-windows-server-2025-hotpatch-reboot-cadence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:25:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Windows Server 2025 Hotpatch can remove restarts from many monthly Windows update cycles, but planned and unplanned baselines, .NET, drivers, firmware, and other updates still need maintenance. Build the service around the complete reboot calendar. ## Potentially affected Windows Server 2025 Standard and Datacenter systems connected to Azure Arc; supported Windows Server Datacenter: Azure Edition virtual machines; Azure Update Manager; workloads with constrained maintenance windows. ## DSE recommendation Inventory eligible servers, verify the documented platform prerequisites, enroll a representative pilot, map baseline and non-Hotpatch restart needs, and approve each cycle only after workload-level validation and recorded recovery evidence. ## Article ## Source facts: Hotpatch changes the cadence, not the operating responsibility Microsoft describes [Hotpatch for Windows Server](https://learn.microsoft.com/en-us/windows-server/get-started/hotpatch) as a way to apply eligible Windows operating-system updates by patching in-memory code without restarting the server or its processes. For Azure Arc-connected machines, Microsoft currently lists Windows Server 2025 Standard and Datacenter as eligible editions after Hotpatch is enabled. Supported Windows Server Datacenter: Azure Edition images in Azure and Azure Local follow their documented image and orchestration requirements. Custom images, containers, and unlisted offer-and-SKU combinations are not automatically covered by the Azure image support table. The servicing pattern is built around baselines. A planned baseline uses the current cumulative update and requires a restart. Microsoft describes a typical cycle as a baseline month followed by two Hotpatch months. An unplanned baseline can replace a Hotpatch release when an update cannot be delivered as a Hotpatch, and that baseline also requires a restart. Microsoft therefore presents Hotpatch as fewer restarts, not a restart-free server. The boundary matters. Microsoft says Hotpatch covers the Windows update content included in its program, while nonsecurity Windows updates, .NET updates, drivers, firmware, and non-Windows updates are outside that Hotpatch scope and can still require conventional installation and restart handling. The documentation also states that Hotpatch updates do not provide automatic rollback; recovery from a problematic Hotpatch can require uninstalling it, installing the last functional baseline, and restarting. As of this review, Microsoft states that Azure Arc-enabled Hotpatch for eligible Windows Server 2025 machines is available at no extra Hotpatch cost. Azure connectivity, Azure Arc requirements, supported build and edition, virtualization-based security prerequisites, management tooling, and any other Azure services used by the design still need to be confirmed for each environment. ## DSE recommendation: operate one calendar for every update class Do not divide the server program into “Hotpatch machines” and “machines that need maintenance.” Keep a single maintenance register that shows the next planned baseline, any announced unplanned baseline, .NET servicing, application updates, agents, drivers, firmware, and vendor maintenance for every workload. Hotpatch is a scheduling input within that register. - Prove eligibility. Record edition, build, installation type, physical or virtual platform, Azure Arc state, required agents, virtualization-based security state, update source, and orchestration owner. Treat portal enrollment as incomplete until the server reports the expected Hotpatch status. - Use a representative pilot. Include each important application pattern, not merely an idle utility server. Exercise services, scheduled work, integrations, storage, printing, monitoring, backup agents, and any latency-sensitive role after the update. - Publish a twelve-month restart forecast. Mark expected baseline months and the normal restart window. Reserve a path for unplanned baselines and out-of-band workload maintenance. A forecast is not a promise that a particular month will remain restart-free. - Separate install success from service health. Capture update status and build, then test the business service through its normal client and dependency path. A successful Windows update record does not prove that the application completed its own recovery. - Keep recovery executable. Confirm supported backup or recovery methods, application-specific shutdown requirements, the last functional baseline, console access, escalation contacts, and the authority to extend or reverse a change. - Reconcile exceptions. Servers that miss a baseline, receive an out-of-band update, lose Arc connectivity, or drift from the approved build need an explicit disposition before the next Hotpatch cycle. Measure the program by avoided workload interruptions, completed baselines, update currency, application test success, exception age, and recovery performance. Do not count “no reboot requested” as the sole success condition. A server can remain online while a dependent service is degraded, and an update outside the Hotpatch scope can still be waiting for a restart. The durable benefit is predictable servicing: routine eligible months can have less disruption, while baseline and exceptional maintenance remain visible, rehearsed, and owned. ## Official references - Microsoft Learn, [Hotpatch for Windows Server](https://learn.microsoft.com/en-us/windows-server/get-started/hotpatch), July 14, 2025; documentation reviewed August 11, 2026. - Microsoft Learn, [Windows Server release information](https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info), including the current Hotpatch calendar. ## Primary reference - Name: Microsoft Learn: Hotpatch for Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/get-started/hotpatch - Source publication date: 2025-07-14 ## Citation and use Preferred citation: “Operate Windows Server 2025 Hotpatch without pretending reboots disappeared,” DSE Security, https://update.dsesecurity.com/updates/operate-windows-server-2025-hotpatch-reboot-cadence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # OSDP commissioning evidence: Verified profiles, Secure Channel, cabling, and load > A successful OSDP installation needs evidence for exact verified products, Secure Channel, addressing, cabling, power, features, and performance under load. - Canonical URL: https://update.dsesecurity.com/updates/osdp-commissioning-verified-secure-channel-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:28:39+00:00 - Modified: 2026-07-19T21:28:39+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 2 minutes ## What you need to know A successful OSDP installation needs evidence for exact verified products, Secure Channel, addressing, cabling, power, features, and performance under load. ## Potentially affected New or migrated OSDP reader-to-controller connections, including peripheral devices, access-control units, multidrop buses, reused cabling, and remote-management designs. ## DSE recommendation Commission the exact peripheral and controller combination with documented verification records, key ownership, electrical tests, functional tests, and post-install results. ## Article ## Verification is specific Source fact: SIA distinguishes a vendor statement that a device “supports OSDP” from OSDP Verified status. The Verified program uses third-party testing to validate conformance to the standard and related performance profiles. SIA’s implementation checklist recommends checking both the peripheral device and the access-control unit, including the certified firmware and the profiles and features required by the project. The official product directory lists Secure, Smart Card, and Biometric profiles. It also warns that verification does not automatically guarantee interoperability because an implementer still has design decisions to make. Required capabilities can include multidrop operation, reader count, structured smart-card data, biometric messages, and remote file transfer. They should be selected explicitly rather than inferred from the protocol name. ## Secure Channel and the physical layer SIA describes OSDP Secure Channel as the protected mode that encrypts data exchanged between readers and controllers. Its 2026 checklist says unsecured mode should exist only during initialization before Secure Channel communication is established. Commissioning therefore needs evidence that protected negotiation succeeded, not merely that credential reads appeared in software. For new work, SIA calls for cabling rated for two-wire RS-485. Existing cable should be tested with an appropriate OSDP cable test tool rather than assumed suitable. Power also has to account for long runs, mixed devices, and voltage drop. The checklist recommends bench testing, unique peripheral addresses, documented speeds and keys, and post-install checks for stability, response, and signal integrity. ## DSE commissioning checklist DSE recommendation: This is DSE operational synthesis organized from SIA’s checklist. It is distinct from a migration plan and does not claim every legacy cable can be reused. - Save the exact OSDP Verified record, profile, model, and certified firmware for every peripheral and controller. - Confirm reader count, multidrop, remote-management, smart-card, biometric, and other required features. - Calculate power at each location and record supply capacity, distance, conductor size, and measured voltage. - Validate new or reused data cable for the designed RS-485 topology and conditions. - Assign and document unique addresses, communication speed, controller port, physical location, and key owner. - Bench-test credential reads, keypad input, LED, buzzer, commands, and Secure Channel negotiation. - Test the installed bus under representative activity and confirm command response, communication stability, and supervision. - Protect Secure Channel keys and retain redacted commissioning evidence without exposing secret material. ## Official references - [Implementing OSDP Access Control? Follow This Simple Checklist](https://www.securityindustry.org/2026/02/10/implementing-osdp-access-control-follow-this-simple-checklist/) — SIA’s February 10, 2026 implementation guidance. - [SIA OSDP Verified](https://www.securityindustry.org/industry-standards/open-supervised-device-protocol/sia-osdp-verified/) — supported-versus-verified distinction. - [OSDP Verified Products](https://www.securityindustry.org/industry-standards/open-supervised-device-protocol/sia-osdp-verified/sia-osdp-verified-products/) — current products, profiles, and interoperability caveat. ## Primary reference - Name: Security Industry Association — Implementing OSDP Access Control? Follow This Simple Checklist - Authority: Security Industry Association - URL: https://www.securityindustry.org/2026/02/10/implementing-osdp-access-control-follow-this-simple-checklist/ - Source publication date: 2026-02-10 ## Citation and use Preferred citation: “OSDP commissioning evidence: Verified profiles, Secure Channel, cabling, and load,” DSE Security, https://update.dsesecurity.com/updates/osdp-commissioning-verified-secure-channel-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Package project access with approval, expiry, and delegated ownership > Entra entitlement management access packages bundle resource roles with request and lifecycle policies, creating a governable project-access product when catalog and package ownership are explicit. - Canonical URL: https://update.dsesecurity.com/updates/entra-access-packages-approval-expiry-ownership/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:21+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Entra entitlement management access packages bundle resource roles with request and lifecycle policies, creating a governable project-access product when catalog and package ownership are explicit. ## Potentially affected Organizations evaluating Microsoft Entra entitlement management for internal or external access to groups, applications, Teams, and SharePoint sites. ## DSE recommendation Design each access package around one business purpose, least-privilege resource roles, named approvers, finite assignment duration, review, and an accountable catalog owner. ## Article Bottom line: Microsoft Entra entitlement management can bundle access to groups, applications, Teams, and SharePoint sites into access packages governed by request, approval, assignment, expiration, and review policies. The quality of the result depends on the resource roles selected and the people trusted to own catalogs, packages, and approvals. ## Source fact: what Microsoft documents Microsoft’s [entitlement management overview](https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-overview) describes an access package as a bundle of resource roles placed in a catalog. A package can include roles from Entra groups, Microsoft 365 groups and Teams, enterprise applications, and SharePoint Online sites, with additional documented scenarios and preview capabilities. Policies define who can request or be assigned the package, who approves, and how long an assignment lasts. Microsoft documents time-limited assignments, recurring access reviews, automatic assignments based on identity properties, external connected organizations, and delegation to catalog owners and access package managers. Entitlement management can invite an approved external identity and can remove its B2B account after access expires when documented conditions are met. Licensing applies. ## What the source does not establish An access package does not prove that every included resource role is least privilege or that an approver understands its consequence. It does not govern access granted outside the package, application-native privileges unknown to Entra, or data copied while access was valid. Automatic guest removal has conditions and should not be assumed to occur if other assignments remain. Expiration is not a substitute for reviewing ownership and exceptions. ## Applicability questions - What single task, project, or role does the package enable? - Which exact resource roles are required, and are owner or administrative roles accidentally included? - Who is eligible, who approves, and can the approver validate business need and conflicts? - What assignment duration, extension, review, and sponsor rules fit internal and external users? - Who owns the catalog and package when the original project manager leaves? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Define the business outcome and build the smallest resource-role bundle that supports it. Separate privileged administration from ordinary collaboration packages. - Assign catalog and package owners by role or governed group, with an escalation owner outside the project. - Use explicit eligibility, approver, expiration, and review rules. Avoid indefinite assignments merely because a project end date is uncertain. - Pilot with test internal and external identities. Verify request, approval, provisioning, denial, expiry, extension, and removal. - Reconcile package assignments against direct resource assignments so the package does not create a false impression of complete governance. ## Verification and evidence - Preserve catalog, resource, role, package, policy, connected-organization, and delegation configuration. - Record request, approval, denial, assignment, review, expiration, and removal evidence for test cases. - Export current assignments and identify access to packaged resources granted by other paths. - Confirm owner and approver groups remain staffed and appropriately privileged. ## Official references - [What is entitlement management?](https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-overview) — Microsoft ## Primary reference - Name: What is entitlement management? - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Package project access with approval, expiry, and delegated ownership,” DSE Security, https://update.dsesecurity.com/updates/entra-access-packages-approval-expiry-ownership/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Parse and serialize HTTP Structured Fields as ordered typed values > Use RFC 9651 — Structured Field Values for HTTP to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/parse-and-serialize-http-structured-fields-as-ordered-typed-values/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:51+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 9651 — Structured Field Values for HTTP to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 9651 — Structured Field Values for HTTP ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Parse and serialize HTTP Structured Fields as ordered typed values. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 9651 — Structured Field Values for HTTP](https://www.rfc-editor.org/rfc/rfc9651.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A Structured Field serializer accepts a defined List, Dictionary, or Item and returns ASCII; it omits an empty List or Dictionary and fails when the supplied structure cannot be serialized. The research record locates this support at Section 4.1 (Serializing Structured Fields). - Dictionaries and Parameters are order-preserving maps, and their serialization algorithms process members in that stored order so applications can retain ordering when a field assigns it meaning. The research record locates this support at Sections 4.1.1.2 (Serializing Parameters), 4.1.2 (Serializing a Dictionary), and Appendix A. - A recipient parses a Structured Field according to its declared Dictionary, List, or Item type, and a parsing failure causes the entire field to be ignored. The research record locates this support at Sections 2.2 (Error Handling) and 4.2 (Parsing Structured Fields). Only the traced statements above are asserted as source facts. Apply the review to clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 4.1 (Serializing Structured Fields), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 4.1.1.2 (Serializing Parameters), 4.1.2 (Serializing a Dictionary), and Appendix A, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Sections 2.2 (Error Handling) and 4.2 (Parsing Structured Fields), which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify DNS, certificates, identity providers, time, content delivery, network paths, and application ownership. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations Section 4.1 (Serializing Structured Fields); Sections 4.1.1.2 (Serializing Parameters), 4.1.2 (Serializing a Dictionary), and Appendix A; Sections 2.2 (Error Handling) and 4.2 (Parsing Structured Fields) adjacent to the sanitized artifacts used for comparison. Prefer request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 9651 — Structured Field Values for HTTP](https://www.rfc-editor.org/rfc/rfc9651.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 9651 — Structured Field Values for HTTP - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9651.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Parse and serialize HTTP Structured Fields as ordered typed values,” DSE Security, https://update.dsesecurity.com/updates/parse-and-serialize-http-structured-fields-as-ordered-typed-values/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Parse enhanced mail status codes into class, subject, and detail > Use RFC 3463 — Enhanced Mail System Status Codes to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/parse-enhanced-mail-status-codes-into-class-subject-and-detail/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:56+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3463 — Enhanced Mail System Status Codes to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3463 — Enhanced Mail System Status Codes ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Parse enhanced mail status codes into class, subject, and detail. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3463 — Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An enhanced mail status code contains three dot-separated fields: delivery class, problem subject, and specific detail. The research record locates this support at Section 2 (Status Code Structure). - Class 2 means success, class 4 means a persistent transient failure that may succeed later, and class 5 means a permanent failure requiring a change. The research record locates this support at Section 2 (Status Code Structure), class sub-codes. - A client that does not recognize a detail code still reports the recognized subject, and if the subject is also unknown it reports the general class. The research record locates this support at Section 2 (Status Code Structure), extensibility behavior. The source support ends with the statements listed above. Use them to examine sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling in the applicable environment, not to imply a wider guarantee. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 2 (Status Code Structure), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2 (Status Code Structure), class sub-codes, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2 (Status Code Structure), extensibility behavior, which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from Section 2 (Status Code Structure); Section 2 (Status Code Structure), class sub-codes; Section 2 (Status Code Structure), extensibility behavior through sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Record what was collected, where, when, by whom, and which system or role it represents. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 3463 — Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 3463 — Enhanced Mail System Status Codes - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3463.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Parse enhanced mail status codes into class, subject, and detail,” DSE Security, https://update.dsesecurity.com/updates/parse-enhanced-mail-status-codes-into-class-subject-and-detail/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Parse extended ICMP objects only after the original datagram and length fields > Use RFC 4884 — Extended ICMP to Support Multi-Part Messages to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/parse-extended-icmp-objects-only-after-the-original-datagram-and-length-fields/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:19+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4884 — Extended ICMP to Support Multi-Part Messages to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4884 — Extended ICMP to Support Multi-Part Messages ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Parse extended ICMP objects only after the original datagram and length fields. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4884 — Extended ICMP to Support Multi-Part Messages](https://www.rfc-editor.org/rfc/rfc4884.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - The defined ICMPv4 and ICMPv6 error messages gain an original-datagram length field so an appended extension structure can be located after that field. The research record locates this support at Sections 3 (Summary of Changes to ICMP) and 4.1-4.5. - When extensions are present, the original-datagram field must contain at least 128 octets and be padded to a 32-bit boundary for ICMPv4 or a 64-bit boundary for ICMPv6. The research record locates this support at Section 3 (Summary of Changes to ICMP). - A receiver must validate message syntax and the extension checksum before processing extension objects; malformed lengths can otherwise cause buffer overruns. The research record locates this support at Section 9 (Security Considerations). Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Sections 3 (Summary of Changes to ICMP) and 4.1-4.5, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Summary of Changes to ICMP), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 9 (Security Considerations), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Sections 3 (Summary of Changes to ICMP) and 4.1-4.5; Section 3 (Summary of Changes to ICMP); Section 9 (Security Considerations) to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 4884 — Extended ICMP to Support Multi-Part Messages](https://www.rfc-editor.org/rfc/rfc4884.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4884 — Extended ICMP to Support Multi-Part Messages - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4884.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Parse extended ICMP objects only after the original datagram and length fields,” DSE Security, https://update.dsesecurity.com/updates/parse-extended-icmp-objects-only-after-the-original-datagram-and-length-fields/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Parse IPv6 extension headers without assuming a fixed upper-layer offset > Use RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/parse-ipv6-extension-headers-without-assuming-a-fixed-upper-layer-offset/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:20+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Parse IPv6 extension headers without assuming a fixed upper-layer offset. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification](https://www.rfc-editor.org/rfc/rfc8200.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - IPv6 optional internet-layer headers form a Next Header chain, and the first value that is not an extension header identifies the following upper-layer header. The research record locates this support at Section 4 (IPv6 Extension Headers), Next Header chain. - Except for Hop-by-Hop Options, extension headers are not processed, inserted, or deleted by transit nodes before the packet reaches its destination. The research record locates this support at Section 4 (IPv6 Extension Headers), transit processing rule. - A destination must process extension headers strictly in their on-wire order and cannot scan ahead to process a later header first. The research record locates this support at Section 4 (IPv6 Extension Headers), destination processing order. Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Section 4 (IPv6 Extension Headers), Next Header chain, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4 (IPv6 Extension Headers), transit processing rule, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4 (IPv6 Extension Headers), destination processing order, which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from Section 4 (IPv6 Extension Headers), Next Header chain; Section 4 (IPv6 Extension Headers), transit processing rule; Section 4 (IPv6 Extension Headers), destination processing order to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification](https://www.rfc-editor.org/rfc/rfc8200.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8200.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Parse IPv6 extension headers without assuming a fixed upper-layer offset,” DSE Security, https://update.dsesecurity.com/updates/parse-ipv6-extension-headers-without-assuming-a-fixed-upper-layer-offset/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Parse multipart boundaries before interpreting nested MIME media types > Use RFC 2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/parse-multipart-boundaries-before-interpreting-nested-mime-media-types/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:55+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Parse multipart boundaries before interpreting nested MIME media types. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types](https://www.rfc-editor.org/rfc/rfc2046.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A multipart body is divided by boundary lines into parts, each containing its own content headers, a blank line, and a body. The research record locates this support at Section 5.1 (Multipart Media Type). - The multipart Content-Type requires a boundary parameter, and the chosen delimiter must not occur as a delimiter line inside any encapsulated part. The research record locates this support at Section 5.1.1 (Common Syntax). - While parsing a nested multipart, a MIME implementation must recognize an outer boundary at every inner nesting level, including when an inner entity is truncated. The research record locates this support at Section 5.1.2 (Handling Nested Messages and Multiparts). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 5.1 (Multipart Media Type), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 5.1.1 (Common Syntax), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5.1.2 (Handling Nested Messages and Multiparts), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to Section 5.1 (Multipart Media Type); Section 5.1.1 (Common Syntax); Section 5.1.2 (Handling Nested Messages and Multiparts) and to observable material such as sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types](https://www.rfc-editor.org/rfc/rfc2046.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2046.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Parse multipart boundaries before interpreting nested MIME media types,” DSE Security, https://update.dsesecurity.com/updates/parse-multipart-boundaries-before-interpreting-nested-mime-media-types/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Permission-trim AI retrieval before it touches customer data > An AI answer is only as authorized as the retrieval path behind it. Preserve source permissions, evaluate the current user at query time, deny uncertain matches, and test revocation before an assistant searches customer records. - Canonical URL: https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:30:00+00:00 - Modified: 2026-08-17T19:22:08+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 4 minutes ## What you need to know An AI answer is only as authorized as the retrieval path behind it. Preserve source permissions, evaluate the current user at query time, deny uncertain matches, and test revocation before an assistant searches customer records. ## Potentially affected Retrieval-augmented AI assistants; search indexes; customer documents and records; source-system ACLs; Microsoft Entra users and groups; service identities; caches; vector stores; citations; and authorization logs. ## DSE recommendation Map every indexed source to its permission model, carry permission metadata through ingestion, enforce the current caller at every retrieval, deny incomplete authorization context, and test permission changes, cache behavior, and revocation end to end. ## Article ## Source facts: search relevance and authorization are different decisions Microsoft’s [document-level access-control guidance for Azure AI Search](https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview) describes several ways to exclude documents a caller is not permitted to receive. A generally available security-filter pattern stores user or group identifiers in a filterable field and adds the current caller’s identity to the query. Microsoft also documents native ACL or RBAC enforcement, Microsoft Purview sensitivity-label enforcement, and SharePoint permission ingestion for supported scenarios, with important portions identified as preview features. The security-filter pattern is application enforced. The source ACLs must be represented accurately in the index, the application must authenticate the caller, and every relevant query must apply the correct filter. A relevant vector or keyword match is not an authorization result. Likewise, granting an application permission to query an index does not mean every application user may receive every document in that index. Microsoft’s native permission patterns still have prerequisites and scope limits. The documented ACL and RBAC options depend on supported data sources, API versions, permission metadata, tokens, and index configuration. Preview behavior should not be presented as a universal capability or silently assumed to remain unchanged. NIST’s Generative AI Profile separately emphasizes governing data, privacy, access, monitoring, and testing across the AI lifecycle. Together, the sources support an engineering principle: the authorization boundary belongs in deterministic application and data controls, not in a prompt asking the model to respect permissions. ## DSE recommendation: make every retrieval prove the caller can see the result Design the assistant so it can search everything the current user is allowed to see, while having no path to material the user cannot see. That requires the same authorization context to survive ingestion, retrieval, caching, citation, and follow-up questions. - Declare the source of authority. For each ticket, contract, quote, file, mailbox, or customer record, identify the system that owns access, supported principal types, inheritance rules, sensitivity labels, external users, denial rules, and the event that changes access. - Carry permissions with the content. Index stable object and group identifiers rather than display names. Preserve the source object ID, tenant, ACL version or change marker, classification, and last permission synchronization time. Reject content whose ownership or authorization metadata cannot be resolved. - Evaluate the live caller. Authenticate the user for the conversation and obtain the user’s current groups or claims through an approved identity path. Apply the permission condition to every retrieval, including semantic search, vector search, related-record expansion, citations, exports, and tool calls. Do not rely on text in conversation memory to identify the user. - Use two identities deliberately. The indexing identity may need broad read access to ingest governed sources. The runtime identity should have only the search and application rights needed to return permission-trimmed results. Record which identity performed each step so a service account is not mistaken for the requesting person. - Control caches and conversation state. Bind cached results to tenant, user or authorization scope, source version, and expiry. Recheck access before replaying a prior citation or answering “what changed in that contract?” A document removed from search results must not remain available through an old conversation summary. - Test negative cases. Create users with no access, partial access, recently removed access, nested-group access, and similarly named customers. Test direct questions, vague follow-ups, bulk comparisons, exports, and attempts to convince the model that permission was granted. Inspect the retrieved document IDs, not only the final prose. Factual boundary: Azure AI Search documents specific implementation patterns; it does not make every AI retrieval system permission aware automatically. Some native permission features are preview capabilities. Recheck the selected service, API version, data source, and identity model before deployment. A correctly trimmed index also cannot repair excessive permissions in the source system. Measure denied retrievals, missing ACL metadata, permission-sync age, cache invalidation time, cross-tenant tests, and revoked-user test results. The desired outcome is not an assistant that promises discretion. It is a retrieval path that cannot supply unauthorized evidence to the model in the first place. ## Official references - Microsoft Learn, [Document-Level Access Control in Azure AI Search](https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview). - NIST, [Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence), NIST AI 600-1. - Microsoft Security, [New tools and guidance: Announcing Zero Trust for AI](https://www.microsoft.com/en-us/security/blog/2026/03/19/new-tools-and-guidance-announcing-zero-trust-for-ai/), March 19, 2026. ## Primary reference - Name: Microsoft Learn: Document-Level Access Control in Azure AI Search - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Permission-trim AI retrieval before it touches customer data,” DSE Security, https://update.dsesecurity.com/updates/permission-trim-ai-retrieval-customer-data/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Pilot Data Deduplication on the intended workload before enabling it broadly > What should a workload pilot establish before Data Deduplication is enabled? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-037-pilot-data-deduplication-on-the-intended-workload-before-enabling-it-broadly/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:34+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What should a workload pilot establish before Data Deduplication is enabled? ## Potentially affected Use this review when deciding whether to enable deduplication for a specific data set. ## DSE recommendation Choose a test data set that reflects how the application creates and changes files. ## Article ## Source facts Microsoft advises understanding workload characteristics before enabling Data Deduplication, because suitability and storage performance depend on the workload. For an uncertain workload, Microsoft recommends a pilot using a test data set and observing how it performs. When Data Deduplication is used in a failover cluster, the role must be installed on every node. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/data-deduplication/install-enable). ## Applicability Use this review when deciding whether to enable deduplication for a specific data set. Identify its application owner, storage location, representative contents, and cluster membership. Review the supported workload requirements in the current documentation. ## DSE recommendation Choose a test data set that reflects how the application creates and changes files. Define acceptable application response and storage observations before enabling the feature. Record where the pilot differs from production, including size or activity. For clustered storage, inspect role installation across all possible owners. Keep the pilot result tied to its workload instead of treating one successful evaluation as approval for unrelated applications. ## Verification Compare the agreed workload behavior and storage measurements before and after the pilot configuration. Exercise representative file operations and record optimization activity. Document any skipped data, performance concern, or node inconsistency. Have the application and storage owners review the evidence together before approving a broader rollout or changing the original acceptance criteria. ## Official references [Microsoft Learn: Installing and enabling Data Deduplication](https://learn.microsoft.com/en-us/windows-server/storage/data-deduplication/install-enable). Source reviewed September 8, 2026. ## Primary reference - Name: Installing and enabling Data Deduplication - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/data-deduplication/install-enable - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Pilot Data Deduplication on the intended workload before enabling it broadly,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-037-pilot-data-deduplication-on-the-intended-workload-before-enabling-it-broadly/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Pilot Experimental RADIUS/1.1 without silently breaking AAA > Treat RADIUS/1.1 over TLS or DTLS as an experimental interoperability project with explicit fallback and authorization tests. - Canonical URL: https://update.dsesecurity.com/updates/pilot-experimental-radius-11-without-breaking-aaa/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:36+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Treat RADIUS/1.1 over TLS or DTLS as an experimental interoperability project with explicit fallback and authorization tests. ## Potentially affected Organizations evaluating RADIUS/1.1 between network access servers, proxies, and AAA services ## DSE recommendation Limit RFC 9765 to a controlled pilot, verify ALPN and transport behavior, and prove that failure cannot create an unintended weaker path. ## Article RADIUS/1.1 is published as an Experimental RFC. Its security and transport changes are technically significant, but that status calls for a bounded pilot and explicit interoperability evidence—not an assumption that every NAS, proxy, and server can adopt it safely. ## Source fact: [IETF RFC 9765](https://datatracker.ietf.org/doc/rfc9765/) defines Application-Layer Protocol Negotiation identifiers and protocol extensions for using Experimental RADIUS/1.1 over TLS and DTLS. In that protected transport, RADIUS/1.1 removes the RADIUS shared secret and the protocol’s MD5-based packet authentication and attribute-obfuscation mechanisms. The secure transport provides the cryptographic channel and peer authentication expected by the new mode. The RFC does not change ordinary RADIUS over UDP or TCP. It explicitly has Experimental status, which means it is suitable for evaluation and experience rather than being presented as an Internet Standards Track requirement. Correct version negotiation through ALPN and correct handling at every proxy boundary are central to interoperability. ## Boundary Removing the RADIUS shared secret in RADIUS/1.1 does not remove the need for strong TLS identities, authorization, certificate lifecycle, or protection of the AAA service. Mixed transports can preserve legacy MD5-based behavior on other hops. A successful TLS handshake does not prove that attributes, message authentication, retransmission, duplicate detection, accounting, change-of-authorization, or policy decisions work as intended. Product support may be partial or labeled experimental itself. ## Applicability questions - Do the exact NAS, proxy, load balancer, and RADIUS releases implement RFC 9765 and the required ALPN behavior? - Where does TLS or DTLS terminate, and what protocol protects every subsequent hop? - Which certificate names, trust anchors, roles, renewal paths, and revocation behavior authenticate peers? - What happens when ALPN negotiation fails or a peer supports only a legacy transport? - Can fallback ever bypass the intended security or authorization policy? ## DSE recommendation: Keep the first implementation outside production access. Build a matrix that covers each client, server, proxy, transport, message class, and certificate state. Capture ALPN selection and verify the negotiated RADIUS version. Exercise accept, reject, challenge, accounting, retransmission, duplicate requests, proxying, disconnect or change-of-authorization where used, and failure during a live exchange. Define legacy coexistence and fallback as policy, not whatever the products happen to do. An unsupported or failed secure session should produce a visible, approved result and must not silently move to a less protected route. Use dedicated pilot identities and segmentation, protect private keys, and establish certificate-expiry alerts through an independent channel. Obtain vendor confirmation before any wider use. ## Verification and evidence Retain the experimental approval, full component/version matrix, configurations, certificates and trust design without private keys, decoded negotiation traces, AAA decision comparisons, failure tests, and fallback results. Evidence should correlate the same test identity’s request, server decision, network authorization, and accounting record. Record unresolved interoperation limits as blockers rather than treating basic authentication success as completion. ## Official references - [IETF RFC 9765](https://datatracker.ietf.org/doc/rfc9765/) ## Primary reference - Name: RFC 9765: RADIUS Version 1.1 - Authority: datatracker.ietf.org - URL: https://datatracker.ietf.org/doc/rfc9765/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Pilot Experimental RADIUS/1.1 without silently breaking AAA,” DSE Security, https://update.dsesecurity.com/updates/pilot-experimental-radius-11-without-breaking-aaa/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Pilot the Active Directory Protected Users group before placing privileged accounts inside it > Protected Users applies nonconfigurable credential protections that can also break NTLM, delegation, offline sign-in, and other dependencies. Prove each account's authentication paths before membership expands. - Canonical URL: https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:10+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Protected Users applies nonconfigurable credential protections that can also break NTLM, delegation, offline sign-in, and other dependencies. Prove each account's authentication paths before membership expands. ## Potentially affected Active Directory user accounts, privileged administrators, Kerberos and NTLM dependencies, delegated administration, remote management, cached sign-in, domain controllers, and support recovery procedures. ## DSE recommendation Inventory each candidate account's authentication dependencies, confirm AES readiness, pilot membership with recoverable test accounts, enable the documented event logs, and expand only after both normal work and emergency access are verified. ## Article Bottom line: Active Directory’s Protected Users group reduces the credential material and authentication methods available to member accounts. Those protections are mandatory while an account is a member. They can also expose old NTLM, delegation, encryption, offline sign-in, and remote-administration dependencies, so adding every privileged user at once can create an avoidable lockout. ## Source fact: what Microsoft documents Microsoft’s [Protected Users security group guidance](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group) describes a domain global group designed to protect against credential theft. On supported devices, membership prevents several forms of credential caching. Windows does not create a cached verifier for member sign-in or unlock, so offline sign-in is unavailable. Credential delegation, Windows Digest, NTLM, and Kerberos caching behavior are also restricted as documented by Microsoft. At the domain controller, Protected Users cannot authenticate with NTLM, use DES or RC4 for Kerberos preauthentication, or use constrained or unconstrained Kerberos delegation. Members require Kerberos with AES. Their ticket-granting ticket lifetime and renewal are constrained to four hours by the group’s nonconfigurable settings. Microsoft lists prerequisites that include supported Windows hosts and a Windows Server 2012 R2 or later domain functional level. It warns not to add service or computer accounts because the group does not provide the intended local protection for those accounts. It also warns against moving all highly privileged accounts into the group without testing because the restrictions have no workaround while membership remains. The page identifies ProtectedUser client and domain-controller event logs under Applications and Services Logs → Microsoft → Windows → Authentication. Those logs are disabled by default. Documented events include client credential-package failures, domain-controller failures involving DES or RC4, and successful Kerberos ticket issuance for a protected user. ## What the source does not establish Group membership does not prove that an account is least privileged, that its workstation is trusted, or that every credential-theft path is prevented. The Microsoft page does not inventory an organization’s legacy applications, remote tools, delegation chains, offline work requirements, disaster-recovery accounts, or help-desk procedures. A successful interactive sign-in alone does not demonstrate that the user’s complete administrative workflow remains functional. ## Applicability questions - Which human accounts are candidates, and are any service or computer identities mixed into the list? - Do candidate accounts have AES keys and reach domain controllers that meet the documented prerequisites? - Which applications, scripts, remote tools, file services, or devices still require NTLM or delegation? - Does any approved work require cached offline sign-in? - Which independently protected account can reverse membership if a test user is locked out? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Export current membership and assign an owner for every proposed addition and exception. - Trace representative sign-ins and administrative tasks to find NTLM, delegation, RC4, offline, and cached-credential dependencies. - Confirm domain, controller, workstation, and AES prerequisites before changing membership. - Enable the documented authentication logs on pilot systems and forward relevant events to protected monitoring. - Add one recoverable test account, then exercise local, remote, delegated, and emergency workflows. Remove the account if a required dependency fails and document the result. - Expand in small waves with a defined rollback operator who is not dependent on the account being changed. ## Verification and evidence - Preserve approved membership changes and their owners. - Capture successful Kerberos ticket events and investigated failure events. - Prove required administration paths work without NTLM, RC4, or disallowed delegation. - Test removal from the group and restoration of required access. - Record unresolved dependencies, exceptions, and their retirement dates. ## Official references - [Protected Users security group](https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group) — Microsoft ## Primary reference - Name: Protected Users security group - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/protected-users-security-group - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Pilot the Active Directory Protected Users group before placing privileged accounts inside it,” DSE Security, https://update.dsesecurity.com/updates/active-directory-protected-users-pilot/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Place a failover-cluster witness outside the failure domain it must arbitrate > A quorum witness is a deciding vote, not a decorative cluster setting. Select cloud, disk, or file share from the topology; isolate its dependencies from the failures it must resolve; validate access from every node; and retest after cluster or site changes. - Canonical URL: https://update.dsesecurity.com/updates/failover-cluster-witness-failure-domain-design/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-11T10:44:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know A quorum witness is a deciding vote, not a decorative cluster setting. Select cloud, disk, or file share from the topology; isolate its dependencies from the failures it must resolve; validate access from every node; and retest after cluster or site changes. ## Potentially affected Windows Server failover clusters and Azure Local; cluster nodes and votes; cloud, disk, and file share witnesses; Azure Storage, SMB, Active Directory, networks, storage, credentials, monitoring, and multisite recovery designs. ## DSE recommendation Map simultaneous failure scenarios and votes, inspect the current quorum configuration, choose a supported witness outside correlated failure paths, validate it from every node, monitor its dependencies, and rerun cluster validation after material change. ## Article ## Source facts: the witness supplies a vote, not another workload copy Microsoft defines a [failover-cluster quorum witness](https://learn.microsoft.com/en-us/windows-server/failover-clustering/what-is-quorum-witness) as a component that participates in quorum voting. A running cluster needs more than half of its active votes. If it cannot maintain that majority, it stops cluster operations to avoid separate partitions acting as the active cluster and risking inconsistent or corrupt data. Windows Server supports cloud, disk, and file share witnesses. A cloud witness uses Azure Blob Storage for its arbitration blob. A disk witness uses shared storage accessible to the nodes and contains cluster configuration information, not application data. A file share witness uses an SMB share and maintains cluster information in a log file. Microsoft recommends a witness for Windows Server 2012 R2 and later; current clustering versions dynamically manage witness and node votes. The witness type must fit the topology. Microsoft’s deployment guidance requires a file share dedicated to one cluster and physically separate from the cluster nodes or sites where practical, including consideration of network, power, rack, and room. It warns that DFS and replicated storage technologies are not supported for a file share witness because partitions in space or time can permit nodes to operate independently and risk data loss. Dynamic quorum can adjust node votes as nodes fail or shut down sequentially, but Microsoft states that it does not let a cluster survive the simultaneous failure of most voting members. Microsoft recommends reviewing quorum after cluster creation, using Validate Quorum Configuration or Test-Cluster, and avoiding production changes unless the topology and requirement have been evaluated. ## DSE recommendation: design for the partition, then operate every dependency Start with the failures the service must survive, not with an assumed preference for cloud, disk, or file share. Draw node, site, network, power, storage, directory, internet, and Azure dependencies on one page and calculate which votes remain together in each credible event. - Capture the current state. Record nodes, sites, node votes and dynamic weights, quorum mode, witness type and location, resource name, network path, account or key ownership, monitoring, last validation, application owners, and the cluster’s approved failure assumptions. - Model simultaneous loss. Test the vote outcome for a node failure, site isolation, WAN failure, shared-storage outage, directory or DNS issue, loss of internet or Azure access, maintenance shutdown, and the witness host or credential becoming unavailable. Sequential shutdown behavior is not proof against a simultaneous partition. - Select an independent witness. Place the deciding vote where it remains reachable by the side intended to continue. Do not host a file share witness on a cluster node it is meant to arbitrate or behind the same single power, switching, storage, or site dependency without recording that limitation. - Implement the documented requirements. For cloud witness, control the supported Azure Storage account, HTTPS path, access key, rotation, cost and ownership. For disk witness, dedicate supported shared storage. For file share witness, dedicate an SMB 2-or-later share with the documented permissions and no user or application data. - Validate and observe. Run supported cluster validation, confirm witness access from every node, review cluster events, and alert on a failed witness or long-lived loss of access. Record the quorum state before and after maintenance rather than inferring it from application availability. - Retest after change. Recalculate and validate after adding or evicting nodes, changing sites or storage, replacing a witness, rotating credentials, altering firewalls or proxies, or sustaining a long witness failure. Exercise controlled failure scenarios with workload owners and a stop condition. Document what remained online, where the deciding vote was reachable, how the cluster reacted, and how normal topology was restored. The right witness is not the option that produces an odd number on a diagram; it is a maintained, supported vote that makes the intended partition win under the organization’s actual failure domains. ## Official references - Microsoft Learn, [What is a quorum witness?](https://learn.microsoft.com/en-us/windows-server/failover-clustering/what-is-quorum-witness), March 28, 2025. - Microsoft Learn, [Deploy a quorum witness](https://learn.microsoft.com/en-us/windows-server/failover-clustering/deploy-quorum-witness). ## Primary reference - Name: Microsoft Learn: What is a quorum witness - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/what-is-quorum-witness - Source publication date: 2025-03-28 ## Citation and use Preferred citation: “Place a failover-cluster witness outside the failure domain it must arbitrate,” DSE Security, https://update.dsesecurity.com/updates/failover-cluster-witness-failure-domain-design/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Place access-control components away from hazards and public reach > NIST PE-18 calls for positioning system components to reduce physical and environmental hazards and unauthorized access. Apply that lens to PACS panels, power, and interfaces. - Canonical URL: https://update.dsesecurity.com/updates/place-access-control-components-away-from-hazards-and-public-reach/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:43+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 2 minutes ## What you need to know NIST PE-18 calls for positioning system components to reduce physical and environmental hazards and unauthorized access. Apply that lens to PACS panels, power, and interfaces. ## Potentially affected Access-control panels, power supplies, network switches, interfaces, door controllers, enrollment stations, and service ports installed in exposed or hazardous locations. ## DSE recommendation Survey component placement for public reach, water, heat, impact, service access, and utility hazards, then relocate or protect equipment using approved design and change control. ## Article Bottom line: a locked controller cabinet can still be poorly placed. Water piping, public ceilings, vehicle impact, heat, dust, shared tenant space, or an accessible disconnect can defeat availability or allow tampering before a door alarm is ever generated. ## Source fact: NIST addresses component location as a protection decision PE-18 in [NIST SP 800-53 Release 5.2.0](https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home?element=PE-18) calls for positioning system components within a facility to minimize potential damage from physical and environmental hazards and to minimize opportunities for unauthorized access. The control is broad enough to include computing and supporting components, not merely user workstations. Applied to PACS, placement affects both security and continuity. A controller above a publicly accessible ceiling, below a leak source, or beside an unprotected power cutoff can convert a local condition into multiple uncontrolled doors. ## Source boundary and applicability NIST SP 800-53 is a control catalog. Whether PE-18 is mandatory, selected, tailored, or used as guidance depends on the organization’s authorization framework, contract, regulation, and system boundary. It does not provide a universal mounting location, enclosure rating, flood elevation, fire requirement, or code approval. Qualified design disciplines and local requirements remain necessary. ## Applicability questions - Which doors and functions fail if this panel, power supply, switch, or interface is damaged? - Can the public, tenants, vendors, or unescorted staff reach the equipment or its cables? - Are water, condensation, temperature, dust, vibration, impact, or electromagnetic hazards present? - Is service access safe, observable, and possible without defeating another control? - Do enclosure, battery, ventilation, fire, and accessibility requirements constrain relocation? ## DSE recommendation: add placement risk to panel acceptance The following steps are DSE recommendations based on the cited source. Create an inventory with component location, controlled doors, power and network dependencies, enclosure, access population, environmental conditions, nearby utilities, and failure consequence. Inspect above and below the equipment, trace accessible cable and disconnect paths, and consider credible maintenance and building events. Rank deficiencies by the number and importance of affected openings. Use relocation, rated enclosure, barriers, leak protection, protected power, tamper monitoring, or procedural control only after responsible facilities, security, electrical, fire, and accessibility owners approve the design. Do not place batteries or energized equipment in a sealed or unlisted arrangement. ## Verification and evidence Retain the component inventory, sanitized plans, photographs, environmental and access observations, manufacturer installation requirements, approved risk treatment, change ticket, tamper and power-loss tests, and inspection cadence. Reassess after renovations, tenant changes, utility work, leaks, impacts, or repeated faults. ## Official references - [NIST SP 800-53 Release 5.2.0, PE-18 — Location of System Components](https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home?element=PE-18) – National Institute of Standards and Technology; released August 27, 2025 ## Primary reference - Name: NIST SP 800-53 Release 5.2.0, PE-18 — Location of System Components - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/projects/cprt/catalog#/cprt/framework/version/SP_800_53_5_2_0/home?element=PE-18 - Source publication date: 2025-08-27 ## Citation and use Preferred citation: “Place access-control components away from hazards and public reach,” DSE Security, https://update.dsesecurity.com/updates/place-access-control-components-away-from-hazards-and-public-reach/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Place authoritative DNS secondaries across independent failure domains > Use RFC 2182 — Selection and Operation of Secondary DNS Servers to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/place-authoritative-dns-secondaries-across-independent-failure-domains/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:36+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2182 — Selection and Operation of Secondary DNS Servers to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2182 — Selection and Operation of Secondary DNS Servers ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Place authoritative DNS secondaries across independent failure domains. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2182 — Selection and Operation of Secondary DNS Servers](https://www.rfc-editor.org/rfc/rfc2182.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Authoritative secondary servers must be geographically dispersed and connected through diverse network paths so one failure cannot isolate all servers. The research record locates this support at Section 3.1 (Selecting Secondary Servers). - Placing every authoritative server on one LAN, in one room, or in one building defeats most of the resilience gained from multiple servers. The research record locates this support at Section 3.2 (Unsuitable Configurations). - Most organization-level zones should have three servers, with at least one well removed from the others; higher-reliability zones may use four or five. The research record locates this support at Section 5 (How many secondaries?). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers only where the source and recorded environment align. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Section 3.1 (Selecting Secondary Servers), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3.2 (Unsuitable Configurations), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5 (How many secondaries?), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Section 3.1 (Selecting Secondary Servers); Section 3.2 (Unsuitable Configurations); Section 5 (How many secondaries?). Favor zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 2182 — Selection and Operation of Secondary DNS Servers](https://www.rfc-editor.org/rfc/rfc2182.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2182 — Selection and Operation of Secondary DNS Servers - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2182.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Place authoritative DNS secondaries across independent failure domains,” DSE Security, https://update.dsesecurity.com/updates/place-authoritative-dns-secondaries-across-independent-failure-domains/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Place video privacy controls at capture, viewing, and export > Privacy controls act at different points in the video lifecycle. Map masking, access restriction, and redaction to the disclosure risk each control is intended to reduce. - Canonical URL: https://update.dsesecurity.com/updates/place-video-privacy-controls-at-capture-view-and-export/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:36:13+00:00 - Modified: 2026-08-25T21:36:16+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Privacy controls act at different points in the video lifecycle. Map masking, access restriction, and redaction to the disclosure risk each control is intended to reduce. ## Potentially affected Organizations recording people or private areas, especially where live viewing, investigations, evidence sharing, or public disclosure create different privacy risks. ## DSE recommendation Document the intended privacy boundary at capture, recording, viewing, and export, then test that each authorized and unauthorized workflow produces the expected result. ## Article Bottom line: a privacy mask at the camera, an operator permission in the VMS, and redaction applied to an exported clip solve different problems. A design should identify when information must be hidden, who may reveal it, and whether an unmasked original may exist. ## Source fact: privacy controls can act at several stages The Axis white paper [Privacy in surveillance](https://whitepapers.axis.com/en-us/privacy-in-surveillance) describes privacy options that include blocking selected image areas, masking people, using non-visual technologies, and applying controls across capture, recording, viewing, and export. It distinguishes static masking, dynamic masking, access controls, and redaction rather than presenting privacy as one camera setting. That lifecycle view matters. A permanent source mask can prevent sensitive pixels from entering a stream. A dynamic mask may permit an authorized role to reveal information. VMS permissions can restrict who sees a camera or recording. Export redaction creates a disclosure copy while leaving the evidentiary original subject to separate controls. ## Source boundary and applicability The paper describes Axis approaches and does not establish legal compliance, authorize recording, or prove that a particular third-party VMS preserves a mask. Privacy requirements depend on jurisdiction, purpose, notice, labor agreements, retention, public-record obligations, and the people or spaces captured. Product and version support must be verified. ## Applicability questions - Which areas or people must never be recorded, and which may be revealed only for an approved investigation? - Does masking occur before encoding, in a parallel stream, in the client, or only during export? - Who can disable a mask or retrieve an unmasked stream, and is that action logged? - Do mobile clients, video walls, integrations, thumbnails, analytics, and exported stills follow the same rule? - Must an evidentiary original be preserved while a redacted disclosure copy is created? ## DSE recommendation: build a privacy-control matrix The following steps are DSE recommendations based on the cited source. Create a matrix with lifecycle stages as rows and each viewing or export workflow as columns. For every cell, name the allowed roles, expected masked state, location of any unmasked original, audit event, and approval required to reveal information. Prefer source masking when pixels have no legitimate operational purpose. Where an original is necessary, restrict the reveal path with least privilege, a documented reason, and reviewable logs. Include every stream and derivative, not just the primary desktop client. Test live and recorded video, low- and high-resolution streams, snapshots, bookmarks, evidence packages, third-party integrations, and administrative previews. Treat any unlogged bypass or unexpectedly unmasked derivative as a design defect. ## Verification and evidence Retain the approved privacy matrix, screenshots of configured regions, role and permission exports, test clips from each workflow, redacted and original file hashes where applicable, reveal-event audit logs, and sign-off from privacy or legal owners. Re-test after camera replacement, firmware or VMS upgrades, layout changes, or integration changes. ## Official references - [Privacy in surveillance](https://whitepapers.axis.com/en-us/privacy-in-surveillance) – Axis Communications ## Primary reference - Name: Privacy in surveillance - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/privacy-in-surveillance - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Place video privacy controls at capture, viewing, and export,” DSE Security, https://update.dsesecurity.com/updates/place-video-privacy-controls-at-capture-view-and-export/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan 6 GHz Wi-Fi from client capability, security, power class, and location > A 6 GHz design is more than a faster radio. Client support, security mode, device class, indoor or outdoor location, power limits, channel availability, and automated frequency coordination can change what may be deployed. - Canonical URL: https://update.dsesecurity.com/updates/plan-6-ghz-wifi-client-security-power-location/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:53:00+00:00 - Modified: 2026-08-17T19:22:10+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know A 6 GHz design is more than a faster radio. Client support, security mode, device class, indoor or outdoor location, power limits, channel availability, and automated frequency coordination can change what may be deployed. ## Potentially affected United States 6 GHz Wi-Fi planning; access points and fixed clients; AFC systems; wireless controllers; endpoint drivers; authentication; surveys; channel plans; outdoor links; procurement; and compliance records. ## DSE recommendation Inventory client and security capability, classify every radio and location, verify current FCC and manufacturer requirements, model coverage and capacity, pilot representative workflows, document AFC dependencies, and control future changes. ## Article ## Source facts: 6 GHz rules distinguish device classes and operating conditions The FCC’s [fact sheet on unlicensed use of the 6 GHz band](https://docs.fcc.gov/public/attachments/DOC-417577A1.pdf) summarizes the Commission’s treatment of unlicensed devices across portions of the band. The framework distinguishes classes such as low-power indoor, very-low-power, standard-power access points, and fixed client devices, with different operational constraints. The FCC’s [public notice on automated frequency coordination system operation](https://docs.fcc.gov/public/attachments/DA-24-166A1.pdf) addresses approved AFC systems. Standard-power access points and fixed client devices use AFC within applicable portions of the band to obtain frequency availability and power information intended to protect incumbent services. These documents are United States regulatory materials. They do not establish what is permitted in another country, prove that a particular product is certified for a chosen use, or guarantee that every client supports the required channel, security mode, driver, roaming behavior, or power class. Regulatory and certification details should be checked at design and again before activation. ## DSE recommendation: design from the permitted deployment inward Start with location and device class rather than selecting an access point and deciding later where to install it. Then combine regulatory validation with a representative client and security assessment. - Define jurisdiction and location. Record country, indoor or outdoor placement, building and room, antenna arrangement, mobility, mounting, nearby incumbent considerations, and whether the link crosses property or public space. Send unusual installations through qualified regulatory and engineering review. - Classify every radio. Identify the exact access point, client or fixed-client role, power class, FCC identification or other authorization evidence, firmware, antenna limitations, and controller mode. Confirm that planned configuration does not convert a product into an unapproved operating condition. - Inventory client readiness. Collect device models, chipsets, operating systems, drivers, regulatory domains, supported bands and channels, authentication capability, and known business applications. Separate devices that can use 6 GHz from those that must remain on 5 or 2.4 GHz. - Validate security and onboarding. Test the organization’s approved authentication and encryption design with representative managed, guest, voice, scanning, operational-technology, and specialty clients. Verify certificate enrollment, captive portal behavior, roaming, device recovery, and helpdesk visibility. - Engineer coverage and capacity. Perform predictive design and an on-site survey appropriate to the facility. Account for propagation, attenuation, channel width, co-channel use, client power, uplink constraints, density, application demand, and fallback coverage. A wider channel is not automatically the best capacity decision. - Plan AFC dependency where applicable. Document the selected approved AFC service, registration data, geolocation and height accuracy, connectivity needs, response handling, channel and power grants, renewal, alerts, loss behavior, support ownership, and a compliant recovery plan. - Pilot and govern change. Measure association, authentication, roaming, throughput, latency, retransmission, voice or video quality, battery behavior, coverage boundaries, and failure recovery. Revalidate after firmware, driver, controller, antenna, location, power, channel, or regulatory changes. Define a fallback experience before migration. A client that cannot join 6 GHz should land on an intentionally designed supported band or remediation path, not a hidden exception network with weaker security. Document band-steering assumptions, minimum data rates, legacy-device ownership, replacement timing, and how service staff distinguish coverage from compatibility or authentication failure. Factual boundary: This article addresses United States FCC materials only. Device classes, AFC obligations, authorized frequencies, power limits, certification, and client requirements differ by jurisdiction and can change. Official rules, equipment authorization, manufacturer instructions, and qualified design review govern the actual deployment. Track clients unable to use the intended security design, uncertified or unclassified radios, AFC failures, installations differing from survey records, unsupported drivers, and post-change validation. A successful 6 GHz rollout is a compliant, supportable service—not merely the appearance of a new network name. ## Official references - Federal Communications Commission, [Fact Sheet: Unlicensed Use of the 6 GHz Band](https://docs.fcc.gov/public/attachments/DOC-417577A1.pdf). - Federal Communications Commission, [Public Notice concerning approved Automated Frequency Coordination systems](https://docs.fcc.gov/public/attachments/DA-24-166A1.pdf). ## Primary reference - Name: FCC Fact Sheet: Unlicensed Use of the 6 GHz Band - Authority: docs.fcc.gov - URL: https://docs.fcc.gov/public/attachments/DOC-417577A1.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan 6 GHz Wi-Fi from client capability, security, power class, and location,” DSE Security, https://update.dsesecurity.com/updates/plan-6-ghz-wifi-client-security-power-location/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan ambulatory-surgery continuity around same-day patient risk > Use 42 CFR 416.54 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/plan-ambulatory-surgery-continuity-around-same-day-patient-risk/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:09+00:00 - Modified: 2026-08-27T13:06:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 416.54 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 416.54 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Plan ambulatory-surgery continuity around same-day patient risk. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 416.54 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-416.54) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 416, the rule requires that if elected, the unified and integrated emergency preparedness program include integrated policies and procedures that meet the requirements set forth in paragraph (b) of this section, a coordinated communication plan and training and testing programs that meet the requirements of paragraphs (c) and (d) of this section, respectively. The research record locates this support at 42 CFR 416.54(e)(5), read with 42 CFR 416.54(e) (eCFR anchor p-416.54(e)(5)). - Under 42 CFR 416, the rule requires that the ASC develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 416.54(d) (eCFR anchor p-416.54(d)). Only the traced statements above are asserted as source facts. Apply the review to essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives after confirming that the source and deployed context match. ## What the source does not establish ASC-specific federal condition for coverage; patient acuity, evacuation, anesthesia, utilities, state licensing, accreditation, and survey guidance require facility-specific planning. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 416.54(e)(5), read with 42 CFR 416.54(e) (eCFR anchor p-416.54(e)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 416.54(d) (eCFR anchor p-416.54(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from 42 CFR 416.54(e)(5), read with 42 CFR 416.54(e) (eCFR anchor p-416.54(e)(5)); 42 CFR 416.54(d) (eCFR anchor p-416.54(d)) through business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [42 CFR 416.54 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-416.54) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 416.54 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-416.54 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan ambulatory-surgery continuity around same-day patient risk,” DSE Security, https://update.dsesecurity.com/updates/plan-ambulatory-surgery-continuity-around-same-day-patient-risk/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan an OSDP Secure Channel migration as a controlled access-system change > Moving reader communications to OSDP Secure Channel requires exact component and firmware inventory, supported key handling, staged deployment, operational testing, and a documented recovery path. - Canonical URL: https://update.dsesecurity.com/updates/osdp-secure-channel-migration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:04:47+00:00 - Modified: 2026-07-19T19:29:33+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Moving reader communications to OSDP Secure Channel requires exact component and firmware inventory, supported key handling, staged deployment, operational testing, and a documented recovery path. ## Potentially affected Organizations planning to replace or migrate legacy reader-to-controller communications in an electronic access-control system. ## DSE recommendation Inventory controllers, readers, firmware, wiring, topology, and required functions; verify current vendor support; then pilot Secure Channel with an authorized integrator. ## Article ## Why migration needs system-level planning The Security Industry Association describes OSDP as an access-control communications standard supporting bidirectional communications, supervision, and Secure Channel encryption between an access control unit and peripheral devices. Those capabilities can strengthen a supported design, but migration affects controllers, readers, firmware, wiring, configuration, keys, monitoring, and operating procedures together. This guide does not claim that any product pair is compatible or that a migration is appropriate for every opening. Confirm exact requirements with current SIA material, the controller and reader manufacturers, and the authorized integrator responsible for the system. ## Inventory before selecting a path Record each access control unit, interface module, reader or peripheral device, firmware version, connection type, address, wiring topology, power arrangement, and site. Document current credential technologies and required functions such as reader feedback, tamper or communication supervision, door events, input and output behavior, and management visibility. Identify shared buses, distance and electrical constraints, legacy converters, and openings that cannot tolerate experimental work. Do not assume existing wiring or a general “OSDP supported” statement establishes suitability. Review manufacturer requirements and the SIA OSDP Verified product information where relevant, while recognizing that a listing alone does not prove the complete installed design. ## Define Secure Channel governance Secure Channel depends on correct implementation and key management. Establish who is authorized to initialize devices, how keys are generated or provisioned using supported methods, where recovery information is protected, how commissioning access is controlled, and what happens during device replacement or controller recovery. Avoid shared default material when the supported design provides a unique-key workflow. Record the procedure without exposing keys in tickets, drawings, or general project notes. If the products cannot support the required governance, resolve that gap before scheduling production work. ## Pilot a representative opening - Back up supported controller and system configuration and define rollback criteria. - Verify the approved firmware and configuration for both controller and peripheral device. - Commission through the manufacturer-supported sequence with authorized personnel. - Confirm Secure Channel status through supported management evidence. - Test credentials, reader feedback, door events, alarms, request-to-exit behavior, tamper indications, schedules, and operator visibility as applicable. - Observe communications stability and logs before expanding the deployment group. Use a controlled maintenance window and coordinate with facility, security, IT, and monitoring stakeholders. Stop and recover if observed door behavior, event reporting, or operator control differs from the approved test plan. ## Expand in traceable groups Group migrations by controller, site, device type, or another boundary that supports recovery. Keep a per-opening result with component and firmware versions, Secure Channel status, test evidence, exception, and owner. Monitor failed communications, devices returning to an unintended mode, repeated initialization, and missing events. After completion, update diagrams, inventories, support procedures, spare strategy, and future procurement requirements. Preserve a controlled replacement and recovery process so the secure configuration can be maintained after staff and hardware changes. Work affecting locks, egress, emergency procedures, or regulated openings must also follow applicable manufacturer instructions, approved design, and qualified life-safety review; this article does not replace those requirements. ## Primary reference - Name: Security Industry Association — Open Supervised Device Protocol (OSDP) - Authority: Security Industry Association - URL: https://www.securityindustry.org/industry-standards/open-supervised-device-protocol/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan an OSDP Secure Channel migration as a controlled access-system change,” DSE Security, https://update.dsesecurity.com/updates/osdp-secure-channel-migration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan BitLocker maintenance for Cluster Shared Volumes > Review how a clustered volume is managed, which tools expose it, and what must be tested before enabling BitLocker. - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-001-plan-bitlocker-maintenance-for-cluster-shared-volumes/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:17:10+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Checklist - DSE priority: Information - Topics: Business Continuity, Cybersecurity, IT - Reading time: 1 minutes ## What you need to know Review how a clustered volume is managed, which tools expose it, and what must be tested before enabling BitLocker. ## Potentially affected Administrators evaluating BitLocker for Cluster Shared Volumes in Windows Server failover clusters. ## DSE recommendation Record the volume and protector configuration, arrange maintenance, and test unlocking from the intended cluster nodes. ## Article ## Source facts Microsoft permits enabling BitLocker on a clustered volume either before or after the volume joins the cluster. Its instructions call for putting the resource in maintenance mode first. Microsoft prefers PowerShell or Manage-BDE for CSV administration because volumes without drive letters are absent from the BitLocker Control Panel interface. [Microsoft’s CSV guidance](https://learn.microsoft.com/en-us/windows-server/failover-clustering/bitlocker-on-csv-in-ws-2022) also requires installing the BitLocker feature on every cluster node. ## Applicability Identify the operating-system release, volume type, cluster membership, and current protector before adapting the procedure. Review the source’s protector discussion for that configuration. Do not infer that one node’s successful unlock establishes the recovery behavior of the entire cluster. ## DSE recommendation Prepare a volume-by-volume maintenance record. Include the node owners, protected workload, authorized recovery personnel, approved recovery-key location, and the intended management tool. Have the workload owner approve the interruption and document the command scope before execution. Keep recovery material out of ordinary tickets and article comments. ## Verification In an approved test, record encryption and protector state, the maintenance transition, and unlock behavior from each intended node. Include a planned workload move and a recovery exercise appropriate to the configuration. Record failures separately from successful tests, and leave unresolved recovery questions open before expanding deployment. ## Official references [Microsoft Learn: Use BitLocker with Cluster Shared Volumes](https://learn.microsoft.com/en-us/windows-server/failover-clustering/bitlocker-on-csv-in-ws-2022). Source reviewed September 8, 2026. ## Primary reference - Name: Use BitLocker with Cluster Shared Volumes - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/bitlocker-on-csv-in-ws-2022 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan BitLocker maintenance for Cluster Shared Volumes,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-001-plan-bitlocker-maintenance-for-cluster-shared-volumes/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan cluster volume count around metadata ownership and capacity > How should Storage Spaces Direct volume count account for ownership distribution? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-144-plan-cluster-volume-count-around-metadata-ownership-and-capacity/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:47+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How should Storage Spaces Direct volume count account for ownership distribution? ## Potentially affected Administrators planning volumes in Storage Spaces Direct clusters. ## DSE recommendation Create a volume worksheet showing workload placement, planned capacity, and intended ownership distribution. ## Article ## Source facts Microsoft relates the number of cluster volumes to pool capacity and the maximum supported volume size, with at least one volume per node. That layout allows volume ownership to be distributed among servers; one server coordinates metadata for each volume. The planning guidance treats filesystem, resiliency, and size as separate choices driven by workload performance and capacity needs. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/plan-volumes). ## Applicability Inventory the pool, node count, workload groups, expected growth, and supported volume limits. Review the specific resiliency and capacity calculation for the proposed design before assigning a target size to each volume. ## DSE recommendation Create a volume worksheet showing workload placement, planned capacity, and intended ownership distribution. Ask the application and storage owners to approve the boundaries between workloads. Include the expected expansion scenario so the initial layout does not depend on an undocumented spare-capacity assumption. ## Verification Compare the created volume inventory and ownership with the worksheet. Test representative access and an approved ownership move while observing the workload. Record actual capacity and distribution separately from forecasts, and revisit the plan when node count or workload growth changes materially. ## Official references [Microsoft Learn: Plan volumes on Azure Local and Windows Server clusters](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/plan-volumes). Source reviewed September 8, 2026. ## Primary reference - Name: Plan volumes on Azure Local and Windows Server clusters - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/plan-volumes - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan cluster volume count around metadata ownership and capacity,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-144-plan-cluster-volume-count-around-metadata-ownership-and-capacity/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan CORF continuity around time-sensitive outpatient rehabilitation > Use 42 CFR 485.68 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/plan-corf-continuity-around-time-sensitive-outpatient-rehabilitation/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:01+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 485.68 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 485.68 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Plan CORF continuity around time-sensitive outpatient rehabilitation. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 485.68 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-485.68) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 485, the rule requires that if elected, the unified and integrated emergency preparedness program do all of the following: include integrated policies and procedures that meet the requirements set forth in paragraph (b) of this section, a coordinated communication plan and training and testing programs that meet the requirements of paragraphs (c) and (d) of this section, respectively. The research record locates this support at 42 CFR 485.68(e)(5), read with 42 CFR 485.68(e) (eCFR anchor p-485.68(e)(5)). - Under 42 CFR 485, the rule requires that the CORF develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 485.68(d) (eCFR anchor p-485.68(d)). Keep the evidence boundary at these traced claims. They support a review of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish CORF-specific federal condition; patient mobility, treatment interruption, equipment, referrals, state licensing, and survey guidance require service-specific planning. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 485.68(e)(5), read with 42 CFR 485.68(e) (eCFR anchor p-485.68(e)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 485.68(d) (eCFR anchor p-485.68(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to 42 CFR 485.68(e)(5), read with 42 CFR 485.68(e) (eCFR anchor p-485.68(e)(5)); 42 CFR 485.68(d) (eCFR anchor p-485.68(d)) and to observable material such as business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [42 CFR 485.68 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-485.68) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 485.68 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-485.68 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan CORF continuity around time-sensitive outpatient rehabilitation,” DSE Security, https://update.dsesecurity.com/updates/plan-corf-continuity-around-time-sensitive-outpatient-rehabilitation/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan Defender for Identity around fixed workspace geolocation and 180-day retention > Use Privacy with Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/plan-defender-identity-fixed-geolocation-180-day-retention/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:07+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Privacy with Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Privacy with Microsoft Defender for Identity ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Plan Defender for Identity around fixed workspace geolocation and 180-day retention. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Privacy with Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/privacy-compliance) from Microsoft supports the following bounded statements: - A Defender for Identity workspace is automatically created in the data center geographically closest to the Microsoft Entra ID tenant and cannot later be moved; its geolocation appears under Settings > Identity > About. The research record locates this support at Data location > customer data storage bullets. - Defender for Identity retains data visible across the portal for 180 days. The research record locates this support at Data retention. - After the license grace or suspended period ends, Microsoft says the data is erased and made unrecoverable no later than 180 days after contract termination or expiration. The research record locates this support at Data retention. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows only where the source and recorded environment align. ## What the source does not establish The service’s location and retention statements do not establish an organization’s legal retention duty, independent backup, export completeness, or recovery capability. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Data location > customer data storage bullets, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Data retention, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Data retention, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows are in and out of scope? - Which condition in Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Data location > customer data storage bullets; Data retention; Data retention to the observed environment. Useful domain evidence includes alert records, investigation timelines, analyst actions, tuning or exclusion approvals, remediation results, and case closure; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Privacy with Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/privacy-compliance) — Microsoft ## Primary reference - Name: Privacy with Microsoft Defender for Identity - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/privacy-compliance - Source publication date: 2025-09-28 ## Citation and use Preferred citation: “Plan Defender for Identity around fixed workspace geolocation and 180-day retention,” DSE Security, https://update.dsesecurity.com/updates/plan-defender-identity-fixed-geolocation-180-day-retention/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan Defender for Identity operations around the unified portal and 30-day hunting retention > Use Microsoft Defender for Identity in the Microsoft Defender portal to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/plan-defender-identity-unified-portal-30-day-hunting-retention/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:33+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Microsoft Defender for Identity in the Microsoft Defender portal to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft Defender for Identity in the Microsoft Defender portal ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Plan Defender for Identity operations around the unified portal and 30-day hunting retention. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft Defender for Identity in the Microsoft Defender portal](https://learn.microsoft.com/en-us/defender-for-identity/microsoft-365-security-center-mdi) from Microsoft supports the following bounded statements: - Microsoft moved classic Defender for Identity portal users to the unified Defender portal; the documentation says redirection is automatic and the legacy portal cannot be restored. The research record locates this support at Converged experiences in the Microsoft Defender portal > Note. - The Microsoft Defender portal stores advanced-hunting data for 30 days; Microsoft directs customers needing longer retention to stream activities to Microsoft Sentinel or another partner SIEM. The research record locates this support at Configuration and posture > API > Tip. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows and the conditions the source actually describes. ## What the source does not establish Portal convergence and hunting retention do not establish SIEM ingestion, schema continuity, report retention, licensing, or successful migration of legacy workflows. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Converged experiences in the Microsoft Defender portal > Note, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Configuration and posture > API > Tip, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from Converged experiences in the Microsoft Defender portal > Note; Configuration and posture > API > Tip to the observed environment. Useful domain evidence includes alert records, investigation timelines, analyst actions, tuning or exclusion approvals, remediation results, and case closure; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Microsoft Defender for Identity in the Microsoft Defender portal](https://learn.microsoft.com/en-us/defender-for-identity/microsoft-365-security-center-mdi) — Microsoft ## Primary reference - Name: Microsoft Defender for Identity in the Microsoft Defender portal - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/microsoft-365-security-center-mdi - Source publication date: 2024-02-14 ## Citation and use Preferred citation: “Plan Defender for Identity operations around the unified portal and 30-day hunting retention,” DSE Security, https://update.dsesecurity.com/updates/plan-defender-identity-unified-portal-30-day-hunting-retention/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan Defender for Identity sensor coverage by server role > Use Microsoft Defender for Identity deployment overview to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/plan-defender-for-identity-sensor-coverage-by-server-role/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:41+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Microsoft Defender for Identity deployment overview to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Microsoft Defender for Identity deployment overview ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Plan Defender for Identity sensor coverage by server role. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Microsoft Defender for Identity deployment overview](https://learn.microsoft.com/en-us/defender-for-identity/deploy/deploy-defender-identity) from Microsoft supports the following bounded statements: - Defender for Identity sensors collect signals from on-premises identity infrastructure for threat detection. The research record locates this support at Opening overview. - The service detects activity such as privilege escalation and high-risk lateral movement and reports exploitable identity issues such as unconstrained Kerberos delegation. The research record locates this support at Opening overview. Keep the evidence boundary at these traced claims. They support a review of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Use the server-role matrix and prerequisites for implementation; the overview does not prove that every eligible server is onboarded or healthy. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Microsoft Defender for Identity deployment overview](https://learn.microsoft.com/en-us/defender-for-identity/deploy/deploy-defender-identity) — Microsoft ## Primary reference - Name: Microsoft Defender for Identity deployment overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/deploy/deploy-defender-identity - Source publication date: 2026-08-07 ## Citation and use Preferred citation: “Plan Defender for Identity sensor coverage by server role,” DSE Security, https://update.dsesecurity.com/updates/plan-defender-for-identity-sensor-coverage-by-server-role/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan DFS client return after a target comes back online > How should DFS failback be configured and tested after target maintenance? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-067-plan-dfs-client-return-after-a-target-comes-back-online/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:04+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know How should DFS failback be configured and tested after target maintenance? ## Potentially affected Use this review when maintaining a DFS target that clients should use again afterward. ## DSE recommendation Record the starting referral and failback settings before removing a target from service. ## Article ## Source facts Disabling a DFS namespace-server or folder-target referral stops directing users to that target, which Microsoft identifies as useful for maintenance. Client failback can return clients to a restored target, subject to the documented client requirements. Folders with targets inherit failback settings from the namespace root, with configuration available at folder level. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/enable-or-disable-referrals-and-client-failback). ## Applicability Use this review when maintaining a DFS target that clients should use again afterward. Identify the namespace root, folder settings, client versions, and intended preferred target. Review referral ordering as a separate input to the maintenance plan. ## DSE recommendation Record the starting referral and failback settings before removing a target from service. Have the file-service owner define when the restored target should be accepted for use. Include both the outage period and the return-to-service period in the client test plan. Preserve the original settings and assign responsibility for checking that temporary maintenance choices are cleared. ## Verification Observe representative client target selection while the approved target is unavailable and after it is restored. Record which clients meet the source’s failback requirements and whether they return as intended. Check inherited and explicit settings if behavior differs between folders. Resolve unexpected persistence on an alternate target before closing the maintenance record. ## Official references [Microsoft Learn: Enable or Disable Referrals and Client Failback](https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/enable-or-disable-referrals-and-client-failback). Source reviewed September 8, 2026. ## Primary reference - Name: Enable or Disable Referrals and Client Failback - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/dfs-namespaces/enable-or-disable-referrals-and-client-failback - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan DFS client return after a target comes back online,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-067-plan-dfs-client-return-after-a-target-comes-back-online/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan electric-power facility work around the rule's emergency and access controls > Use 29 CFR 1910.269 - Electric power generation, transmission, and distribution to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/plan-electric-power-facility-work-around-the-rule-s-emergency-and-access-controls/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:15+00:00 - Modified: 2026-08-27T13:06:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.269 - Electric power generation, transmission, and distribution to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.269 - Electric power generation, transmission, and distribution ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Plan electric-power facility work around the rule’s emergency and access controls. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.269 – Electric power generation, transmission, and distribution](https://www.ecfr.gov/current/title-29/section-1910.269) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, while work is being performed in a manhole or vault containing energized electric equipment, an employee with first-aid training must be available on the surface in the immediate vicinity of the manhole or vault entrance to render emergency assistance. The research record locates this support at 29 CFR 1910.269(t)(3)(i) (eCFR anchor p-1910.269(t)(3)(i)). - Under 29 CFR 1910, the rule requires that the briefing cover at least the following subjects: hazards associated with the job, work procedures involved, special precautions, energy-source controls, and personal protective equipment requirements. The research record locates this support at 29 CFR 1910.269(c)(2) (eCFR anchor p-1910.269(c)(2)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths only where the source and recorded environment align. ## What the source does not establish Federal workplace rule for covered operations; voltage, task, employee qualification, construction rules, and other electrical standards determine applicability. A correct source interpretation can still be inapplicable to a particular design. Confirm identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 29 CFR 1910.269(t)(3)(i) (eCFR anchor p-1910.269(t)(3)(i)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.269(c)(2) (eCFR anchor p-1910.269(c)(2)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Keep the source locations 29 CFR 1910.269(t)(3)(i) (eCFR anchor p-1910.269(t)(3)(i)); 29 CFR 1910.269(c)(2) (eCFR anchor p-1910.269(c)(2)) adjacent to the sanitized artifacts used for comparison. Prefer facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, with enough identity and timing data for an independent recheck. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [29 CFR 1910.269 – Electric power generation, transmission, and distribution](https://www.ecfr.gov/current/title-29/section-1910.269) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.269 - Electric power generation, transmission, and distribution - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.269 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan electric-power facility work around the rule's emergency and access controls,” DSE Security, https://update.dsesecurity.com/updates/plan-electric-power-facility-work-around-the-rule-s-emergency-and-access-controls/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan emergency facility access for HIPAA contingency operations > The HIPAA Security Rule addresses procedures for facility access supporting disaster recovery and emergency-mode operations. Translate that requirement into tested, accountable access paths. - Canonical URL: https://update.dsesecurity.com/updates/plan-emergency-facility-access-for-hipaa-contingency-operations/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:47+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 2 minutes ## What you need to know The HIPAA Security Rule addresses procedures for facility access supporting disaster recovery and emergency-mode operations. Translate that requirement into tested, accountable access paths. ## Potentially affected HIPAA covered entities and business associates whose emergency operations require access to facilities housing systems or data containing electronic protected health information. ## DSE recommendation Define who may enter which facility during each contingency, how identity and authorization are verified, what degraded mode is allowed, and how all emergency access is logged and reconciled. ## Article Bottom line: emergency access should not depend on the same network, credential service, staffing model, or building condition that the contingency may disrupt. It needs a preauthorized, testable path that preserves accountability and safety. ## Source fact: HIPAA addresses emergency facility access [45 CFR 164.310(a)(2)(i) — Contingency operations](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.310#p-164.310%28a%29%282%29%28i%29) is part of the facility-access-controls standard for covered entities and business associates. Its contingency-operations implementation specification calls for procedures that allow facility access in support of restoring lost data under a disaster-recovery plan and emergency-mode operations after an emergency. The same section also addresses validating access and controlling facility access based on role or function. A continuity binder that says authorized personnel may enter does not explain how a locked, offline, damaged, or remotely managed building will recognize them. ## Source boundary and applicability The regulation is authoritative text, but this article is not legal advice or a conclusion that a scenario satisfies HIPAA. The emergency procedure must align with the entity’s risk analysis, contingency plan, facility-access plan, safety obligations, leases, local emergency authority, and protection of electronic protected health information. Emergency egress and responder authority remain separate requirements. ## Applicability questions - Which facilities must be entered to restore data or operate in emergency mode? - Which roles may enter, for what task, and under whose activation authority? - What if PACS servers, identity services, communications, power, or normal guards are unavailable? - Where are mechanical keys, offline credentials, contact lists, and safe-entry information held? - How will entry, escort, work performed, equipment movement, and departure be recorded? ## DSE recommendation: build scenario-specific emergency access cards The following steps are DSE recommendations based on the cited source. For each continuity scenario, name the activation authority, facility, authorized roles, identity check, access method, alternate method, escort rule, hazards, communications, evidence log, and deactivation step. Separate loss of PACS from loss of power, inaccessible building management, evacuation, disaster-damaged premises, and after-hours restoration because the safe path differs. Use controlled exercises that do not create unsafe entry or weaken live security. Demonstrate retrieval of required keys or offline credentials, access by the approved role, entry logging, secure work, and return to normal state. Immediately reconcile all temporary badges, keys, overrides, and access events after the exercise or incident. ## Verification and evidence Retain the regulatory applicability decision, contingency and facility-access procedures, role roster, key or credential custody record, exercise script, timing and entry log, communication test, exception record, after-action report, and restoration reconciliation. Protect the plan because detailed bypass information can itself create risk. ## Official references - [45 CFR 164.310(a)(2)(i) — Contingency operations](https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.310#p-164.310%28a%29%282%29%28i%29) – Electronic Code of Federal Regulations ## Primary reference - Name: 45 CFR 164.310(a)(2)(i) — Contingency operations - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.310#p-164.310%28a%29%282%29%28i%29 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan emergency facility access for HIPAA contingency operations,” DSE Security, https://update.dsesecurity.com/updates/plan-emergency-facility-access-for-hipaa-contingency-operations/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan exclusions within a DHCP scope before activating its address range > How should a DHCP scope represent a subnet with addresses that must not be leased? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-091-plan-exclusions-within-a-dhcp-scope-before-activating-its-address-range/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:40+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How should a DHCP scope represent a subnet with addresses that must not be leased? ## Potentially affected Administrators planning Windows Server DHCP scopes and exclusions. ## DSE recommendation Prepare an address worksheet showing the overall scope and every intended exclusion. ## Article ## Source facts A DHCP scope groups addresses that a server can lease to clients on a subnet. Microsoft describes a single scope as an address range together with its configuration options. The Windows Server guidance permits one scope for a subnet, defined as one continuous address range. Administrators needing several usable ranges inside that subnet define the scope first and then add exclusion ranges. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-scopes). ## Applicability Identify the subnet, proposed pool, existing address allocations, and reservations or exclusions already recorded. Review the addressing plan before enabling the scope, and ask the network owner to resolve conflicting inventory entries. ## DSE recommendation Prepare an address worksheet showing the overall scope and every intended exclusion. Name the owner of each address block and the reason it is excluded. Have a second reviewer compare the worksheet with the planned configuration and confirm the intended gateway and DNS options separately. ## Verification Use an approved client test to inspect the assigned address and options. Compare the server’s configured range and exclusions with the worksheet, then reconcile observed leases with the intended eligible addresses. Preserve any unexpected allocation as a finding for investigation before extending the scope to additional clients. ## Official references [Microsoft Learn: DHCP scopes in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-scopes). Source reviewed September 8, 2026. ## Primary reference - Name: DHCP scopes in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-scopes - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan exclusions within a DHCP scope before activating its address range,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-091-plan-exclusions-within-a-dhcp-scope-before-activating-its-address-range/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan for private Wi-Fi addresses before NAC and inventory lose the device > Modern devices can present private MAC addresses per Wi-Fi network and may rotate them. Inventory and network access designs that treat a hardware address as durable identity need stronger signals, documented exceptions, and tested support workflows. - Canonical URL: https://update.dsesecurity.com/updates/plan-private-wifi-addresses-before-nac-inventory-lose-device/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:55:00+00:00 - Modified: 2026-08-17T19:22:10+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Modern devices can present private MAC addresses per Wi-Fi network and may rotate them. Inventory and network access designs that treat a hardware address as durable identity need stronger signals, documented exceptions, and tested support workflows. ## Potentially affected Enterprise and guest Wi-Fi; Apple and Windows clients; NAC and RADIUS; DHCP and DNS records; wireless controllers; device inventories; captive portals; certificates; MDM policies; and helpdesk troubleshooting. ## DSE recommendation Identify MAC-dependent workflows, test current client behavior, prefer certificate and account-based authorization, correlate multiple inventory signals, document managed-device policy, and update support and incident procedures. ## Article ## Source facts: a client address may be private and network-specific Apple’s [private Wi-Fi address documentation](https://support.apple.com/en-us/102509) explains that Apple devices use a different private media access control address for each Wi-Fi network to reduce tracking. Current Apple software exposes Off, Fixed, or Rotating behavior depending on the network and platform context. The address may change under documented conditions, and an organization can use device-management settings for enrolled devices. Windows provides administrative and diagnostic commands for wireless profiles and interfaces through [netsh wlan](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wlan). The command reference can help support teams inspect profiles, interfaces, filters, reports, and related wireless state. It does not make client behavior identical across Windows versions, drivers, adapters, or management configurations. These official sources show why a design that equates one observed MAC address with one permanent device will eventually produce gaps. They do not say private addressing should always be disabled. A MAC address remains useful for association, troubleshooting, and telemetry, but it is not a strong authenticator and should not be the only link among a user, managed endpoint, authorization decision, and asset record. ## DSE recommendation: preserve privacy behavior while strengthening identity Find every workflow that assumes a stable address before changing client settings. The right response is usually to improve authentication and correlation, not to force one global exception without understanding its operational and privacy effects. - Inventory MAC dependencies. Review allowlists, reservations, NAC rules, device counts, license systems, captive portals, location analytics, incident searches, DHCP history, and helpdesk scripts. Record whether each use needs authorization, correlation, convenience, or merely a display label. - Observe representative clients. Test supported Apple and Windows versions, wireless adapters, managed and unmanaged states, saved networks, network resets, roaming, operating-system upgrades, and profile reinstallation. Record the actual behavior for each network rather than assuming a vendor-wide constant. - Use stronger access signals. Prefer enterprise authentication with validated user or device certificates, appropriately protected credentials, managed-device posture, and policy decisions tied to a known identity. Keep guest and unmanaged-device paths separate from trusted corporate access. - Build multi-signal inventory correlation. Relate MDM device identifiers, certificate subjects or thumbprints, RADIUS accounting, controller client records, DHCP leases, hostnames, serial numbers where authorized, user sign-ins, and timestamps. Preserve source and confidence so a guessed match is not presented as certain. - Define managed-device exceptions carefully. If a stable address is operationally necessary, limit the setting to documented networks and enrolled devices, validate the platform’s current management capability, explain the privacy consequence, and assign an owner and review date. Avoid extending a local requirement to personal or unrelated networks. - Update support and incident workflows. Teach staff to search by user, certificate, device-management ID, time range, network, and observed address. A reported address should narrow the investigation, not close identity attribution by itself. Preserve time synchronization and controller, RADIUS, DHCP, and identity logs according to policy. - Test loss and change. Verify onboarding, renewal, revocation, address rotation, certificate replacement, device wipe, ownership change, and offboarding. Confirm that access is removed through the authoritative identity path even when a previously observed MAC address reappears. Keep guest and bring-your-own-device experience in scope. A privacy-preserving address change can consume duplicate registrations, licenses, or portal approvals even when corporate access uses stronger identity. Define expiration, self-service recovery, abuse controls, and support evidence without turning guest analytics into an assertion of permanent device ownership. Factual boundary: Private-address behavior varies by operating system, version, adapter, profile, network security, and device-management policy. The cited commands are diagnostic and administrative interfaces, not evidence that every Windows client exposes the same privacy settings. Recheck current platform documentation before deployment. Measure MAC-only authorization rules, unmatched managed clients, certificate failures, stale correlations, duplicate asset records, and exceptions without review dates. The goal is reliable access and support without pretending a changeable link-layer value is durable identity. ## Official references - Apple Support, [Use private Wi-Fi addresses on Apple devices](https://support.apple.com/en-us/102509). - Microsoft Learn, [netsh wlan](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/netsh-wlan). ## Primary reference - Name: Apple Support: Use private Wi-Fi addresses on Apple devices - Authority: support.apple.com - URL: https://support.apple.com/en-us/102509 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan for private Wi-Fi addresses before NAC and inventory lose the device,” DSE Security, https://update.dsesecurity.com/updates/plan-private-wifi-addresses-before-nac-inventory-lose-device/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan H.265 adoption around every recorder, client, export path, and investigator > H.265 support on a camera does not prove that recording, live viewing, mobile playback, analytics, failover, or evidence export will work. Qualify the complete video path and keep a tested rollback before migration. - Canonical URL: https://update.dsesecurity.com/updates/plan-h265-adoption-across-the-complete-video-path/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:14:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know H.265 support on a camera does not prove that recording, live viewing, mobile playback, analytics, failover, or evidence export will work. Qualify the complete video path and keep a tested rollback before migration. ## Potentially affected IP cameras and encoders, VMS and NVR recording servers, storage sizing, operator workstations, graphics hardware, mobile and web clients, integrations, analytics, failover recording, evidence players, and retention plans. ## DSE recommendation Build a model-and-version compatibility matrix, test representative streams under peak load through every required workflow, measure storage and client performance, validate exports on an independent device, stage deployment, and retain a known-good H.264 rollback. ## Article ## Source facts: a video format and a complete workflow are different things [ONVIF Profile T](https://www.onvif.org/profiles/profile-t/) is designed for advanced IP video streaming and includes H.264 and H.265 encoding, imaging settings, metadata streaming, and other capabilities. ONVIF describes some profile features as mandatory and others as conditional for a conformant device or client. Profile conformance helps establish standardized interfaces; it does not state that every product implements every optional function, accepts every stream setting, or performs adequately at a particular scale. The International Telecommunication Union publishes the [H.265 video-coding recommendation](https://www.itu.int/rec/T-REC-H.265/en). The standard defines video coding, not the readiness of a VMS database, browser, GPU, mobile client, analytic, evidence player, or third-party integration. Resolution, frame rate, scene motion, noise, group-of-pictures settings, bitrate controls, vendor implementation, and available decoding hardware can materially change bandwidth, storage, and playback behavior. Neither source establishes a universal storage-savings percentage or guarantees interoperability. Licensing, supported profiles, client hardware, export containers, and failover behavior depend on the products, versions, and contracts in use. Organizations should confirm current vendor documentation and license terms before enabling H.265. ## DSE recommendation: qualify H.265 as a controlled system change Begin with a dependency matrix. For each camera model and firmware, identify the recorder/VMS version, recording server, storage target, operator client, web and mobile client, video wall, analytic, access-control integration, failover method, export format, and external recipient that must handle the stream. Mark support as documented, tested, unsupported, or unknown. “The camera can emit H.265” is not enough. - Choose representative scenes. Include a quiet interior, moving people, foliage or rain, vehicle traffic, low light with noise, and high-contrast entrances. These scenes exercise compression differently. Preserve equivalent H.264 samples and settings for comparison. - Test recording continuity. Confirm scheduled, motion, event, pre-event, and post-event recording; timeline playback; thumbnails; bookmarks; search; retention; and time synchronization. Restart services through an authorized method and test any supported edge or server failover path. - Load the clients. Build realistic multi-camera layouts on the oldest supported operator hardware, remote connection, mobile device, browser, and video wall. Measure processor and graphics use, dropped frames, seek delay, and usability while decoding multiple streams—not just one full-screen camera. - Exercise integrations. Trigger alarms, metadata, analytics, maps, access events, and API consumers that use the video. Some integrations request a secondary stream or decode frames independently, so VMS playback alone cannot qualify them. - Prove evidence delivery. Export short and long clips with the organization’s ordinary player and authentication options. Open them on an approved computer that does not have the operator client installed. Verify audio when applicable, timestamps, watermarks or signatures, sequence continuity, and an authorized fallback export. - Measure instead of assuming. Compare bitrate and storage over a representative interval, including peak motion and darkness. Recalculate retention from observed data with operating margin. Do not spend an estimated saving before the system has produced it. Deploy by a small camera group with a change window, owner, monitoring criteria, and rollback threshold. Retain the previous H.264 profile and confirm that reverting does not break retention or client behavior. Watch recorder errors, reconnections, archive queues, storage growth, client support calls, and analytic failures before expanding. An H.265 migration is successful only if the required recording, response, investigation, export, and recovery workflows remain reliable. A mixed-codec environment can be a valid long-term outcome where an older integration or evidence recipient has a legitimate constraint. The goal is verified operational value, not codec uniformity. Set an expansion gate before the pilot begins. Stop and restore the known-good profile when recordings develop unexplained gaps, an approved client cannot decode, exports fail independent playback, analytic results materially change, or measured compute and storage exceed design margin. Document the failed condition and require a corrected retest; do not waive a core workflow merely to complete the migration schedule. ## Official references - ONVIF, [Profile T for advanced video streaming](https://www.onvif.org/profiles/profile-t/). - International Telecommunication Union, [Recommendation ITU-T H.265: High efficiency video coding](https://www.itu.int/rec/T-REC-H.265/en). ## Primary reference - Name: ONVIF Profile T for advanced video streaming - Authority: ONVIF - URL: https://www.onvif.org/profiles/profile-t/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan H.265 adoption around every recorder, client, export path, and investigator,” DSE Security, https://update.dsesecurity.com/updates/plan-h265-adoption-across-the-complete-video-path/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan NPS domain access and authentication-method compatibility together > Which domain permissions and access-device capabilities must be checked when NPS acts as the RADIUS server? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-197-plan-nps-domain-access-and-authentication-method-compatibility-together/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:54+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which domain permissions and access-device capabilities must be checked when NPS acts as the RADIUS server? ## Potentially affected Administrators planning NPS as the authentication and authorization server. ## DSE recommendation Build a matrix of user domain, NPS instance, access-device type, and selected method. ## Article ## Source facts Microsoft’s server-planning guidance requires choosing the domain membership of NPS. To read user dial-in properties during authorization, it directs administrators to add the NPS computer account to the RAS and NPSs group in each relevant domain. NPS supports password and certificate authentication methods, but network access servers do not all support the same methods. The method may therefore differ by access type. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-plan-server). ## Applicability Identify the user domains, NPS computer account, trust arrangement, access devices, and proposed authentication methods. Review the source’s precise domain requirements before granting directory access. ## DSE recommendation Build a matrix of user domain, NPS instance, access-device type, and selected method. Have directory and network-access owners review permissions and compatibility independently. Document which requests NPS will process locally and which belong to a separately designed proxy path. ## Verification Test an authorized representative account from each relevant domain through each intended device type. Inspect the authentication and authorization results and verify the selected method. Preserve a directory-read failure separately from an access-device compatibility failure, and resolve both before expanding the service. ## Official references [Microsoft Learn: Plan NPS as a RADIUS server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-plan-server). Source reviewed September 8, 2026. ## Primary reference - Name: Plan NPS as a RADIUS server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-plan-server - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan NPS domain access and authentication-method compatibility together,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-197-plan-nps-domain-access-and-authentication-method-compatibility-together/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan NPS server certificates even when Wi-Fi users authenticate with passwords > Why does the password-based 802.1X wireless design still require NPS certificates? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-063-plan-nps-server-certificates-even-when-wi-fi-users-authenticate-with-passwords/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:08+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Why does the password-based 802.1X wireless design still require NPS certificates? ## Potentially affected Use this review for the documented password-based wireless design and supported client population. ## DSE recommendation Keep the user credential decision separate from the authentication-server certificate plan. ## Article ## Source facts The documented PEAP-MS-CHAP v2 design uses password credentials for user authentication. That same deployment guide still requires server certificates on the authenticating NPS servers. Microsoft identifies an internal AD CS deployment or a public certification authority as options for issuing those server certificates. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/a-deploy-8021X-wireless-access). ## Applicability Use this review for the documented password-based wireless design and supported client population. Identify every authenticating NPS server, its certificate source, and the client trust configuration. Review current authentication guidance before selecting this method. ## DSE recommendation Keep the user credential decision separate from the authentication-server certificate plan. Have the wireless, identity, and certificate owners review the expected server identities and trust anchors together. Record who will renew each NPS certificate and how a replacement will be tested. Include a deliberately untrusted server identity in the approved client-validation test plan. ## Verification Test a representative client against the intended NPS service and inspect the server certificate involved. Verify the approved behavior when server identity or trust does not match the client configuration. Preserve the connection result and certificate identity without capturing user passwords. Resolve a validation or renewal gap before expanding wireless enrollment. ## Official references [Microsoft Learn: Deploy Password-Based 802.1X Authenticated Wireless Access](https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/a-deploy-8021X-wireless-access). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy Password-Based 802.1X Authenticated Wireless Access - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/a-deploy-8021X-wireless-access - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan NPS server certificates even when Wi-Fi users authenticate with passwords,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-063-plan-nps-server-certificates-even-when-wi-fi-users-authenticate-with-passwords/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan private network access for Windows Admin Center inside an Azure VM > What network path is needed to use Windows Admin Center for an Azure VM? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-152-plan-private-network-access-for-windows-admin-center-inside-an-azure-vm/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:39+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What network path is needed to use Windows Admin Center for an Azure VM? ## Potentially affected Administrators enabling Windows Admin Center management of Windows Azure VMs. ## DSE recommendation Have the Azure and network owners document the management path from the administrator’s device to the VM. ## Article ## Source facts Windows Admin Center in the Azure portal manages operating-system functions inside an Azure VM. Microsoft installs Windows Admin Center in each VM that will be managed through this feature. The source recommends connecting through the VM’s private address. That approach does not require an inbound port rule but does require access to the VM’s virtual network. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/manage-vm). ## Applicability Identify the Azure subscription, target VM, browser, authorized user, and route to the virtual network. Review the feature’s platform and permission requirements before enabling the extension. ## DSE recommendation Have the Azure and network owners document the management path from the administrator’s device to the VM. Prefer the approved private-access arrangement and record how that access will be maintained. Keep this guest-management path separate from registering an on-premises Windows Admin Center gateway with Azure. ## Verification Connect through the intended private path and perform an approved read-only operating-system inspection. Confirm the target VM identity and the user’s permitted management scope. Record connectivity or permission failures and verify that the management operation remains confined to the intended VM before enabling the workflow for more operators. ## Official references [Microsoft Learn: Manage a Windows VMs using Windows Admin Center in Azure](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/manage-vm). Source reviewed September 8, 2026. ## Primary reference - Name: Manage a Windows VMs using Windows Admin Center in Azure - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/manage-vm - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan private network access for Windows Admin Center inside an Azure VM,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-152-plan-private-network-access-for-windows-admin-center-inside-an-azure-vm/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan processor compatibility before moving a VM across CPU generations > Which VM processor setting must be reviewed before migration between different hosts? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-237-plan-processor-compatibility-before-moving-a-vm-across-cpu-generations/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:14+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know Which VM processor setting must be reviewed before migration between different hosts? ## Potentially affected Administrators configuring Hyper-V VM processor compatibility. ## DSE recommendation Document the hosts the VM must be able to use and the application features that may depend on exposed CPU capabilities. ## Article ## Source facts Microsoft describes processor compatibility mode as limiting the processor features exposed to a VM so it can move between hosts with differing capabilities. The VM must be powered off before enabling or disabling the setting. Dynamic processor compatibility cannot be configured in Hyper-V Manager; the documented alternatives are PowerShell or Windows Admin Center. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/configure-processor-compatibility-mode). ## Applicability Inventory the intended source, destination, and recovery hosts and their supported capabilities. Check whether the cluster and operating-system versions support the dynamic option described in the source. Keep the compatibility decision separate from allocating more virtual processors to a workload. ## DSE recommendation Document the hosts the VM must be able to use and the application features that may depend on exposed CPU capabilities. Ask the workload owner to approve the planned powered-off change window. Select the management tool that supports the intended mode and preserve the initial setting. Define a representative migration and application test before altering a production VM. ## Verification Confirm the effective compatibility mode after the approved change, then start the VM and validate the application. Exercise the intended host-to-host move and record both placement and workload results. Compare the result with every host in the accepted placement set. Resolve an unsupported destination or changed application behavior before extending the setting to other VMs. ## Official references [Microsoft Learn: Configure processor compatibility in Hyper-V virtual machines](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/configure-processor-compatibility-mode). Source reviewed September 8, 2026. ## Primary reference - Name: Configure processor compatibility in Hyper-V virtual machines - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/configure-processor-compatibility-mode - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan processor compatibility before moving a VM across CPU generations,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-237-plan-processor-compatibility-before-moving-a-vm-across-cpu-generations/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan remote-session locking behavior for Entra-authenticated RDP > What happens when a remote session using Microsoft Entra authentication is locked? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-085-plan-remote-session-locking-behavior-for-entra-authenticated-rdp/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:46+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What happens when a remote session using Microsoft Entra authentication is locked? ## Potentially affected Administrators assessing Microsoft Entra authentication in Remote Desktop Connection. ## DSE recommendation Include the disconnect-on-lock behavior in the pilot instructions and support notes. ## Article ## Source facts Remote Desktop Connection supports single sign-on through Microsoft Entra authentication. The client option to use a web account for remote sign-in corresponds to the enablerdsaadauth RDP property. Microsoft states that the remote Windows lock screen does not accept Entra tokens or passwordless methods such as FIDO keys. Attempting to lock such a session disconnects it instead, with a message explaining the disconnection. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-connection-single-sign-on). ## Applicability Check both computers against the documented operating-system and update prerequisites. Review the intended account, device join state, remote access permissions, and any policy that locks inactive sessions before assessing this sign-in route. ## DSE recommendation Include the disconnect-on-lock behavior in the pilot instructions and support notes. Ask the application owner to define an acceptable reconnect experience, including any unsaved work concerns. Review the actual session-lock policy with the endpoint team and identify who will investigate failed reconnections. ## Verification Test initial sign-in, a deliberate lock attempt, a policy-triggered lock, and the subsequent reconnect using a representative account. Record the actual client setting, user-visible messages, and application state after reconnecting. Keep each authentication method tested separate so success with one method is not recorded as proof for all methods. ## Official references [Microsoft Learn: Connect to a Remote PC with Single Sign-On Using Microsoft Entra Authentication](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-connection-single-sign-on). Source reviewed September 8, 2026. ## Primary reference - Name: Connect to a Remote PC with Single Sign-On Using Microsoft Entra Authentication - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/remote-desktop-connection-single-sign-on - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan remote-session locking behavior for Entra-authenticated RDP,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-085-plan-remote-session-locking-behavior-for-entra-authenticated-rdp/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan removable-media controls around business use, malware risk, and sanitization > Removable media can carry essential recovery data, sensitive records, and malicious content across trust boundaries. Define approved uses, managed media, encryption, scanning, transfer stations, custody, retention, and sanitization by risk. - Canonical URL: https://update.dsesecurity.com/updates/plan-removable-media-controls-business-use-malware-sanitization/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:50:00+00:00 - Modified: 2026-08-17T19:22:10+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Removable media can carry essential recovery data, sensitive records, and malicious content across trust boundaries. Define approved uses, managed media, encryption, scanning, transfer stations, custody, retention, and sanitization by risk. ## Potentially affected USB storage and removable media; endpoints and servers; backup and recovery workflows; operational systems; service technicians; sensitive data transfers; malware controls; encryption; custody records; reuse; and disposal. ## DSE recommendation Map legitimate media workflows, prohibit unapproved use, issue managed encrypted media, constrain read and write paths, inspect content, maintain custody, protect recovery copies, and sanitize or destroy media using verified methods. ## Article ## Source facts: media control continues through its final disposition NIST [SP 800-88 Rev. 2, Guidelines for Media Sanitization](https://csrc.nist.gov/pubs/sp/800/88/r2/final), frames sanitization as a program based on information sensitivity, media type, intended disposition, organizational risk, available techniques, verification, and documentation. Clear, purge, and destroy are categories whose suitability depends on the media and the organization’s requirements. CISA’s [guidance on protecting data stored on devices](https://www.cisa.gov/resources-tools/training/how-protect-data-stored-your-devices) emphasizes understanding what data is present, controlling access, using encryption, maintaining backups, and securely disposing of devices and media. Those practices address confidentiality and recovery but do not replace malware prevention, safe transfer, or system-specific operating restrictions. The sources do not require one universal choice among prohibition, authorization, encryption, scanning, write restriction, managed media, or physical destruction. A recovery team, service technician, isolated operational system, and ordinary office user can have different legitimate needs and consequences. ## DSE recommendation: govern each transfer from issuance through sanitization Begin with the business workflow. Eliminate casual use, then provide a controlled path for the transfers and recovery functions that remain necessary. - Map approved use cases. Identify recovery media, configuration transfer, evidence collection, field service, software installation, offline update, regulated export, and customer delivery. For each, record data class, source and destination trust zones, owner, frequency, retention, and what happens if the media is lost or contaminated. - Set a controlled default. Block or restrict unapproved removable storage through supported endpoint and application controls. Distinguish storage from keyboards, authentication devices, serial adapters, cameras, and other USB classes. Provide a documented exception route so necessary work does not move to invisible personal media. - Issue managed media. Use organization-owned, uniquely identified media with appropriate capacity, hardware or software encryption, recovery-key custody, tamper handling, and assignment records. Limit who may receive it and where it may connect. Do not rely on a printed label as the only inventory control. - Control the transfer station. Where risk justifies it, use a hardened intermediary with current protection, restricted networking, disabled autorun behavior, content inspection, logging, and a reset or rebuild process. Define separate paths for inbound and outbound material and a quarantine decision for suspicious files. - Minimize and verify content. Transfer only required files, preserve hashes or signatures when applicable, scan before and after movement, and validate the destination result. Treat encrypted archives and unsupported formats as unresolved until they can be inspected through an approved method. - Maintain custody and recovery. Record issue, transfer, return, storage, loss, and incident events. Protect recovery media from the same event as the production system, test that it can be read on approved equipment, and ensure encryption keys remain available during an outage. - Sanitize according to media and disposition. Select a clear, purge, or destroy method supported for the exact media and risk. Verify the outcome, record the method and operator, and use qualified destruction or recycling services where required. Account for failed and damaged media that cannot accept ordinary commands. Include removable media in incident response. Define when a device is isolated, who may handle it, how a forensic image or hash is obtained when appropriate, how exposed systems are identified, and when credentials or data transfers require investigation. Do not reconnect suspected media merely to determine whether it still works. Factual boundary: Sanitization effectiveness depends on media technology, device implementation, condition, encryption, and intended disposition. Antivirus scanning cannot guarantee a file is safe, and encryption does not prevent an authorized endpoint from reading malicious content. Legal, contractual, records, safety, and vendor requirements can change the appropriate control. Measure personal or unknown media detections, approved transfers, inspection failures, lost media, recovery-read tests, overdue returns, sanitization verification, and exceptions past expiry. The target is a usable controlled path with traceable custody—not a policy statement that ignores the work people must perform. ## Official references - NIST, [SP 800-88 Rev. 2: Guidelines for Media Sanitization](https://csrc.nist.gov/pubs/sp/800/88/r2/final). - CISA, [How to Protect the Data That is Stored on Your Devices](https://www.cisa.gov/resources-tools/training/how-protect-data-stored-your-devices). ## Primary reference - Name: CISA: How to Protect the Data That is Stored on Your Devices - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/resources-tools/training/how-protect-data-stored-your-devices - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan removable-media controls around business use, malware risk, and sanitization,” DSE Security, https://update.dsesecurity.com/updates/plan-removable-media-controls-business-use-malware-sanitization/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan removal and recovery of the Remote Desktop Connection app > What must be prepared before removing the Windows Remote Desktop Connection client? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-169-plan-removal-and-recovery-of-the-remote-desktop-connection-app/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:22+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know What must be prepared before removing the Windows Remote Desktop Connection client? ## Potentially affected Administrators managing the built-in Remote Desktop Connection app on Windows 11. ## DSE recommendation Ask the device owner to identify an approved alternative access method and a rollback contact. ## Article ## Source facts Microsoft permits uninstalling the built-in Remote Desktop Connection application starting with Windows 11 version 23H2. Its procedure offers graphical and command-line removal methods. The reinstall procedure provides installers selected to match the computer architecture. Removing the client also prevents use of the RemoteApp and Desktop Connections control panel. Microsoft identifies error 0x800704c7 in this removal procedure as a sign that the command is not running with administrator privileges. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/uninstall-remote-desktop-connection). ## Applicability Inventory the Windows release and client application before scheduling removal. Explicitly check reliance on the RemoteApp and Desktop Connections control panel as well as direct client sessions. Review the reinstall instructions while access to the official download source is still available. ## DSE recommendation Ask the device owner to identify an approved alternative access method and a rollback contact. Record the intended removal scope, required elevation, restart handling, and architecture-matched reinstall package. Pilot on a representative managed device before expanding the assignment. Keep the removal decision tied to the client application rather than assuming it changes the configuration of remote computers. ## Verification After the pilot, verify the application inventory and the approved alternative workflow. Exercise reinstall on the test device and confirm that the intended client opens and can reach an authorized test computer. Capture the actual command result and any restart requirement. Treat a privilege error as a failed operation, not a completed removal. ## Official references [Microsoft Learn: Uninstall and Reinstall the Remote Desktop Connection App in Windows](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/uninstall-remote-desktop-connection). Source reviewed September 8, 2026. ## Primary reference - Name: Uninstall and Reinstall the Remote Desktop Connection App in Windows - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/uninstall-remote-desktop-connection - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan removal and recovery of the Remote Desktop Connection app,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-169-plan-removal-and-recovery-of-the-remote-desktop-connection-app/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan rural clinic and FQHC continuity with community partners > Use 42 CFR 491.12 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/plan-rural-clinic-and-fqhc-continuity-with-community-partners/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:57+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 491.12 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 491.12 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Plan rural clinic and FQHC continuity with community partners. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 491.12 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-491.12) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 491, the rule requires that if elected, the unified and integrated emergency preparedness program do all of the following: include integrated policies and procedures that meet the requirements set forth in paragraph (b) of this section, a coordinated communication plan, and training and testing programs that meet the requirements of paragraphs (c) and (d) of this section, respectively. The research record locates this support at 42 CFR 491.12(e)(5), read with 42 CFR 491.12(e) (eCFR anchor p-491.12(e)(5)). - Under 42 CFR 491, the rule requires that the RHC or FQHC develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 491.12(d) (eCFR anchor p-491.12(d)). The source support ends with the statements listed above. Use them to examine essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives in the applicable environment, not to imply a wider guarantee. ## What the source does not establish RHC and FQHC-specific federal condition; local hazards, limited staffing, referral and transport networks, state law, and survey guidance require site-specific planning. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 491.12(e)(5), read with 42 CFR 491.12(e) (eCFR anchor p-491.12(e)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 491.12(d) (eCFR anchor p-491.12(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 42 CFR 491.12(e)(5), read with 42 CFR 491.12(e) (eCFR anchor p-491.12(e)(5)); 42 CFR 491.12(d) (eCFR anchor p-491.12(d)). Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [42 CFR 491.12 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-491.12) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 491.12 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-491.12 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan rural clinic and FQHC continuity with community partners,” DSE Security, https://update.dsesecurity.com/updates/plan-rural-clinic-and-fqhc-continuity-with-community-partners/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan Storage Migration Service cutover around the server identity handoff > What must be accepted when Storage Migration Service transfers a server identity? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-026-plan-storage-migration-service-cutover-around-the-server-identity-handoff/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:45+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What must be accepted when Storage Migration Service transfers a server identity? ## Potentially affected Use this review when the inventory and transfer work has reached an approved identity-handoff decision. ## DSE recommendation Prepare an endpoint worksheet and have a second administrator check it against the migration plan. ## Article ## Source facts Cutover transfers the source computer’s network identity to the destination. Microsoft states that the source retains its files afterward but is no longer available to users and applications. Before cutover, the administrator supplies the destination network configuration and can select a unique replacement name for the source. The service exposes progress descriptions for the individual cutover stages. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/cutover). ## Applicability Use this review when the inventory and transfer work has reached an approved identity-handoff decision. Identify both computers, their intended final names, and the users and applications that must reach the destination. ## DSE recommendation Prepare an endpoint worksheet and have a second administrator check it against the migration plan. Name the person who will authorize the handoff and the workload owners who will accept it. Communicate the interruption window and preserve the pre-cutover state needed by the approved recovery procedure. Keep the retained source files under controlled ownership while acceptance remains open. ## Verification Record the reported cutover stages and verify the resulting names and network configuration. Test the actual client paths and application operations selected in advance. Confirm that users reach the intended destination and that the source is handled according to the approved plan. Investigate partial completion before declaring the migration accepted. ## Official references [Microsoft Learn: How cutover works in Storage Migration Service](https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/cutover). Source reviewed September 8, 2026. ## Primary reference - Name: How cutover works in Storage Migration Service - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-migration-service/cutover - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan Storage Migration Service cutover around the server identity handoff,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-026-plan-storage-migration-service-cutover-around-the-server-identity-handoff/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan the client address pool for Azure Network Adapter > What address space is needed when connecting a server through Azure Network Adapter? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-242-plan-the-client-address-pool-for-azure-network-adapter/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:09+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What address space is needed when connecting a server through Azure Network Adapter? ## Potentially affected Administrators evaluating Windows Admin Center Azure Network Adapter for server-to-Azure connectivity. ## DSE recommendation Have the network owner compare the proposed client pool against both address plans. ## Article ## Source facts Azure Network Adapter uses a Point-to-Site VPN connection to connect a server with an Azure virtual network. Microsoft describes this option for a small number of servers and states that it needs neither an on-premises VPN device nor a public-facing client address. Its private client address pool must not overlap the connecting on-premises location or destination virtual network. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/use-azure-network-adapter). ## Applicability Confirm the active Azure subscription, existing virtual network, server internet access, and Windows Admin Center integration prerequisites. Scope this design to the servers needing the connection, not an assumed site-wide transit service. Review gateway resources and associated charges before creation. ## DSE recommendation Have the network owner compare the proposed client pool against both address plans. Reserve the accepted range and identify the target subscription, network, and gateway in the change record. Agree which server-to-Azure application flow will demonstrate success. Keep connection removal and any newly created Azure resource cleanup under separate, explicit ownership. ## Verification After an approved setup, inspect the address assigned to the server connection and verify it belongs to the reserved pool. Test the named application flow and confirm the intended destination network. Review unexpected routes or overlapping addresses before adding another server to the connection plan. ## Official references [Microsoft Learn: Connect server to Azure Virtual Network – Azure Network Adapter](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/use-azure-network-adapter). Source reviewed September 8, 2026. ## Primary reference - Name: Connect server to Azure Virtual Network - Azure Network Adapter - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/use-azure-network-adapter - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan the client address pool for Azure Network Adapter,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-242-plan-the-client-address-pool-for-azure-network-adapter/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan the hosted cache server alongside its BranchCache clients > What must be included when deploying BranchCache in hosted-cache mode? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-074-plan-the-hosted-cache-server-alongside-its-branchcache-clients/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:57+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What must be included when deploying BranchCache in hosted-cache mode? ## Potentially affected Use this review after choosing hosted-cache mode for a supported BranchCache deployment. ## DSE recommendation Create a responsibility map covering the cache host, client configuration, source content, and existing branch connectivity. ## Article ## Source facts Microsoft’s hosted-cache design requires both branch clients configured for that mode and a hosted cache server at the branch. Choosing a shared server and cache allocation depends on its workload, hardware, and branch size. The guide does not provision the branch WAN, DHCP, read-only domain controller, or VPN service. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/bc-hcm/1-Deploy-Bc-Hcm). ## Applicability Use this review after choosing hosted-cache mode for a supported BranchCache deployment. Identify the branch, clients, content sources, and proposed cache host. Check client and server release requirements before following the historical deployment example. ## DSE recommendation Create a responsibility map covering the cache host, client configuration, source content, and existing branch connectivity. Have the server owner approve the cache allocation and any cohosted workload. Record which network prerequisites are already provided and which remain unresolved. Keep initial content preparation and client rollout coordinated in one deployment record. ## Verification Test access to representative content from the selected clients and inspect the intended cache host. Record workload and capacity observations on that host during the exercise. Check that the client configuration matches the chosen mode. Resolve missing prerequisites or unexpected resource contention before extending the deployment to another branch. ## Official references [Microsoft Learn: Deploy BranchCache Hosted Cache Mode](https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/bc-hcm/1-Deploy-Bc-Hcm). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy BranchCache Hosted Cache Mode - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/bc-hcm/1-Deploy-Bc-Hcm - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan the hosted cache server alongside its BranchCache clients,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-074-plan-the-hosted-cache-server-alongside-its-branchcache-clients/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan the Hyper-V host role before installing guest workloads > What should be verified when enabling the Hyper-V role on Windows Server? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-233-plan-the-hyper-v-host-role-before-installing-guest-workloads/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:18+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What should be verified when enabling the Hyper-V role on Windows Server? ## Potentially affected Administrators enabling Hyper-V on a Windows Server host, including Server Core. ## DSE recommendation Record the chosen server, installation option, management workstation, and approved restart window. ## Article ## Source facts Microsoft directs administrators to verify hardware compatibility before installing the Hyper-V role. The documented PowerShell installation example restarts the server after role installation. On Server Core, including management tools installs the PowerShell module; Hyper-V Manager can instead run on another computer for remote management. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Install-Hyper-V). ## Applicability Distinguish installing a virtualization host from installing only management tools. Review the host hardware and any other virtualization software against the cited requirements. Plan for the restart behavior of the selected installation method before scheduling the work. ## DSE recommendation Record the chosen server, installation option, management workstation, and approved restart window. Have the host owner confirm that existing workloads can tolerate the change. For Server Core, prepare the remote management route in advance instead of expecting a local graphical console. Keep guest creation as a later, separately approved step after the host installation is verified. ## Verification After the server returns, verify that the Hyper-V role is installed using the documented role-status check. Open the intended management path and confirm it targets the correct host. Record the restart and role state before allocating guest storage, connecting workload networks, or accepting virtual machines onto the host. ## Official references [Microsoft Learn: Install Hyper-V in Windows and Windows Server](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Install-Hyper-V). Source reviewed September 8, 2026. ## Primary reference - Name: Install Hyper-V in Windows and Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/get-started/Install-Hyper-V - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan the Hyper-V host role before installing guest workloads,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-233-plan-the-hyper-v-host-role-before-installing-guest-workloads/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan the RD Connection Broker outage before upgrading RDS roles > In what order should RDS roles be upgraded, and where is an outage expected? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-159-plan-the-rd-connection-broker-outage-before-upgrading-rds-roles/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:32+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know In what order should RDS roles be upgraded, and where is an outage expected? ## Potentially affected Administrators planning Windows Server upgrades for an RDS deployment. ## DSE recommendation Build a role-by-role sequence with an explicit broker outage window. ## Article ## Source facts Microsoft upgrades RD Connection Broker first. In an active/active deployment, it removes all but one broker, upgrades that broker in place, upgrades the others offline, and adds them back. The deployment is unavailable during the broker upgrade. All brokers must be upgraded; mixed broker versions are unsupported. License servers should be upgraded before Session Host servers. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/upgrade-to-rds). ## Applicability Inventory every RDS role, its release, redundancy configuration, and allowed upgrade path. Review the source’s role-specific limitations and known upgrade issues before scheduling the work. ## DSE recommendation Build a role-by-role sequence with an explicit broker outage window. Have the RDS owner agree on user communication, session handling, recovery checkpoints, and the conditions for advancing to the next role. Preserve the deployment inventory and required recovery material before the first upgrade. ## Verification After the broker stage, confirm that all brokers run the intended release and test the required session workflows. Repeat appropriate checks after the licensing and Session Host stages. Record failures and mixed-version exceptions before declaring the overall deployment upgraded. ## Official references [Microsoft Learn: Upgrade Remote Desktop Services deployments](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/upgrade-to-rds). Source reviewed September 8, 2026. ## Primary reference - Name: Upgrade Remote Desktop Services deployments - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/upgrade-to-rds - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan the RD Connection Broker outage before upgrading RDS roles,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-159-plan-the-rd-connection-broker-outage-before-upgrading-rds-roles/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan the WAC high-availability transition across the 2410 architecture change > What deployment constraints apply when upgrading an older highly available WAC gateway? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-238-plan-the-wac-high-availability-transition-across-the-2410-architecture-change/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:13+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What deployment constraints apply when upgrading an older highly available WAC gateway? ## Potentially affected Administrators upgrading Windows Admin Center gateways hosted in failover clusters. ## DSE recommendation Have the gateway owner prepare the documented uninstall-and-reinstall transition in a representative cluster. ## Article ## Source facts Microsoft describes the clustered WAC gateway as active-passive, with one active instance at a time. Its current guidance says highly available versions 2311 and earlier cannot directly upgrade to versions 2410 and later because of architectural changes. The documented high-availability prerequisites include shared persistent storage and the required certificate with its private key on every node. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/deploy/high-availability). ## Applicability Identify the actual gateway version and deployment method before selecting an upgrade path. Review the current HA scripts and certificate requirements rather than using an ordinary single-server update procedure. Treat this transition as a deployment change with its own maintenance and recovery plan. ## DSE recommendation Have the gateway owner prepare the documented uninstall-and-reinstall transition in a representative cluster. Preserve the current configuration and required recovery material through approved handling. Assign ownership for the shared storage and certificate installation on each node. Maintain an alternative management route during the change and agree on the conditions that require stopping the rollout. ## Verification Verify the resulting gateway version, active instance, certificate presentation, and access to an intended managed server. Exercise the agreed node failover and confirm management resumes through the expected gateway name. Record any configuration that required restoration or recreation before accepting the upgraded highly available deployment. ## Official references [Microsoft Learn: Deploy Windows Admin Center with High Availability](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/deploy/high-availability). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy Windows Admin Center with High Availability - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/deploy/high-availability - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Plan the WAC high-availability transition across the 2410 architecture change,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-238-plan-the-wac-high-availability-transition-across-the-2410-architecture-change/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan vehicle-incident mitigation before buying barriers > Vehicle risk is shaped by approach speed, geometry, pedestrian exposure, deliveries, traffic operations, emergency access, and site use. Use CISA’s Plan-Prevent-Protect framework to define the problem before selecting a barrier. - Canonical URL: https://update.dsesecurity.com/updates/plan-vehicle-incident-mitigation-before-barriers/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:27:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Business Continuity, Video Surveillance - Reading time: 3 minutes ## What you need to know Vehicle risk is shaped by approach speed, geometry, pedestrian exposure, deliveries, traffic operations, emergency access, and site use. Use CISA’s Plan-Prevent-Protect framework to define the problem before selecting a barrier. ## Potentially affected Campuses, storefronts, public venues, parking and delivery areas, gatehouses, pedestrian approaches, temporary events, vehicle gates and barriers, cameras, lighting, communications, and emergency routes. ## DSE recommendation Complete a site-specific vehicle assessment, map people and vehicle movement, use layered operational and physical measures, and have qualified professionals design and approve any barrier or traffic-control work. ## Article ## Source facts: vehicle mitigation is a site-specific program CISA’s April 2024 [Vehicle Incident Prevention and Mitigation Security Guide](https://www.cisa.gov/resources-tools/resources/vehicle-incident-prevention-and-mitigation-security-guide) addresses intentional and unintentional vehicle threats near critical infrastructure, facilities, venues, and pedestrians. It presents a Plan-Prevent-Protect framework rather than a single product prescription. Under planning, CISA discusses risk assessment, emergency operations planning, professional security expertise, and resources for mitigation. Prevention considerations include traffic and crowd management, awareness of concerning behavior or suspicious vehicle activity, reporting, training, and layered security. Protection includes appropriately selected and installed active or passive barriers and understanding relevant perimeter-protection standards. CISA explicitly says not every recommendation applies to every organization and there is no one-size-fits-all security solution. The guide is a starting point and does not guarantee prevention. Barrier engineering, roadway design, accessibility, emergency access, fire and building requirements, permits, utilities, drainage, snow operations, and property boundaries require qualified professionals and the applicable authorities. ## DSE recommendation: define the vehicle problem in layers Begin with a scaled site plan and observed operations. Mark public roads, curbs, slopes, medians, parking, loading, queuing, drop-off, ride-share, bus and delivery routes, emergency access, pedestrian gathering, accessible routes, building entrances, critical equipment, temporary-event changes, and land a vehicle could traverse. Include adjacent property where its geometry materially shapes an approach. - Describe credible scenarios without guessing intent. Consider accidental loss of control, driver error, unauthorized entry, tailgating at a gate, a vehicle entering a pedestrian space, and other scenarios selected by the organization’s risk process. Record target area, approach path, possible vehicle class and speed, exposed people or assets, and existing controls. - Observe normal movement. Count and watch vehicles and pedestrians during shift changes, deliveries, events, winter operations, and after hours. A control that works in an empty drawing may create queues, unsafe crossings, or bypass behavior in service. - Reduce opportunity operationally. Evaluate routing, scheduling, delivery control, parking placement, traffic calming, staffed entry, credential and visitor processes, lighting, signs, reporting, and temporary-event procedures before assuming a fixed barrier is the only layer. - Define detection and response. Assign camera views, intercoms, gate events, duress or alarm procedures, lighting, staff observation, and responder communication to specific zones. Test whether an operator can understand location and direction quickly enough to take the approved action. - Engineer physical protection. When the assessment supports a barrier, provide the qualified designer with the approach geometry, desired protection objective, site constraints, operations, utilities, drainage, accessibility, emergency access, maintenance, and evidence needed for selection and installation. Do not infer performance from appearance or an unlabeled product. - Plan the degraded day. Define safe operation during gate failure, power loss, snow, construction, a damaged barrier, a blocked lane, a large event, or emergency response. Temporary measures need the same ownership and review as permanent ones. Acceptance should cover more than the barrier. Walk and drive the approved routes; verify signs, lane assignments, credentials, intercom and guard views, gate sequencing, pedestrian separation, lighting, camera evidence, communications, emergency access, and the procedure for a suspicious or disabled vehicle. Do not perform impact testing on an installed site unless it is part of a professionally controlled program. Maintain a register of assumptions, drawings, product and installation evidence, inspections, repairs, exercises, incidents, near misses, operational exceptions, and responsible owners. Reassess after a roadway or parking change, new tenant or event use, construction, landscaping, barrier strike, delivery-pattern change, or significant incident. The strongest result is a layered site that manages ordinary traffic safely while reducing plausible vehicle opportunities—not an isolated row of hardware with no operating plan. Review the completed plan with operations, facilities, security, accessibility stakeholders, and emergency-response partners whose work or access it changes. ## Official references - Cybersecurity and Infrastructure Security Agency, [Vehicle Incident Prevention and Mitigation Security Guide](https://www.cisa.gov/resources-tools/resources/vehicle-incident-prevention-and-mitigation-security-guide), April 23, 2024. - CISA, [full guide (PDF)](https://www.cisa.gov/sites/default/files/2024-04/Vehicle_Incident_Prevention_and_Mitigation_Security_Guide_508_20240418.pdf), April 2024. ## Primary reference - Name: Cybersecurity and Infrastructure Security Agency: Vehicle Incident Prevention and Mitigation Security Guide - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/resources-tools/resources/vehicle-incident-prevention-and-mitigation-security-guide - Source publication date: 2024-04-23 ## Citation and use Preferred citation: “Plan vehicle-incident mitigation before buying barriers,” DSE Security, https://update.dsesecurity.com/updates/plan-vehicle-incident-mitigation-before-barriers/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Plan Windows 10 ESU Year 2 without confusing 22H2 and LTSC > As of August 4, 2026, Windows 10 ESU Year 2 planning requires an edition-and-version inventory. Commercial 22H2 ESU is annual and cumulative; LTSC and LTSB releases follow separate lifecycles and must not be grouped with 22H2. - Canonical URL: https://update.dsesecurity.com/updates/plan-windows-10-esu-year-2-without-confusing-22h2-and-ltsc/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know As of August 4, 2026, Windows 10 ESU Year 2 planning requires an edition-and-version inventory. Commercial 22H2 ESU is annual and cumulative; LTSC and LTSB releases follow separate lifecycles and must not be grouped with 22H2. ## Potentially affected Organizations still operating Windows 10 version 22H2 under commercial ESU, Windows 10 Enterprise LTSC or LTSB, embedded or special-purpose devices, and applications or hardware delaying Windows 11 migration. ## DSE recommendation Classify every remaining Windows 10 device by exact edition, version, and servicing channel; verify its current Microsoft lifecycle and licensing path; then approve either migration, retirement, or a time-bounded support bridge. ## Article ## Source fact: commercial 22H2 ESU is a bridge Microsoft states that Windows 10 reached end of support on October 14, 2025. Its [commercial Extended Security Updates program](https://learn.microsoft.com/en-us/windows/whats-new/extended-security-updates) allows eligible enrolled PCs to receive Critical and Important security updates after that date. Devices must run Windows 10 version 22H2. ESU does not add features, customer-requested nonsecurity updates, design changes, or general support for an out-of-support Windows release. The program is annual. Microsoft says customers cannot purchase a partial period and that a customer entering in Year 2 must also acquire Year 1 because coverage is cumulative. Microsoft’s lifecycle FAQ lists Windows 10 ESU Year 1 through October 13, 2026 and Year 2 through October 12, 2027. Pricing, program channel, and eligibility can change, so this article does not quote a budget figure; obtain a current written quote and licensing confirmation for the actual estate. ## Source fact: LTSC and LTSB are not 22H2 Microsoft’s [LTSC overview](https://learn.microsoft.com/en-us/windows/whats-new/ltsc/overview) explains that the Long-Term Servicing Channel was previously called the Long-Term Servicing Branch and that each release maps to a particular Windows feature version. LTSC is intended for special-purpose devices and has release-specific support. A device labeled Windows 10 Enterprise does not reveal enough to select an ESU or migration plan. - Windows 10 Enterprise LTSC 2021 corresponds to version 21H2 and has a five-year lifecycle for the non-IoT Enterprise edition. Microsoft’s lifecycle page lists January 12, 2027 as its support end; IoT Enterprise LTSC 2021 has a different lifecycle. - Windows 10 Enterprise LTSC 2019 corresponds to version 1809 and follows its own lifecycle. - Windows 10 Enterprise 2016 LTSB corresponds to version 1607 and reaches support end on October 13, 2026. Microsoft has published a separate transition path for that release. Do not apply the 22H2 ESU prerequisite or dates to LTSC or LTSB by analogy. Verify the exact edition in Microsoft Lifecycle and the applicable licensing terms. An IoT label, embedded use, or appliance form factor can also change which product lifecycle and support contract govern the device. ## DSE recommendation: build a decision-grade inventory now For every remaining Windows 10 endpoint, record hardware identifier, owner, user or device purpose, exact edition, display version and build, servicing channel, architecture, management platform, update source, last successful security update, ESU activation state where applicable, Windows 11 eligibility, application and peripheral blockers, data sensitivity, network exposure, replacement dependency, and target exit date. Reconcile management data with procurement and physical inventory so offline and special-purpose systems are not invisible. Divide devices into four owned outcomes: upgrade in place to a supported Windows release; replace hardware; retire or consolidate the workload; or retain temporarily under a verified support bridge. A bridge requires an approved business reason, licensing evidence, update-health monitoring, compensating controls based on exposure, and a funded migration milestone. It is not a permanent operating model. ## DSE recommendation: prove Year 2 readiness and migration separately - Confirm which 22H2 devices truly need Year 2 and which will exit before Year 1 ends. Do not purchase from a stale device count. - Verify licensing eligibility, cumulative prior-year requirement, activation method, management prerequisites, and support route with Microsoft or the authorized licensing partner. - Use a representative pilot to prove activation, update detection, deployment, restart behavior, reporting, and rollback procedures before broad reliance. - Track monthly update success and exceptions using device-level evidence. ESU entitlement without successful deployment does not reduce operational exposure. - Maintain a separate migration board with each blocker, accountable owner, decision date, test result, procurement dependency, and retirement evidence. Escalate devices that cannot be inventoried, updated, isolated, or tied to an exit owner. Review LTSC suitability rather than treating it as a general-purpose refuge; Microsoft’s documentation describes LTSC as a special-use channel and warns that support from applications and tools designed for the general availability channel may be limited. ## Official sources - [Microsoft Learn: Extended Security Updates program for Windows 10](https://learn.microsoft.com/en-us/windows/whats-new/extended-security-updates) - [Microsoft Lifecycle FAQ: Extended Security Updates](https://learn.microsoft.com/en-us/lifecycle/faq/extended-security-updates) - [Microsoft Learn: Windows Enterprise LTSC overview](https://learn.microsoft.com/en-us/windows/whats-new/ltsc/overview) - [Microsoft Lifecycle: Windows 10 Enterprise LTSC 2021](https://learn.microsoft.com/en-us/lifecycle/products/windows-10-enterprise-ltsc-2021) - [Microsoft Lifecycle: Windows 10 2016 LTSB](https://learn.microsoft.com/en-us/lifecycle/products/windows-10-2016-ltsb) ## Primary reference - Name: Microsoft Learn — Extended Security Updates program for Windows 10 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/whats-new/extended-security-updates - Source publication date: 2025-11-17 ## Citation and use Preferred citation: “Plan Windows 10 ESU Year 2 without confusing 22H2 and LTSC,” DSE Security, https://update.dsesecurity.com/updates/plan-windows-10-esu-year-2-without-confusing-22h2-and-ltsc/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Practice GETS calls before normal telephone service is congested > Train enrolled personnel to use the Government Emergency Telecommunications Service and maintain their access information before a crisis. - Canonical URL: https://update.dsesecurity.com/updates/practice-gets-calls-before-congestion/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:32+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Train enrolled personnel to use the Government Emergency Telecommunications Service and maintain their access information before a crisis. ## Potentially affected Organizations and personnel eligible for or enrolled in CISA's Government Emergency Telecommunications Service ## DSE recommendation Enroll only through the official program, protect user credentials, and conduct approved practice calls from realistic devices and locations. ## Article GETS can support priority calling for enrolled subscribers when ordinary calls are difficult to complete, but users still need their access information, a current dialing workflow, and a working connection from the devices available during the incident. ## Source fact: A [CISA Priority Telecommunications Services presentation hosted by HHS 405(d)](https://405d.hhs.gov/Documents/405d-webinar-2024-0327-cisa-telcom-svc.pdf) says events including cyberattacks, extreme weather, human error, and high call volume can degrade, destroy, or overload network infrastructure. It explains that GETS enhances voice-call completion when commercial networks are overloaded or impaired and provides end-to-end priority over landline commercial networks. The presentation instructs a user to dial the universal GETS access number, enter the user’s PIN after the tone, and then enter the destination number when prompted. Its best-practices slide recommends practicing with GETS and WPS, making test calls frequently, and incorporating those calls into training exercises. It also directs users to report call problems and lists the Priority Telecommunications Service Center’s 24-hour assistance number. The presentation reports a generally greater-than-95-percent GETS completion rate; it does not promise that every call will complete or that destroyed infrastructure will remain available. ## Boundary Use current CISA resources and the CISA Priority Telecommunications Service Center for enrollment and dialing details. This article does not enroll a person or organization or replace CISA instructions. The presentation distinguishes GETS priority over wireline commercial networks from WPS priority over wireless networks. The following continuity steps are DSE recommendations; they do not assert that a specific call path will work. ## Applicability questions - Which incident roles need to place essential calls during congestion, and are those people eligible and currently enrolled? - Can they retrieve their GETS access information if corporate identity, email, or mobile-data service is unavailable? - Which originating phones, PBXs, calling plans, and locations are likely during activation? - Are destination numbers maintained offline and expressed in a dialable format? - Who reports lost credentials, role changes, departures, and failed test calls? ## DSE recommendation: Use CISA’s current process to determine eligibility and enroll the minimum operational roles that require priority calling. Assign program administration, user training, roster review, and credential-loss response. Protect PINs from shared documents and tickets while ensuring each user has an approved, resilient way to retrieve their own information during an outage. Conduct practice calls only as permitted by current program guidance. Include the actual devices and calling paths users expect at a primary site, alternate site, home, and field location. Have the user follow the complete sequence, reach a designated test recipient, and record only nonsecret results. Pair the test with scenarios in which corporate contact lists, single sign-on, mobile data, or normal PBX dialing are unavailable. Maintain satellite, radio, alternate-carrier, or other communications where the continuity assessment requires them. ## Verification and evidence Keep an access-controlled roster of active enrolled roles, training dates, approved practice-call records, failure tickets, CISA support contacts, and quarterly or other defined review evidence. Do not store PINs in the evidence package. A useful exercise verifies both the user’s procedure and the destination’s readiness to recognize the call and exchange the necessary information. Remove or update access promptly after role and employment changes through the official process. ## Official references - [CISA Priority Telecommunications Services presentation, hosted by HHS 405(d)](https://405d.hhs.gov/Documents/405d-webinar-2024-0327-cisa-telcom-svc.pdf) ## Primary reference - Name: CISA Priority Telecommunications Services presentation - Authority: 405d.hhs.gov - URL: https://405d.hhs.gov/Documents/405d-webinar-2024-0327-cisa-telcom-svc.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Practice GETS calls before normal telephone service is congested,” DSE Security, https://update.dsesecurity.com/updates/practice-gets-calls-before-congestion/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Practice the restart sequence after facility power returns > Utility power returning does not mean every dependent service is ready. Build and rehearse an authorized restart sequence that validates power quality, facility systems, network, identity, storage, applications, security, and monitoring. - Canonical URL: https://update.dsesecurity.com/updates/practice-facility-power-restoration-restart-sequence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:47:00+00:00 - Modified: 2026-08-17T19:22:10+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Utility power returning does not mean every dependent service is ready. Build and rehearse an authorized restart sequence that validates power quality, facility systems, network, identity, storage, applications, security, and monitoring. ## Potentially affected Facility electrical and cooling systems; generators and UPS; network, storage, virtualization and identity; physical-security systems; business applications; monitoring; vendors; communications; and post-outage change control. ## DSE recommendation Map service dependencies and startup authority, define safe prerequisites and sequencing, create observable checkpoints and abort criteria, rehearse representative restoration, validate business workflows, and feed findings back into continuity plans. ## Article ## Source facts: restoration requires planning beyond power availability The [Ready Business Power Outage Toolkit](https://www.ready.gov/sites/default/files/2020-04/ready_business_power-outage-toolkit.pdf) asks organizations to evaluate outage impacts, create a plan, protect systems and data, identify backup-power needs, communicate, train, and exercise. The toolkit treats power loss as a business interruption whose consequences and recovery tasks extend beyond the utility feed. FEMA [P-1019](https://www.fema.gov/sites/default/files/2020-07/fema_p-1019_final_02-06-2015.pdf) explains that emergency power performance depends on generation, fuel, transfer, distribution, controls, maintenance, testing, and connected loads. Returning from backup to normal supply is part of that system behavior, and downstream services may have their own safe operating prerequisites. The sources support planning and testing but do not provide a universal IT restart order. Actual sequence depends on electrical and life-safety conditions, cooling, network design, identity, storage consistency, application architecture, vendor requirements, and the cause of the outage. Restoring damaged or wet equipment can be dangerous. ## DSE recommendation: promote services through observable recovery stages Create one coordinated runbook with facility, safety, IT, security, operations, application, communications, and vendor owners. No technical convenience should override qualified confirmation that power and the environment are safe. - Map dependency layers. Connect each critical business service to power, UPS, cooling, carrier links, switching, routing, firewalls, DNS, time, identity, storage, virtualization, databases, middleware, integrations, physical-security systems, and required staff. Identify circular dependencies and manual credentials needed during an identity outage. - Assign command and authority. Name who confirms facility safety, authorizes energization, controls generator or transfer actions, starts each technology layer, communicates status, approves vendor access, and declares service restored. Provide alternates and an offline copy of contacts and procedures. - Define entry conditions. Require qualified checks for damage, water, smoke, temperature, grounding, voltage, frequency, phase, transfer state, fuel, UPS alarms, and cooling before equipment starts. Set abort criteria for unstable power, overheating, unusual noise or odor, repeated trips, and uncertain equipment condition. - Sequence by dependency and load. Restore facility services and approved infrastructure, then foundational network, name and time services, identity, storage and compute, databases, applications, integrations, monitoring, and user access as the architecture requires. Stage inrush and demand according to engineering limits. - Use checkpoints rather than assumptions. At each stage, validate redundancy, configuration, replication, data consistency, certificate and clock state, routing, authentication, queues, backups, alarms, logging, and downstream reachability. Record the observer, time, evidence, deviation, and decision to proceed. - Test end-to-end business workflows. A green server console is not proof of service. Validate representative customer communication, ticketing, access events, video, remote access, transactions, printing, alerting, escalation, backup, and reporting with business owners. - Stabilize after return. Monitor delayed failures, exhausted batteries, thermal change, storage rebuilds, expired sessions, missed jobs, duplicate processing, carrier instability, and security-control gaps. Replenish fuel, back up changed state, open corrective actions, and conduct a structured review. Keep recovery credentials and runbooks available through a protected offline or independently reachable path. Test that designated personnel can retrieve them when normal identity, password vault, file sharing, telephony, and internet services are unavailable. Use controlled check-out, tamper evidence, rotation after use, and dual authorization for powerful emergency credentials. Define a stop point for every layer. If power quality, temperature, storage consistency, identity replication, routing, security telemetry, or application data integrity is outside its accepted range, hold the next layer, preserve evidence, and invoke the named recovery owner. Continuing can transform a contained fault into wider corruption or unsafe load. Factual boundary: The correct restart sequence is site-, architecture-, and vendor-specific. This article never authorizes energizing damaged, wet, overheated, contaminated, or otherwise unsafe equipment. Qualified electrical, facility, safety, engineering, manufacturer, utility, and authority-having-jurisdiction direction takes precedence. Measure time to qualified release, checkpoint success, undocumented dependencies, manual interventions, failed service tests, repeat incidents, and corrective-action closure. Declare recovery only when priority business services work safely and monitoring can detect their next failure. ## Official references - Ready.gov, [Ready Business Power Outage Toolkit](https://www.ready.gov/sites/default/files/2020-04/ready_business_power-outage-toolkit.pdf). - FEMA, [P-1019: Emergency Power Systems for Critical Facilities](https://www.fema.gov/sites/default/files/2020-07/fema_p-1019_final_02-06-2015.pdf). ## Primary reference - Name: Ready Business Power Outage Toolkit - Authority: Ready.gov - URL: https://www.ready.gov/sites/default/files/2020-04/ready_business_power-outage-toolkit.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Practice the restart sequence after facility power returns,” DSE Security, https://update.dsesecurity.com/updates/practice-facility-power-restoration-restart-sequence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Predefine safe actions before integrating ShakeAlert > Treat earthquake early warning as a rapid signal after an earthquake begins, then engineer bounded human or automated actions for uncertain warning time. - Canonical URL: https://update.dsesecurity.com/updates/predefine-safe-actions-for-shakealert/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:21+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Treat earthquake early warning as a rapid signal after an earthquake begins, then engineer bounded human or automated actions for uncertain warning time. ## Potentially affected Organizations in California, Oregon, or Washington evaluating ShakeAlert-powered notifications or automated protective actions ## DSE recommendation Select only actions that remain safe with a late, missed, duplicate, or mistaken alert, then qualify the complete delivery and recovery path. ## Article ShakeAlert is not earthquake prediction. It can provide limited time for a predefined protective action after an earthquake has already started, so any human or automated integration must remain safe when warning time is short—or no alert arrives before shaking. ## Source fact: [The U.S. Geological Survey’s earthquake early-warning overview](https://www.usgs.gov/programs/earthquake-hazards/science/earthquake-early-warning-overview) explains that ShakeAlert detects an earthquake that has begun and estimates its location, magnitude, and shaking intensity. When an event meets USGS thresholds, the system issues a ShakeAlert Message. Technical partners use the message to deliver alerts to people or trigger automated protective actions. USGS gives examples of potential automated actions such as slowing a train, closing a valve, or making a public announcement. Early warning is possible because telecommunications can carry information faster than the damaging seismic waves travel; locations farther from the earthquake’s origin may have more time. USGS issues the message, while public and private delivery mechanisms provide the alert to users and systems. These facts do not mean every location or event receives useful warning time. ## Boundary The USGS overview describes the ShakeAlert system for the U.S. West Coast, specifically California, Oregon, and Washington. Availability, message access, technical-partner arrangements, delivery thresholds, latency, and supported automated interfaces must be verified through current official and provider documentation. The alert cannot predict the earthquake, stop shaking, assess post-event structural safety, or guarantee that a protective action completes. A false, updated, duplicate, missed, or late signal is a credible integration condition even when each component is functioning as designed. ## Applicability questions - Is the site and intended delivery mechanism inside the current supported geographic and service scope? - What specific injury, equipment, process, or infrastructure consequence could a rapid action reduce? - Does that action remain safe if it begins only seconds before shaking, begins unnecessarily, or receives no completion confirmation? - Which sensors, technical partners, Internet or private links, controllers, power, identity, and time sources carry the message? - How will people recognize the alert, take immediate protective action, and avoid delaying for local verification? ## DSE recommendation: Start with a narrowly defined protective outcome and involve life-safety, engineering, operations, legal, labor, accessibility, cybersecurity, facilities, and equipment owners. Compare a human notification with automation and select an action only when its failure modes are understood. Define the authorized input, thresholds, allowed state, interlocks, manual override, timeout, logging, and method for returning equipment to service. Use an approved ShakeAlert technical partner and authenticate every integration component according to current supported guidance. Separate the alert path from ordinary business workflows where the risk assessment requires it, and account for lost power or connectivity. Do not make an unsafe action depend on a last-second operator acknowledgment. Pair any alert with established earthquake instructions and post-event accountability; do not let automation replace protective training. Test with simulated messages, never an improvised production signal. Exercise expected, late, duplicate, updated, malformed, unauthorized, and absent messages; communications loss; controller restart; manual override; and restoration. Measure receipt-to-action time and verify the physical outcome safely with qualified personnel. ## Verification and evidence Keep the use-case approval, current USGS and partner documentation, geographic and threshold assumptions, architecture, interface and security configuration, safety analysis, interlocks, simulated-message set, synchronized logs, action timing, physical test evidence, override result, operator training, and residual-risk decision. Requalify after provider, threshold, network, controller, equipment, facility, or operating-procedure changes. A successful drill supports only the tested scenario and is not proof that a future earthquake will provide the same warning. ## Official references - [USGS: Earthquake Early Warning – Overview](https://www.usgs.gov/programs/earthquake-hazards/science/earthquake-early-warning-overview) - [USGS: ShakeAlert Basics](https://www.usgs.gov/media/files/factsheet-faq-shakealertr-basics) ## Primary reference - Name: Earthquake Early Warning - Overview - Authority: www.usgs.gov - URL: https://www.usgs.gov/programs/earthquake-hazards/science/earthquake-early-warning-overview - Source publication date: 2022-03-09 ## Citation and use Preferred citation: “Predefine safe actions before integrating ShakeAlert,” DSE Security, https://update.dsesecurity.com/updates/predefine-safe-actions-for-shakealert/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prefer granular alert tuning before Defender for Identity detection exclusions > Use Configure Defender for Identity detection exclusions in Microsoft Defender to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/prefer-granular-alert-tuning-before-identity-detection-exclusions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:48+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Configure Defender for Identity detection exclusions in Microsoft Defender to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Configure Defender for Identity detection exclusions in Microsoft Defender ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Prefer granular alert tuning before Defender for Identity detection exclusions. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Configure Defender for Identity detection exclusions in Microsoft Defender](https://learn.microsoft.com/en-us/defender-for-identity/exclusions) from Microsoft supports the following bounded statements: - Defender for Identity supports excluding specific IP addresses, computers, domains, or users from a number of detections. The research record locates this support at Opening exclusion overview. - Microsoft recommends Defender XDR alert-tuning rules instead of exclusions because tuning supports more granular conditions and lets analysts review tuned alerts. The research record locates this support at Tuning recommendation. The source support ends with the statements listed above. Use them to examine identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Any exclusion or tuning rule can hide relevant activity; require an owner, narrow conditions, evidence, expiry, and periodic review. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening exclusion overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Tuning recommendation, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening exclusion overview; Tuning recommendation. Favor sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Configure Defender for Identity detection exclusions in Microsoft Defender](https://learn.microsoft.com/en-us/defender-for-identity/exclusions) — Microsoft ## Primary reference - Name: Configure Defender for Identity detection exclusions in Microsoft Defender - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/exclusions - Source publication date: 2026-08-10 ## Citation and use Preferred citation: “Prefer granular alert tuning before Defender for Identity detection exclusions,” DSE Security, https://update.dsesecurity.com/updates/prefer-granular-alert-tuning-before-identity-detection-exclusions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prepare a Robocopy pre-seed for DFS Replication > Review the copy tool, locked-file handling, and source-to-destination evidence before using a pre-seed for DFS Replication. - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-018-prepare-a-robocopy-pre-seed-for-dfs-replication/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:53+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Checklist - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know Review the copy tool, locked-file handling, and source-to-destination evidence before using a pre-seed for DFS Replication. ## Potentially affected Windows Server administrators preparing files for a new or replacement DFS Replication member. ## DSE recommendation Approve the copy direction, stabilize the source data, and reconcile skipped or failed files before accepting the pre-seed. ## Article ## Source facts [Microsoft’s Robocopy procedure](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/preseed-dfsr-with-robocopy) describes pre-seeding as a way to shorten DFS Replication’s initial synchronization when establishing replication, adding a partner, or replacing a server. It calls for a current Robocopy version appropriate to the operating system and for stabilizing the files so locked files do not block copying. Except when the source runs Windows Server 2003 R2, the procedure permits running Robocopy on either server. ## Applicability Identify the source of truth, destination, replication membership, and operating-system versions. Review the source’s version-specific instructions rather than treating its historical examples as a deployment inventory. A completed file-copy job should be evaluated separately from the later replication acceptance test. ## DSE recommendation Have a second administrator review the approved source and destination paths before starting the copy. Plan how writers will be paused or otherwise coordinated, and record which data remains subject to change. Retain the chosen options and a sanitized log. Investigate skipped files and access failures individually instead of accepting a successful-looking completion message alone. ## Verification Compare representative files, directories, and permissions between the approved endpoints. Reconcile all unexplained copy failures, then conduct a separate initial-synchronization review and controlled replication test. Ask the data owner to confirm the destination contents before the old server is retired or repurposed. Keep the copy log and replication evidence together, with their timestamps and reviewer names. ## Official references [Microsoft Learn: Use Robocopy to pre-seed files for DFS Replication](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/preseed-dfsr-with-robocopy). Source reviewed September 8, 2026. ## Primary reference - Name: Use Robocopy to pre-seed files for DFS Replication - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/preseed-dfsr-with-robocopy - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prepare a Robocopy pre-seed for DFS Replication,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-018-prepare-a-robocopy-pre-seed-for-dfs-replication/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prepare an additional HGS node without overlooking its identity and DNS prerequisites > What must be checked before adding another Host Guardian Service node? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-013-prepare-an-additional-hgs-node-without-overlooking-its-identity-and-dns/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:58+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What must be checked before adding another Host Guardian Service node? ## Potentially affected Use this review when adding capacity or resilience to an existing HGS deployment. ## DSE recommendation Compare the proposed node with the primary before initialization. ## Article ## Source facts Microsoft recommends a highly available HGS cluster for production so a failed HGS node does not prevent shielded virtual machines from starting. Secondary nodes are optional in test environments. An additional node should match the primary node’s hardware and software, share the HGS network, and resolve the other HGS servers by name. The documented procedure joins it to the same domain as the first HGS node. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-configure-additional-hgs-nodes). ## Applicability Use this review when adding capacity or resilience to an existing HGS deployment. Identify its forest model and certificate arrangement, then follow the matching branch of the source procedure for that environment. ## DSE recommendation Compare the proposed node with the primary before initialization. Assign owners for name resolution, domain membership, certificates, and the workload acceptance test. Record the existing HGS service state and plan the addition during an agreed maintenance period. Keep the new node out of the accepted service inventory until its configuration and intended role have been reviewed. ## Verification Check name resolution and domain membership from the added node. Verify the completed HGS configuration against the selected procedure and perform an approved shielded-VM start test. Include a controlled loss of the node intended to be redundant. Record which nodes participated and investigate any failed start separately from successful installation. ## Official references [Microsoft Learn: Configure additional HGS nodes](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-configure-additional-hgs-nodes). Source reviewed September 8, 2026. ## Primary reference - Name: Configure additional HGS nodes - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-configure-additional-hgs-nodes - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prepare an additional HGS node without overlooking its identity and DNS prerequisites,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-013-prepare-an-additional-hgs-node-without-overlooking-its-identity-and-dns/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prepare and sign the template disk used for shielded VM provisioning > What makes a Windows template disk ready for shielded VM provisioning? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-076-prepare-and-sign-the-template-disk-used-for-shielded-vm-provisioning/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:55+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What makes a Windows template disk ready for shielded VM provisioning? ## Potentially affected Use this review when producing a shielded Windows VM template. ## DSE recommendation Have the image owner approve the guest configuration and update state before signing. ## Article ## Source facts Microsoft begins with an operating-system VHDX that meets the stated generation-2 and shielding requirements. The source calls for current Windows updates on the template operating system because missing updates can cause the shielding process to fail. The template-disk wizard prepares the disk with BitLocker, creates its hash in a volume signature catalog, and signs that catalog with a chosen certificate for provisioning checks. The wizard changes the selected disk in place, and its protected output cannot later be edited. Microsoft suggests retaining an unprotected VHDX copy for future updates. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-create-a-shielded-vm-template). ## Applicability Use this review when producing a shielded Windows VM template. Identify the intended guest release, image owner, signing certificate, and supported provisioning workflow. Keep the template preparation record separate from the tenant’s shielding-data artifact. ## DSE recommendation Have the image owner approve the guest configuration and update state before signing. Preserve an approved unprotected VHDX copy before running the wizard, under the organization’s image-management controls. Record the input identity and certificate custodian without exposing private key material. Plan how later image updates will produce a newly reviewed catalog while retaining the artifact already trusted by tenants. ## Verification Inspect the generated catalog and template identity after the approved preparation. Provision a representative shielded test VM and verify the intended guest and management behavior. Record which template and catalog were used. Resolve provisioning failures or an unexpected image identity before making the template available for additional tenant deployments. ## Official references [Microsoft Learn: Create a Windows shielded VM template disk](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-create-a-shielded-vm-template). Source reviewed September 8, 2026. ## Primary reference - Name: Create a Windows shielded VM template disk - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-create-a-shielded-vm-template - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prepare and sign the template disk used for shielded VM provisioning,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-076-prepare-and-sign-the-template-disk-used-for-shielded-vm-provisioning/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prepare bomb-threat decisions before the call or message arrives > Bomb threats demand organized intake, prompt responder notification, credible assessment, controlled searches, and deliberate choices among monitoring, search, lockdown, or evacuation. Automatically emptying the building can move people toward danger. - Canonical URL: https://update.dsesecurity.com/updates/prepare-bomb-threat-decisions-before-call-message-arrives/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:10:00+00:00 - Modified: 2026-08-11T14:48:23+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Access Control, Business Continuity - Reading time: 3 minutes ## What you need to know Bomb threats demand organized intake, prompt responder notification, credible assessment, controlled searches, and deliberate choices among monitoring, search, lockdown, or evacuation. Automatically emptying the building can move people toward danger. ## Potentially affected Reception, call centers, executives, schools, houses of worship, public venues, security teams, facilities, emergency managers, employees receiving email or social threats, evacuation teams, assembly areas, and first-responder coordination. ## DSE recommendation Build a bomb-threat management plan with trained receivers, a threat checklist, named decision makers, responder contacts, searchable floor information, authorized search and evacuation teams, alternate routes and assembly areas, accountability, and re-entry authority. ## Article ## Source facts: assess before selecting the response CISA’s Office for Bombing Prevention [Bomb Threat Guide](https://www.cisa.gov/sites/default/files/2023-08/Bomb%20Threat%20Guide_v1.9_508.pdf) organizes preparedness into planning, receiving a threat, assessment, response, and suspicious-item actions. It is written for site decision makers and stresses an orderly, controlled process coordinated with law enforcement and first responders. The guide describes risk levels based on the threat’s specificity, realism, feasibility, and immediacy, then presents response options such as assess and monitor, assess and search, search with partial or full lockdown, and evacuation. CISA cautions against automatic evacuation because a threat can be used to move people toward a device or other attack. When evacuation is selected, routes and assembly areas should be evaluated and kept away from a suspicious item. If a suspicious item is found, CISA says not to touch, tamper with, or move it; report it to decision makers and local law enforcement or first responders; secure and clear the area; and brief responders. The guide does not make an employee a bomb technician or guarantee that a checklist establishes credibility. Emergency responder direction and site-specific public-safety authority control the incident. ## DSE recommendation: prepare the decision structure and preserve the facts Write a bomb-threat management plan with law-enforcement, fire, emergency-management, facilities, security, communications, accessibility, and operational input. Identify a primary decision maker and alternates who can order protective actions. Give them building plans, occupancy information, critical operations, mobility needs, route options, assembly areas, and current responder contacts. - Train likely receivers. Reception, call centers, assistants, supervisors, and anyone monitoring public messages should know how to stay calm, preserve the exact wording, note time and source, capture available caller or message details, listen for background information without provoking the sender, and notify the established emergency path. Use CISA’s bomb-threat checklist at the point of work. - Protect original evidence. Preserve voicemail, email, envelope, social-media post, caller display, notes, and system timestamps. Limit forwarding or rewriting that loses headers or context. Do not ask staff to trace, confront, or investigate the sender. - Notify responders promptly. Follow local emergency-reporting instructions and provide the threat’s exact content, delivery method, time, named location or target, stated timing or device details, actions already taken, and a safe contact. Keep the designated liaison available as facts change. - Use authorized search teams. Preidentify people who know their ordinary work areas and can report something unusual under responder-approved procedures. Define search boundaries, communications, marking, accountability, and the immediate action for a suspicious item. Searching is not touching, opening, or moving property. - Select protective action deliberately. Consider the credible information, suspicious findings, threatened location, occupancy, routes, assembly areas, operational constraints, and responder advice. Prepare partial and full evacuation, lockdown, shelter, or continued monitoring options rather than forcing every incident into one alarm sequence. - Control evacuation and re-entry. Use routes and assembly points evaluated for the incident, account for occupants and visitors, maintain responder access, support people who need assistance, and prevent casual return. Name the authority that can approve re-entry and how that decision will be communicated. Exercise telephone, written, electronic, and suspicious-item scenarios separately. Observe whether the receiver captures facts, notification reaches the decision maker, responders receive accurate information, teams avoid the simulated item, alternate routes work, visitors are accounted for, and operations know when to stop or continue. Never place an object or conduct a surprise exercise that could trigger a real emergency response without authorization and coordination. After a threat, preserve the decision log, responder instructions, communications, accountability results, operational impacts, and corrective actions. Support affected employees and avoid public speculation. The objective is disciplined uncertainty management: reliable facts reach the right authority, people do not handle suspicious items, and protective movement occurs only through a route judged safer than remaining in place. ## Official references - Cybersecurity and Infrastructure Security Agency, Office for Bombing Prevention, [Bomb Threat Guide, Version 1](https://www.cisa.gov/sites/default/files/2023-08/Bomb%20Threat%20Guide_v1.9_508.pdf), August 2023. - CISA and the Federal Bureau of Investigation, [DHS-DOJ Bomb Threat Guidance Quad-Fold](https://www.cisa.gov/publication/dhs-doj-bomb-threat-guidance?collection=fact-sheets). ## Primary reference - Name: CISA Office for Bombing Prevention: Bomb Threat Guide, Version 1 - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/2023-08/Bomb%20Threat%20Guide_v1.9_508.pdf - Source publication date: 2023-08-01 ## Citation and use Preferred citation: “Prepare bomb-threat decisions before the call or message arrives,” DSE Security, https://update.dsesecurity.com/updates/prepare-bomb-threat-decisions-before-call-message-arrives/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prepare commercial buildings for wildfire smoke before air quality deteriorates > Build and test a site-specific smoke-readiness plan covering HVAC capability, filtration, air monitoring, cleaner-air space, supplies, and operating decisions. - Canonical URL: https://update.dsesecurity.com/updates/prepare-commercial-buildings-for-wildfire-smoke/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:17+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know Build and test a site-specific smoke-readiness plan covering HVAC capability, filtration, air monitoring, cleaner-air space, supplies, and operating decisions. ## Potentially affected Schools, public and commercial buildings, and multi-unit residential buildings in areas that may experience wildfire or prescribed-burn smoke ## DSE recommendation Have qualified facilities and indoor-air professionals prepare building-specific HVAC, filtration, monitoring, communications, and cleaner-air-space procedures before smoke arrives. ## Article Wildfire smoke can affect a building for days, and improvised HVAC changes can introduce other indoor-air, pressure, temperature, or equipment problems. A qualified, building-specific smoke-readiness plan should be prepared and exercised before outdoor air quality deteriorates. ## Source fact: [The U.S. Environmental Protection Agency’s commercial-building guidance](https://www.epa.gov/emergencies-iaq/wildfires-and-indoor-air-quality-schools-and-commercial-buildings) provides resources for reducing smoke concentrations in schools, public and commercial buildings, and multi-unit residential buildings. EPA identifies HVAC improvements, building adjustments, air sensors, and occupant behavior as key areas and points building managers to an example smoke-ready checklist. The EPA page summarizes a planning framework for buildings with air-handling systems that bring in outdoor air or recirculate indoor air. Elements include evaluating whether the HVAC system can safely use a higher-efficiency filter, completing maintenance, maintaining suitable airflow, considering supplemental intake filtration, tracking filter pressure drop, limiting smoke entry, observing indoor particulate trends, preparing temporary cleaner-air spaces, and reducing indoor particle sources. EPA notes that low-cost sensors can show trends but are not as accurate as regulatory monitors. ## Boundary The source provides planning guidance, not a universal indoor-air threshold, HVAC design, occupancy decision, or health determination for a particular building or person. Ventilation, filtration, pressure, cooling, fire and life safety, infection control, energy, code, lease, and manufacturer requirements can conflict if settings are changed without competent review. Smoke conditions, building leakage, equipment, occupancy, and local public-health direction differ. A cleaner-air space reduces exposure only to the extent demonstrated by the actual building and operation; it is not a guarantee of safe occupancy. ## Applicability questions - Which sites can experience smoke, and which current AirNow, state, tribal, or local authority provides operating information? - What outdoor-air, recirculation, exhaust, pressure, cooling, and filtration functions does each air-handling unit provide? - What filter efficiency and pressure drop can the installed equipment safely support under current manufacturer and professional guidance? - Where can indoor and outdoor particulate trends be observed, and what are the sensor limitations and maintenance needs? - Which occupants, essential functions, alternate sites, and public-health instructions affect closure or cleaner-air-space decisions? ## DSE recommendation: Assign facilities, safety, continuity, human resources, communications, and qualified HVAC or indoor-air professionals to create a plan for each materially different building. Inventory air-handling units, outdoor-air intakes, filters, controls, sensors, portable air cleaners, doors, windows, and likely indoor particle sources. Obtain a professional determination of supported filtration and operating modes rather than copying settings from another site. Define readiness work, activation triggers, authorized control changes, monitoring, filter inspection and replacement, cleaner-air-space capacity, supply levels, occupant communications, and return-to-normal steps. Procure compatible filters and other approved supplies before regional demand rises. Coordinate any ventilation reduction with temperature, pressure, indoor contaminant, code, and life-safety needs. Establish alternate-work or relocation decisions for conditions the building cannot manage. Exercise the procedure with simulated degraded outdoor air. Have operators change only approved settings, confirm control positions, observe indoor-versus-outdoor trends, open the cleaner-air space, notify occupants, and restore normal operation. Include a failed sensor, loaded filter, power interruption, and a staff handoff. ## Verification and evidence Keep the site plan, professional HVAC assessment, equipment and filter specifications, approved control settings, sensor locations and limitations, maintenance records, supply inventory, communication templates, exercise readings, decisions, and corrective actions. During a real event, retain authoritative outdoor-air information, indoor trend data, filter and pressure observations, setting changes, occupancy decisions, and restoration checks. Revisit the plan after HVAC work, building-envelope changes, sensor replacement, or lessons from a smoke event. ## Official references - [EPA: Wildfires and Indoor Air Quality in Schools and Commercial Buildings](https://www.epa.gov/emergencies-iaq/wildfires-and-indoor-air-quality-schools-and-commercial-buildings) - [AirNow Fire and Smoke Map](https://fire.airnow.gov/) ## Primary reference - Name: Wildfires and Indoor Air Quality in Schools and Commercial Buildings - Authority: www.epa.gov - URL: https://www.epa.gov/emergencies-iaq/wildfires-and-indoor-air-quality-schools-and-commercial-buildings - Source publication date: 2026-08-20 ## Citation and use Preferred citation: “Prepare commercial buildings for wildfire smoke before air quality deteriorates,” DSE Security, https://update.dsesecurity.com/updates/prepare-commercial-buildings-for-wildfire-smoke/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prepare federation certificate names before a Work Folders lab becomes production > Which certificate planning decisions should precede the Work Folders AD FS setup example? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-059-prepare-federation-certificate-names-before-a-work-folders-lab-becomes-production/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:12+00:00 - Modified: 2026-09-08T18:20:21+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know Which certificate planning decisions should precede the Work Folders AD FS setup example? ## Potentially affected Use this review when planning the federation endpoint for the documented Work Folders design. ## DSE recommendation Create a certificate-name worksheet before requesting issuance. ## Article ## Source facts Microsoft’s Work Folders walkthrough starts by preparing AD FS before the later proxy and client stages. The walkthrough distinguishes its self-signed test certificate from the publicly trusted certificate recommended for production. Its certificate example includes names for the federation service, enterprise registration, and federation server. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/work-folders/deploy-work-folders-adfs-step1). ## Applicability Use this review when planning the federation endpoint for the documented Work Folders design. Identify the real service names and certificate authority. Check the procedure’s release-specific limits before adapting any historical lab instruction. ## DSE recommendation Create a certificate-name worksheet before requesting issuance. Have the federation and certificate owners confirm which names the planned service requires and who will maintain the certificate. Keep lab identities and trust decisions visibly separate from the production request. Allow time for issuance and validation, and avoid copying sample hostnames into the deployment record. ## Verification Inspect the issued certificate against the approved name worksheet and trust arrangement. Verify the intended federation endpoint through an authorized test before moving to later Work Folders stages. Record the certificate identity, responsible owner, and any name mismatch. Resolve the mismatch through the approved certificate process before publishing the service to clients. ## Official references [Microsoft Learn: Deploy Work Folders with AD FS and Web Application Proxy – Step 1, Set Up AD FS](https://learn.microsoft.com/en-us/windows-server/storage/work-folders/deploy-work-folders-adfs-step1). Source reviewed September 8, 2026. ## Primary reference - Name: Deploy Work Folders with AD FS and Web Application Proxy - Step 1, Set Up AD FS - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/work-folders/deploy-work-folders-adfs-step1 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prepare federation certificate names before a Work Folders lab becomes production,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-059-prepare-federation-certificate-names-before-a-work-folders-lab-becomes-production/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prepare for DDoS before availability becomes an incident > DDoS readiness requires prioritized public services, provider coverage and emergency contacts, observable baselines, upstream mitigation, exercised decisions, and validated recovery. - Canonical URL: https://update.dsesecurity.com/updates/ddos-readiness-response-playbook/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:10+00:00 - Modified: 2026-07-19T21:27:10+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know DDoS readiness requires prioritized public services, provider coverage and emergency contacts, observable baselines, upstream mitigation, exercised decisions, and validated recovery. ## Potentially affected Organizations relying on public websites, APIs, remote access, DNS, email, voice, messaging, cloud services, internet circuits, hosting providers, CDNs, or other externally reachable services. ## DSE recommendation Rank public services, document dependencies and provider defenses, baseline traffic, define and exercise response, preserve evidence, and correct coverage or architecture gaps. ## Article A large distributed denial-of-service attack can exceed controls at the target because the unwanted traffic has already consumed an upstream resource. Preparation therefore depends on service priorities, architecture, providers, communication, and rehearsed decisions—not only a firewall rule created during the outage. ## Prepare with providers before the event Source fact: CISA, FBI, and MS-ISAC recommend identifying critical externally available assets and services and reviewing the organizational impact of their loss. Organizations should understand DDoS protections and coverage gaps offered by internet, cloud, hosting, content-delivery, and mitigation providers before an attack. Source fact: High availability, load balancing, colocation, and removal of single points of failure can improve continuity. The guidance also explains that large attacks may need to be stopped or diverted through upstream provider or specialized DDoS defenses before traffic reaches the local environment. Source fact: A response plan should cover attack identification and confirmation, mitigation, monitoring, recovery, roles, communication, and provider coordination. Possible indicators include sudden traffic increases, latency, service unavailability, and degraded communications, but monitoring and traffic analysis are needed to distinguish an attack from other failures. ## Build a service-specific playbook DSE recommendation: rank each public service using safety, operational, financial, legal, customer, and reputational impact. Diagram its DNS, address space, protocols, authentication, application dependencies, provider paths, capacity, regions, failover, and single points of failure. - Record ISP, cloud, hosting, CDN, DNS, application, security-provider, leadership, communications, and law-enforcement contacts appropriate to the organization. - Document contracted protections, exclusions, protected addresses and protocols, activation method, authorization, expected telemetry, evidence needs, and support escalation. - Baseline normal traffic, latency, error, resource, and availability patterns and define criteria for confirmation and incident declaration. - Preapprove bounded filtering, rate limits, traffic diversion, scaling, alternate communication, and business-continuity options where technically appropriate. - Define evidence collection, status updates, recovery validation, and after-action review. ## Exercise the real coordination path DSE recommendation: run a tabletop with providers and a safe technical validation where contracts and architecture permit. Confirm who can activate mitigation, make DNS or routing changes, accept user impact, communicate externally, and declare recovery. Verify contacts outside the affected network and preserve configuration, traffic summaries, timestamps, alerts, logs, and provider records. ## Applicability and limits DDoS attacks vary by volume, protocol, reflection method, and application behavior. Rate limits or blocking can harm legitimate users, local capacity may not absorb an upstream attack, and a CDN may not cover every protocol or origin. The publication is general guidance, not a guarantee. Current provider architecture and contract terms determine available actions. ## Official reference [Understanding and Responding to Distributed Denial-of-Service Attacks](https://www.cisa.gov/sites/default/files/2024-03/understanding-and-responding-to-distributed-denial-of-service-attacks_508c.pdf) — joint preparedness and response guidance. ## Primary reference - Name: CISA, FBI, and MS-ISAC: Understanding and Responding to Distributed Denial-of-Service Attacks - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/2024-03/understanding-and-responding-to-distributed-denial-of-service-attacks_508c.pdf - Source publication date: 2024-03-21 ## Citation and use Preferred citation: “Prepare for DDoS before availability becomes an incident,” DSE Security, https://update.dsesecurity.com/updates/ddos-readiness-response-playbook/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prepare the restart and feature checks for a Secured-core server change > What should accompany enabling Secured-core features through Windows Admin Center? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-011-prepare-the-restart-and-feature-checks-for-a-secured-core-server-change/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:17:00+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What should accompany enabling Secured-core features through Windows Admin Center? ## Potentially affected Use this review when planning a Secured-core configuration change on Windows Server. ## DSE recommendation Have the server and hardware owners jointly review readiness. ## Article ## Source facts Secured-core combines security capabilities across hardware, firmware, drivers, and the operating system. Microsoft lists requirements including Secure Boot, TPM 2.0, relevant firmware protections, and processor virtualization capabilities. In Windows Admin Center, the documented workflow enables unconfigured security features and schedules a restart to retain the changes. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/security/configure-secured-core-server). ## Applicability Use this review when planning a Secured-core configuration change on Windows Server. Check the exact hardware and firmware prerequisites in the current documentation. Identify the server workload and its permitted restart window before enabling features. ## DSE recommendation Have the server and hardware owners jointly review readiness. Record which features are already configured and which will change, including any prerequisite that remains unresolved. Coordinate the restart with the workload owner and preserve a supported recovery route. Pilot the change on an appropriate representative server, with named reviewers for hardware status and application acceptance. ## Verification After the planned restart, compare feature states with the approved change record. Examine reported device problems and test the workload functions selected in advance. Record the actual restart and acceptance times. Treat a feature that remains unconfigured or a workload failure as an open result requiring investigation before expanding the rollout. ## Official references [Microsoft Learn: Configure Secured-core server for Windows Server](https://learn.microsoft.com/en-us/windows-server/security/configure-secured-core-server). Source reviewed September 8, 2026. ## Primary reference - Name: Configure Secured-core server for Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/configure-secured-core-server - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prepare the restart and feature checks for a Secured-core server change,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-011-prepare-the-restart-and-feature-checks-for-a-secured-core-server-change/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prepare users for file transfer and printing in the RDS web client > Which file-transfer and printing behaviors should an RDS web-client pilot verify? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-095-prepare-users-for-file-transfer-and-printing-in-the-rds-web-client/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:36+00:00 - Modified: 2026-09-08T18:20:22+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which file-transfer and printing behaviors should an RDS web-client pilot verify? ## Potentially affected Support teams evaluating the browser-based Remote Desktop Services client. ## DSE recommendation Write a short user procedure covering the approved upload route, text clipboard use, and handling of generated PDFs. ## Article ## Source facts Microsoft’s RDS web client provides browser access to published remote applications and desktops. Its documented clipboard support is text-only; files are not copied between the local and remote environments through copy and paste. The upload control places selected files in the remote virtual drive’s Uploads folder. Selecting Remote Desktop Virtual Printer produces a PDF in the browser, which can then be saved or printed locally. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-web-client). ## Applicability Review the supported browser and device requirements, the published resources, and the organization’s data-handling rules. Select representative users whose work includes the intended file and print tasks rather than testing sign-in alone. ## DSE recommendation Write a short user procedure covering the approved upload route, text clipboard use, and handling of generated PDFs. Ask the data owner which local downloads or printouts are acceptable. Include a support contact and a clear description of where uploaded files should appear. ## Verification Pilot an upload, a text paste, and a representative print job using non-sensitive files. Confirm the destination of the upload and PDF and ask the user to complete the actual workflow. Record any blocked step or unexpected local copy before approving the browser client for that work. ## Official references [Microsoft Learn: Get started with the web client for Remote Desktop Services](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-web-client). Source reviewed September 8, 2026. ## Primary reference - Name: Get started with the web client for Remote Desktop Services - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-web-client - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prepare users for file transfer and printing in the RDS web client,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-095-prepare-users-for-file-transfer-and-printing-in-the-rds-web-client/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preplan hazardous-substance emergency response by role and hazard > Use 29 CFR 1910.120 - Hazardous waste operations and emergency response to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/preplan-hazardous-substance-emergency-response-by-role-and-hazard/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:27+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.120 - Hazardous waste operations and emergency response to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.120 - Hazardous waste operations and emergency response ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Preplan hazardous-substance emergency response by role and hazard. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.120 – Hazardous waste operations and emergency response](https://www.ecfr.gov/current/title-29/section-1910.120) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, hazardous materials technicians must have received at least 24 hours of training equal to the first responder operations level and in addition have competency in the following areas and the employer must so certify: be able to function within an assigned role in the Incident Command System. The research record locates this support at 29 CFR 1910.120(q)(6)(iii)(C), read with 29 CFR 1910.120(q)(6)(iii) (eCFR anchor p-1910.120(q)(6)(iii)(C)). - Under 29 CFR 1910, any emergency response employee who exhibits signs or symptoms which may have resulted from exposure to hazardous substances during the course of an emergency incident, either immediately or subsequently, must be provided with medical consultation as required in paragraph (f)(3)(ii) of this section. The research record locates this support at 29 CFR 1910.120(q)(9)(ii) (eCFR anchor p-1910.120(q)(9)(ii)). Keep the evidence boundary at these traced claims. They support a review of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Federal workplace rule; response scope, employee role, incidental releases, other agencies, and substance-specific standards determine applicability. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.120(q)(6)(iii)(C), read with 29 CFR 1910.120(q)(6)(iii) (eCFR anchor p-1910.120(q)(6)(iii)(C)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.120(q)(9)(ii) (eCFR anchor p-1910.120(q)(9)(ii)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to 29 CFR 1910.120(q)(6)(iii)(C), read with 29 CFR 1910.120(q)(6)(iii) (eCFR anchor p-1910.120(q)(6)(iii)(C)); 29 CFR 1910.120(q)(9)(ii) (eCFR anchor p-1910.120(q)(9)(ii)) and to observable material such as business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [29 CFR 1910.120 – Hazardous waste operations and emergency response](https://www.ecfr.gov/current/title-29/section-1910.120) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.120 - Hazardous waste operations and emergency response - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.120 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preplan hazardous-substance emergency response by role and hazard,” DSE Security, https://update.dsesecurity.com/updates/preplan-hazardous-substance-emergency-response-by-role-and-hazard/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prequalify critical circuits for CISA Telecommunications Service Priority > Determine whether eligible national security and emergency preparedness circuits should receive priority installation or restoration treatment before an outage. - Canonical URL: https://update.dsesecurity.com/updates/prequalify-critical-circuits-for-cisa-tsp/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:33+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Briefing - DSE priority: Important - Topics: Business Continuity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Determine whether eligible national security and emergency preparedness circuits should receive priority installation or restoration treatment before an outage. ## Potentially affected Eligible organizations whose national security or emergency preparedness functions depend on qualifying telecommunications services ## DSE recommendation Map critical circuits to qualifying functions, engage CISA and carriers in advance, and keep service records current and available offline. ## Article If a qualifying emergency function depends on a carrier circuit, priority treatment must be arranged before the disruption. A circuit inventory assembled during an outage is too late for normal eligibility, assignment, and carrier coordination work. ## Source fact: [CISA’s Telecommunications Service Priority overview](https://www.cisa.gov/sites/default/files/2023-09/Telecommunications%20Service%20Priority_Overview.pdf) describes a federal program through which eligible national security and emergency preparedness users can receive priority treatment for qualifying telecommunications services. TSP supports priority installation of new services and priority restoration of existing services. Approved assignments are implemented with the telecommunications provider for the identified service. The program serves both emergency and nonemergency needs under its rules. It applies to specific qualifying telecommunications services and functions; it is not a blanket priority label for every circuit an organization buys. Priority means eligible work receives precedence according to the program—it does not promise uninterrupted service, immediate repair, a particular restoration time, or carrier capacity where the underlying infrastructure is unavailable. ## Boundary Eligibility and assignment are determined through the official program, not by this article. Organizations must consult CISA and their service providers for current requirements, charges, renewal, and ordering processes. TSP does not replace diverse routing, backup communications, local power, equipment spares, carrier escalation, or application continuity. A carrier account name or “critical infrastructure” description alone does not establish that a service qualifies. ## Applicability questions - Which documented national security or emergency preparedness function would stop if the service failed? - What exact carrier service, circuit identifier, demarcation, location, and account support that function? - Is priority installation, restoration, or both the relevant need? - Does the service traverse shared local facilities whose loss would still affect multiple supposedly diverse circuits? - Who owns CISA coordination, carrier orders, renewal, and annual inventory review? ## DSE recommendation: Start with the continuity plan’s essential functions and trace each one to named telecommunications dependencies. Reconcile provider invoices, contracts, network diagrams, circuit IDs, service addresses, demarcations, and escalation contacts. Ask CISA whether the organizational function and service are eligible, and follow the current official process. Coordinate with the carrier so the assignment is attached to the correct service record and order. Keep a controlled register of assignments, authorization details, provider acknowledgments, renewal dates, service changes, and contacts. Require network changes, relocations, renewals, and carrier migrations to trigger a TSP review. Maintain an offline copy for incident leadership. Exercise carrier escalation using a tabletop scenario and verify that staff know how to identify the protected service without exposing sensitive program details unnecessarily. ## Verification and evidence Retain eligibility and assignment correspondence, accurate circuit records, carrier confirmation, invoices where relevant, renewal evidence, and exercise notes. Verify identifiers directly against provider records and the physical demarcation. A continuity test should also demonstrate an alternate communications path because a valid TSP assignment cannot by itself prove that the service will remain or be restored within the business recovery objective. ## Official references - [CISA Telecommunications Service Priority overview](https://www.cisa.gov/sites/default/files/2023-09/Telecommunications%20Service%20Priority_Overview.pdf) ## Primary reference - Name: Telecommunications Service Priority Overview - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/2023-09/Telecommunications%20Service%20Priority_Overview.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prequalify critical circuits for CISA Telecommunications Service Priority,” DSE Security, https://update.dsesecurity.com/updates/prequalify-critical-circuits-for-cisa-tsp/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preselect a backup employee-warning method for alarm outages > Use 29 CFR 1910.165 - Employee alarm systems to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/preselect-a-backup-employee-warning-method-for-alarm-outages/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:18+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.165 - Employee alarm systems to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.165 - Employee alarm systems ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Preselect a backup employee-warning method for alarm outages. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.165 – Employee alarm systems](https://www.ecfr.gov/current/title-29/section-1910.165) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, the rule requires that the employer explain to each employee the preferred means of reporting emergencies, such as manual pull box alarms, public address systems, radio or telephones. The research record locates this support at 29 CFR 1910.165(b)(4) (eCFR anchor p-1910.165(b)(4)). - Under 29 CFR 1910, the rule requires that the employer maintain or replace power supplies as often as is necessary to assure a fully operational condition. The research record locates this support at 29 CFR 1910.165(d)(3) (eCFR anchor p-1910.165(d)(3)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives and the conditions the source actually describes. ## What the source does not establish Federal workplace rule; a backup warning method still needs site-specific staffing, coverage, accessibility, testing, and coordination with emergency plans and applicable fire codes. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.165(b)(4) (eCFR anchor p-1910.165(b)(4)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.165(d)(3) (eCFR anchor p-1910.165(d)(3)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from 29 CFR 1910.165(b)(4) (eCFR anchor p-1910.165(b)(4)); 29 CFR 1910.165(d)(3) (eCFR anchor p-1910.165(d)(3)) to the observed environment. Useful domain evidence includes business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [29 CFR 1910.165 – Employee alarm systems](https://www.ecfr.gov/current/title-29/section-1910.165) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.165 - Employee alarm systems - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.165 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preselect a backup employee-warning method for alarm outages,” DSE Security, https://update.dsesecurity.com/updates/preselect-a-backup-employee-warning-method-for-alarm-outages/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve an incident scene before ordinary operations erase the evidence > Security personnel should protect life, summon authorities, establish a controlled boundary, prevent avoidable disturbance, identify witnesses, and document their own actions without attempting an untrained crime-scene examination. - Canonical URL: https://update.dsesecurity.com/updates/preserve-incident-scene-before-operations-erase-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:24:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Business Continuity - Reading time: 3 minutes ## What you need to know Security personnel should protect life, summon authorities, establish a controlled boundary, prevent avoidable disturbance, identify witnesses, and document their own actions without attempting an untrained crime-scene examination. ## Potentially affected Security officers, reception, facilities, supervisors, incident commanders, access logs, physical barriers, witness separation, found property, damaged doors, assault or theft locations, responder access, cleanup, repair, and return-to-service decisions. ## DSE recommendation Define first-arrival priorities and authority, establish inner and outer boundaries, limit and log entry, preserve transient conditions and witnesses, avoid handling items, coordinate urgent safety work, transfer control to law enforcement, and document formal release. ## Article ## Source facts: initial responders protect life and control the scene The U.S. Department of Justice’s [Crime Scene Investigation: A Guide for Law Enforcement](https://www.ojp.gov/library/publications/crime-scene-investigation-guide-law-enforcement) organizes scene work from initial response and prioritization through documentation, processing, completion, and evidence submission. Its initial-response principles put safety first, call for control of people and movement, and emphasize preventing contamination or loss while qualified investigators are summoned. The guide describes scene boundaries, entry control, documentation of people and actions, witness management, and communication with investigative personnel. It recognizes that urgent medical aid and hazard control can change a scene; those changes should be limited to what is necessary and communicated. Protection of evidence begins before an evidence technician arrives. The DOJ guide is intended for law enforcement. It does not grant private security personnel search, seizure, detention, evidence-collection, or investigative authority. Applicable law, property rights, employer policy, licensing, collective bargaining, insurer requirements, and law-enforcement direction govern a private organization. Security personnel should remain within training and authority. ## DSE recommendation: stabilize, protect, record, and transfer Write a first-arrival procedure for events that may become investigative scenes: assault, burglary, robbery, suspicious death or serious injury, major vandalism, forced door, weapon report, arson indication, or unexplained high-value loss. Give personnel a 24-hour escalation path and criteria for calling emergency services immediately. - Protect life and identify hazards. Call 911, provide aid within training, and address an active threat, fire, gas, electrical, structural, traffic, or environmental danger. Do not delay lifesaving action to preserve an object. Note what was moved, opened, shut down, cut, or removed and why. - Establish boundaries early. Begin wider than the obvious damage and adjust under authority. Use an inner boundary around the likely scene and an outer boundary for safe coordination, witnesses, media or public separation, and responder staging. Preserve entrance and exit paths for emergency personnel. - Control and log entry. Stop routine cleaning, repairs, deliveries, tours, and management walk-throughs. Record each person entering, time in and out, purpose, and authorizer. Essential fire, medical, utility, or safety work takes priority, but unnecessary observation does not. - Leave items and conditions alone. Do not pick up, unload, wipe, mark, smell, test, reassemble, search, or package an item unless immediate safety or authorized instruction requires it. Protect transient conditions such as weather exposure, footprints, tire marks, doors, lights, odors, temperature, or running equipment without contaminating them. - Identify people without conducting interrogations. Obtain names, safe contact information, location, and basic immediate observations. Keep witnesses from coordinating accounts when lawful and practical, provide care, and ask them to remain available for police. Record spontaneous statements accurately without leading questions. - Transfer deliberately. Brief the arriving authority on hazards, medical actions, boundaries, entries, changes, witnesses, available access records, and preserved systems. Confirm who controls the scene and who may authorize cleanup, repair, employee reentry, credential changes, or business reopening. Secure relevant routine records against automatic loss under the approved legal process: access events, alarm logs, guard reports, visitor records, work orders, delivery records, and communications. Do not alter original records, create speculative annotations, or circulate sensitive material. Preserve integrity and document who collected each authorized copy. Train with tabletop maps and ordinary props, never a surprise realistic crime scene. Test night shift, severe weather, injured persons, a manager demanding entry, essential equipment inside the boundary, and delayed police arrival. After release, photograph authorized conditions, retain the release record, complete repairs, support affected people, and review control failures. Good scene preservation is disciplined restraint: do what safety requires, keep others out, record what changed, and let the lawful investigator direct what comes next. ## Official references - U.S. Department of Justice, Office of Justice Programs, [Crime Scene Investigation: A Guide for Law Enforcement](https://www.ojp.gov/library/publications/crime-scene-investigation-guide-law-enforcement), September 2013. - National Institute of Justice, [Crime Scene Investigation: A Guide for Law Enforcement](https://www.ojp.gov/pdffiles1/nij/178280.pdf), original technical working group guide. ## Primary reference - Name: U.S. Department of Justice: Crime Scene Investigation—A Guide for Law Enforcement - Authority: www.ojp.gov - URL: https://www.ojp.gov/library/publications/crime-scene-investigation-guide-law-enforcement - Source publication date: 2013-09-01 ## Citation and use Preferred citation: “Preserve an incident scene before ordinary operations erase the evidence,” DSE Security, https://update.dsesecurity.com/updates/preserve-incident-scene-before-operations-erase-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve ATA investigation data and document exclusions before migration > Use Migrate from Advanced Threat Analytics to Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/preserve-ata-investigation-data-document-exclusions-before-migration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:05+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Migrate from Advanced Threat Analytics to Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Migrate from Advanced Threat Analytics to Microsoft Defender for Identity ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Preserve ATA investigation data and document exclusions before migration. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Migrate from Advanced Threat Analytics to Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/migrate-from-ata-overview) from Microsoft supports the following bounded statements: - ATA data is not migrated to Defender for Identity, so Microsoft recommends retaining the ATA Data Center and alerts needed for ongoing investigations until those alerts are closed or remediated. The research record locates this support at Migration comparison > Important note before Prerequisites. - ATA alert exclusions are not transferable; their details must be collected so the exclusions can be recreated in Microsoft Defender. The research record locates this support at Plan your migration > Alert exclusions. - The ATA Center must remain installed until all ATA Gateways are removed because removing the center while gateways still run leaves no threat protection. The research record locates this support at Plan your migration > Caution. Only the traced statements above are asserted as source facts. Apply the review to Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health after confirming that the source and deployed context match. ## What the source does not establish This migration guide covers Defender for Identity sensors, not standalone sensors; preserve evidence and verify current product support rather than treating migration as an in-place data transfer. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Migration comparison > Important note before Prerequisites, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Plan your migration > Alert exclusions, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Plan your migration > Caution, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health are in and out of scope? - Which condition in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations Migration comparison > Important note before Prerequisites; Plan your migration > Alert exclusions; Plan your migration > Caution adjacent to the sanitized artifacts used for comparison. Prefer sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Migrate from Advanced Threat Analytics to Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/migrate-from-ata-overview) — Microsoft ## Primary reference - Name: Migrate from Advanced Threat Analytics to Microsoft Defender for Identity - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/migrate-from-ata-overview - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Preserve ATA investigation data and document exclusions before migration,” DSE Security, https://update.dsesecurity.com/updates/preserve-ata-investigation-data-document-exclusions-before-migration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve community mental health services through disruption > Use 42 CFR 485.727 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/preserve-community-mental-health-services-through-disruption/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:58+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 485.727 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 485.727 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Preserve community mental health services through disruption. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 485.727 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-485.727) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 485, the rule requires that if elected, the unified and integrated emergency preparedness program do all of the following: include integrated policies and procedures that meet the requirements set forth in paragraph (b) of this section, a coordinated communication plan and training and testing programs that meet the requirements of paragraphs (c) and (d) of this section, respectively. The research record locates this support at 42 CFR 485.727(e)(5), read with 42 CFR 485.727(e) (eCFR anchor p-485.727(e)(5)). - Under 42 CFR 485, the rule requires that covered organizations develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 485.727(d) (eCFR anchor p-485.727(d)). The source support ends with the statements listed above. Use them to examine essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives in the applicable environment, not to imply a wider guarantee. ## What the source does not establish CMHC-specific federal condition; crisis services, clients, community partners, records, staffing, state requirements, and survey guidance require local planning. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 485.727(e)(5), read with 42 CFR 485.727(e) (eCFR anchor p-485.727(e)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 485.727(d) (eCFR anchor p-485.727(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 42 CFR 485.727(e)(5), read with 42 CFR 485.727(e) (eCFR anchor p-485.727(e)(5)); 42 CFR 485.727(d) (eCFR anchor p-485.727(d)). Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [42 CFR 485.727 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-485.727) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 485.727 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-485.727 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve community mental health services through disruption,” DSE Security, https://update.dsesecurity.com/updates/preserve-community-mental-health-services-through-disruption/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve file state when changing a redirected-folder server path > What should be verified before using an optimized move for redirected folders? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-099-preserve-file-state-when-changing-a-redirected-folder-server-path/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:32+00:00 - Modified: 2026-09-08T18:20:23+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know What should be verified before using an optimized move for redirected folders? ## Potentially affected Administrators moving Folder Redirection data to another file share. ## DSE recommendation Prepare a coordinated plan for the file transfer, policy setting, and target-path update. ## Article ## Source facts Microsoft’s optimized-move policy lets the client rename cached content in Offline Files when an administrator relocates the share and updates the redirected-folder target path. With that policy disabled or unconfigured, a server-path change causes the client to copy the redirected content to the new location and then remove it from the old location. The source warns that open files or failure to preserve the complete file state can cause conflicts, poor performance, or data loss. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/enable-optimized-moving). ## Applicability Review the existing Folder Redirection configuration, supported client versions, cache state, and proposed share migration. Identify how user activity will be coordinated and how file state will be preserved throughout the move. ## DSE recommendation Prepare a coordinated plan for the file transfer, policy setting, and target-path update. Ask the data owner to approve the source of truth and the period during which users should stop editing. Record the original paths and a recovery decision before changing policy. ## Verification Pilot the move with a representative user and a controlled file set. Compare files and metadata before and after the move, then inspect synchronization and sign-in behavior. Reconcile local edits and conflicts explicitly before accepting the new path; keep an unresolved cache discrepancy open rather than treating a successful sign-in as completion. ## Official references [Microsoft Learn: Enable optimized moves of redirected folders](https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/enable-optimized-moving). Source reviewed September 8, 2026. ## Primary reference - Name: Enable optimized moves of redirected folders - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/folder-redirection/enable-optimized-moving - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve file state when changing a redirected-folder server path,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-099-preserve-file-state-when-changing-a-redirected-folder-server-path/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve HGS signing and encryption keys through certificate renewal > What certificate-renewal constraint must be preserved for Host Guardian Service? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-121-preserve-hgs-signing-and-encryption-keys-through-certificate-renewal/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:10+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What certificate-renewal constraint must be preserved for Host Guardian Service? ## Potentially affected Administrators obtaining or renewing HGS signing and encryption certificates. ## DSE recommendation Prepare a renewal plan that explicitly preserves the required keys and identifies the authorized custodian. ## Article ## Source facts HGS uses signing and encryption certificates to protect the information needed to start shielded VMs. VM owners use the public certificate material to authorize the guarded environment. Microsoft recommends certificates from a trusted certification authority. The documentation also permits self-signed certificates for a lab environment. The HGS certificate requirements specify renewal with the same key. Microsoft warns that renewing with different keys prevents shielded VMs from starting. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-obtain-certs). ## Applicability Identify the certificate roles, current keys, issuing authority, expiration dates, and all HGS nodes. Review the source’s complete cryptographic requirements and the key-storage provider before ordering replacements. ## DSE recommendation Prepare a renewal plan that explicitly preserves the required keys and identifies the authorized custodian. Have the guarded-fabric owner review how renewal differs from an intentional key-change project. Schedule a representative startup test and retain the approved recovery material before replacing certificates. ## Verification Inspect the renewed certificates and confirm the intended key relationship and deployment on the required nodes. Start a representative shielded VM through the approved guarded-host path and record HGS results. Treat an unexplained key change or startup failure as unresolved before completing the renewal. ## Official references [Microsoft Learn: Obtain certificates for HGS](https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-obtain-certs). Source reviewed September 8, 2026. ## Primary reference - Name: Obtain certificates for HGS - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-obtain-certs - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve HGS signing and encryption keys through certificate renewal,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-121-preserve-hgs-signing-and-encryption-keys-through-certificate-renewal/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve internationalized addresses in delivery and disposition reports > Use RFC 6533 — Internationalized Delivery Status and Disposition Notifications to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:54+00:00 - Modified: 2026-08-27T12:36:15+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 6533 — Internationalized Delivery Status and Disposition Notifications to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 6533 — Internationalized Delivery Status and Disposition Notifications ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Preserve internationalized addresses in delivery and disposition reports. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 6533 — Internationalized Delivery Status and Disposition Notifications](https://www.rfc-editor.org/rfc/rfc6533.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - The UTF-8 address type has native, unitext, and ASCII-safe xtext forms; native UTF-8 cannot be used through a server that lacks SMTPUTF8. The research record locates this support at Section 3 (UTF-8 Address Type). - A message/global-delivery-status part uses UTF-8 and should preserve non-ASCII recipient addresses in the native UTF-8 address form. The research record locates this support at Section 4.1 (The message/global-delivery-status Media Type). - A UTF-8 message disposition notification uses message/global-disposition-notification and converts an encoded ORCPT original recipient back to its UTF-8 address form. The research record locates this support at Section 5 (UTF-8 Message Disposition Notifications). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 3 (UTF-8 Address Type), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4.1 (The message/global-delivery-status Media Type), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5 (UTF-8 Message Disposition Notifications), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to Section 3 (UTF-8 Address Type); Section 4.1 (The message/global-delivery-status Media Type); Section 5 (UTF-8 Message Disposition Notifications) and to observable material such as sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 6533 — Internationalized Delivery Status and Disposition Notifications](https://www.rfc-editor.org/rfc/rfc6533.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 6533 — Internationalized Delivery Status and Disposition Notifications - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc6533.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve internationalized addresses in delivery and disposition reports,” DSE Security, https://update.dsesecurity.com/updates/preserve-internationalized-addresses-in-delivery-and-disposition-reports/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve long NPS expressions outside the console editor > How can an NPS expression longer than 256 characters be maintained without invalidating it? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-050-preserve-long-nps-expressions-outside-the-console-editor/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:16:21+00:00 - Modified: 2026-09-08T18:17:14+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know How can an NPS expression longer than 256 characters be maintained without invalidating it? ## Potentially affected Use this review when an approved NPS expression approaches or exceeds the graphical editor limit. ## DSE recommendation Keep the approved expression in a controlled change record and choose the documented command-based route when required. ## Article ## Source facts NPS supports regular expressions for network-policy attribute conditions and RADIUS realms. NPS console and MMC string fields have a 256-character entry limit, including regular-expression settings. Microsoft directs administrators to NETSH NPS commands for longer values. Editing an already configured longer value through those graphical tools invalidates it. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-crp-reg-expressions). ## Applicability Use this review when an approved NPS expression approaches or exceeds the graphical editor limit. Identify the exact policy field, current expression, character count, and intended maintenance interface before changing the value. ## DSE recommendation Keep the approved expression in a controlled change record and choose the documented command-based route when required. Have another administrator compare the complete proposed value with that record. Review escaping, anchors, and the expected matches against the source syntax reference. Document that later graphical editing is excluded for this long-value configuration. ## Verification Inspect the configured value after the approved change and compare it character for character with the reviewed expression. Run representative matching and nonmatching inputs without altering the intended authentication design. Preserve the command, sanitized observations, and full expression for the next operator. Resolve truncation or unexpected modification before accepting the change. ## Official references [Microsoft Learn: Use Regular Expressions in NPS](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-crp-reg-expressions). Source reviewed September 8, 2026. ## Primary reference - Name: Use Regular Expressions in NPS - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-crp-reg-expressions - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve long NPS expressions outside the console editor,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-050-preserve-long-nps-expressions-outside-the-console-editor/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve records of airport law-enforcement actions and response times > Use 49 CFR 1542.221 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/preserve-records-of-airport-law-enforcement-actions-and-response-times/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:24+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.221 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.221 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Preserve records of airport law-enforcement actions and response times. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.221 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.221) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, the rule requires that each airport operator ensure that a record is made of each law enforcement action taken in furtherance of this part. The research record locates this support at 49 CFR 1542.221(a)(1), read with 49 CFR 1542.221(a) (eCFR anchor p-1542.221(a)(1)). - Under 49 CFR 1542, the rule requires that data developed in response to paragraph (a) of this section include at least the following, except as authorized by TSA: the number of bomb threats received, real and simulated bombs found, and actual detonations on the airport. The research record locates this support at 49 CFR 1542.221(b)(3), read with 49 CFR 1542.221(b) (eCFR anchor p-1542.221(b)(3)). Keep the evidence boundary at these traced claims. They support a review of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 49 CFR 1542.221(a)(1), read with 49 CFR 1542.221(a) (eCFR anchor p-1542.221(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.221(b)(3), read with 49 CFR 1542.221(b) (eCFR anchor p-1542.221(b)(3)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 49 CFR 1542.221(a)(1), read with 49 CFR 1542.221(a) (eCFR anchor p-1542.221(a)(1)); 49 CFR 1542.221(b)(3), read with 49 CFR 1542.221(b) (eCFR anchor p-1542.221(b)(3)). Favor asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, linked to stable identifiers, time, and operator. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [49 CFR 1542.221 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.221) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.221 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.221 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve records of airport law-enforcement actions and response times,” DSE Security, https://update.dsesecurity.com/updates/preserve-records-of-airport-law-enforcement-actions-and-response-times/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve scene metadata as a separately verified evidence track > Scene metadata can support search, alerts, and trends, but it has its own generation, transport, retention, and export path. Verify that path independently from video. - Canonical URL: https://update.dsesecurity.com/updates/preserve-scene-metadata-as-a-separately-verified-evidence-track/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:56+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, Video Surveillance - Reading time: 2 minutes ## What you need to know Scene metadata can support search, alerts, and trends, but it has its own generation, transport, retention, and export path. Verify that path independently from video. ## Potentially affected Systems using object or scene metadata for forensic search, real-time analytics, dashboards, integrations, or evidence review. ## DSE recommendation Document metadata origin, schema, time basis, transport, retention, permissions, and export behavior, then test them against known events and the associated video. ## Article Bottom line: searchable metadata is not simply part of the picture. It is data generated by a component, transported and indexed by systems, and queried under particular definitions. Losing or misaligning that track can break search even when video remains available. ## Source fact: scene metadata describes image content for several uses Axis’s [Unlocking the power of scene metadata](https://whitepapers.axis.com/en-us/unlocking-the-power-of-scene-metadata) describes scene metadata as textual descriptions or attributes associated with video content. It explains that metadata can be generated in a camera or another component and used for forensic search, real-time applications, and trend analysis. It also links better image quality with better conditions for metadata generation. Each use creates a dependency. The same recorded video can produce different search results when model, configuration, schema mapping, index availability, or time alignment changes. ## Source boundary and applicability The vendor paper describes capabilities and use cases; it does not establish a universal schema, accuracy rate, legal conclusion, or interoperability result. A metadata label is an analytic output, not an independently verified fact. Product, model, scene, threshold, privacy configuration, VMS version, and integration determine behavior. ## Applicability questions - Which component produces each field, under which model and configuration? - How are object type, color, direction, zone, confidence, and time defined? - Does metadata follow every recorded stream, failover path, archive, and export? - Is its retention equal to, shorter than, or independent of video retention? - Who may query or export metadata, and can searches expose sensitive patterns? ## DSE recommendation: manage metadata as a versioned data product The following steps are DSE recommendations based on the cited source. Create a field-level register containing producer, model/version, definition, units or vocabulary, confidence handling, timestamp source, transport, index, retention, consumer, and access role. Run a labeled scene with known entries, exits, directions, objects, and times. Compare raw or exposed metadata, VMS search results, and archived video without treating analytic labels as conclusive. Test camera and server outage, time correction, failover recording, reindexing, export, archive restore, and model upgrade. Preserve prior definitions when a change would make historical searches non-comparable. Apply privacy and records review to metadata separately because it can reveal behavior at scale even when individual clips are not opened. Define a fallback search method for periods when the metadata index is missing, delayed, corrupt, or incompatible with the retained video. ## Verification and evidence Retain the field register, schema or product documentation, model and configuration export, labeled test script, search results, video comparison, timestamp measurements, retention and restore tests, role review, and change log. Record false positives and false negatives rather than reporting only successful searches. ## Official references - [Unlocking the power of scene metadata](https://whitepapers.axis.com/en-us/unlocking-the-power-of-scene-metadata) – Axis Communications ## Primary reference - Name: Unlocking the power of scene metadata - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/unlocking-the-power-of-scene-metadata - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve scene metadata as a separately verified evidence track,” DSE Security, https://update.dsesecurity.com/updates/preserve-scene-metadata-as-a-separately-verified-evidence-track/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve the current VM state before applying an older checkpoint > What choice is made when applying an earlier Hyper-V checkpoint? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-234-preserve-the-current-vm-state-before-applying-an-older-checkpoint/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:17+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What choice is made when applying an earlier Hyper-V checkpoint? ## Potentially affected Administrators applying Hyper-V virtual-machine checkpoints during an approved recovery or test. ## DSE recommendation Have the owner decide whether the present state must be preserved before the older checkpoint is applied. ## Article ## Source facts Microsoft describes checkpoints as saved VM states that can be used to return to an earlier point after a configuration change. Hyper-V Manager offers a choice to create a checkpoint of the current VM before applying the selected older checkpoint. The alternative Apply choice applies only the selected checkpoint, and the source warns that this action cannot be undone. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/checkpoints). ## Applicability Identify the exact VM, the checkpoint time, and the data-state change the application owner intends. Review the configured checkpoint type and workload requirements before proceeding. Keep returning to an earlier state separate from confirming that the earlier application data is acceptable. ## DSE recommendation Have the owner decide whether the present state must be preserved before the older checkpoint is applied. Record that decision alongside the selected checkpoint name and the reason it represents the desired point. Use identifiable checkpoint names and a representative pilot when designing the procedure. Agree on how newly created or modified application data will be assessed after the return. ## Verification Verify the selected state through the VM configuration and a workload-specific data check. Confirm that the current-state checkpoint exists when that option was required. Record the actual applied checkpoint and any unexpected data difference. Do not close the recovery solely because the VM starts; obtain the application owner’s acceptance of the restored state. ## Official references [Microsoft Learn: Using checkpoints](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/checkpoints). Source reviewed September 8, 2026. ## Primary reference - Name: Using checkpoints - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/checkpoints - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve the current VM state before applying an older checkpoint,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-234-preserve-the-current-vm-state-before-applying-an-older-checkpoint/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve the VM adapter identity before starting an SDN tenant workload > Which VM network-adapter identity must be established before an SDN-connected VM starts? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-130-preserve-the-vm-adapter-identity-before-starting-an-sdn-tenant-workload/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:01+00:00 - Modified: 2026-09-08T18:23:27+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which VM network-adapter identity must be established before an SDN-connected VM starts? ## Potentially affected Administrators attaching VMs to Microsoft SDN tenant networks or VLANs. ## DSE recommendation Prepare a binding record linking the VM adapter to its Network Controller interface and tenant network. ## Article ## Source facts Microsoft’s procedure attaches a tenant VM either to a virtualized tenant network or to a VLAN. The VM adapter requires a static MAC address for the VM’s lifetime. A MAC change prevents Network Controller from configuring the required adapter policy and stops network communication. For a VM needing connectivity at startup, the source instructs administrators to set the interface identifier on the adapter port before starting it. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Create-a-Tenant-VM). ## Applicability Identify the VM, adapter, controller interface resource, MAC address, target subnet, and startup dependencies. Replace the source’s sample identifiers with the approved values for this tenant. ## DSE recommendation Prepare a binding record linking the VM adapter to its Network Controller interface and tenant network. Have the platform and network owners review those identities before first boot. Define how the binding will be maintained if the VM is moved or its adapter is recreated. ## Verification Inspect the identities before startup, then test the intended tenant communication from the guest. Compare the observed policy association and network path with the binding record. Treat a changed MAC or missing interface resource as an unresolved configuration issue before allowing the application to depend on that connection. ## Official references [Microsoft Learn: Create a VM and connect to a tenant virtual network or VLAN](https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Create-a-Tenant-VM). Source reviewed September 8, 2026. ## Primary reference - Name: Create a VM and connect to a tenant virtual network or VLAN - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/sdn/manage/Create-a-Tenant-VM - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve the VM adapter identity before starting an SDN tenant workload,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-130-preserve-the-vm-adapter-identity-before-starting-an-sdn-tenant-workload/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve tribal authority and participation throughout mitigation planning > Use 44 CFR 201.7 - Tribal Mitigation Plans to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/preserve-tribal-authority-and-participation-throughout-mitigation-planning/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:23+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 44 CFR 201.7 - Tribal Mitigation Plans to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 44 CFR 201.7 - Tribal Mitigation Plans ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Preserve tribal authority and participation throughout mitigation planning. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [44 CFR 201.7 – Tribal Mitigation Plans](https://www.ecfr.gov/current/title-44/section-201.7) from Federal Emergency Management Agency via eCFR supports the following bounded statements: - Under 44 CFR 201, the rule requires that indian Tribal governments review and revise their plan to reflect changes in development, progress in local mitigation efforts, and changes in priorities, and resubmit it for approval within 5 years in order to continue to be eligible for non-emergency Stafford Act assistance and FEMA mitigation grant funding. The research record locates this support at 44 CFR 201.7(d)(3) (eCFR anchor p-201.7(d)(3)). - Under 44 CFR 201, the rule requires that indian Tribal governments applying to FEMA as a recipient have an approved Tribal Mitigation Plan meeting the requirements of this section as a condition of receiving non-emergency Stafford Act assistance and FEMA mitigation grants. The research record locates this support at 44 CFR 201.7(a)(1) (eCFR anchor p-201.7(a)(1)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives only where the source and recorded environment align. ## What the source does not establish Federal hazard-mitigation regulation for tribal governments; recipient or subrecipient role, sovereignty, hazards, consultation, FEMA guidance, plan status, and grant program rules require authoritative review. No current deployment state or change approval follows from the source alone. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 44 CFR 201.7(d)(3) (eCFR anchor p-201.7(d)(3)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 44 CFR 201.7(a)(1) (eCFR anchor p-201.7(a)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from 44 CFR 201.7(d)(3) (eCFR anchor p-201.7(d)(3)); 44 CFR 201.7(a)(1) (eCFR anchor p-201.7(a)(1)) through business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [44 CFR 201.7 – Tribal Mitigation Plans](https://www.ecfr.gov/current/title-44/section-201.7) — Federal Emergency Management Agency via eCFR ## Primary reference - Name: 44 CFR 201.7 - Tribal Mitigation Plans - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-44/section-201.7 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve tribal authority and participation throughout mitigation planning,” DSE Security, https://update.dsesecurity.com/updates/preserve-tribal-authority-and-participation-throughout-mitigation-planning/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve UAC token boundaries in privileged workflows > Use How User Account Control works to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/preserve-uac-token-boundaries-in-privileged-workflows/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:44+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Use How User Account Control works to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of How User Account Control works ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Preserve UAC token boundaries in privileged workflows. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [How User Account Control works](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/user-account-control/how-it-works) from Microsoft supports the following bounded statements: - UAC reduces malware risk by limiting execution with administrator privileges. The research record locates this support at Opening overview. - Applications needing an administrator token prompt for consent, while child processes inherit the parent token only at the same integrity level. The research record locates this support at Opening overview. Keep the evidence boundary at these traced claims. They support a review of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish UAC is a privilege-elevation control, not a security boundary that makes administrator sessions safe. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to Opening overview; Opening overview and to observable material such as policy and feature state, security events, test detections, administrative assignments, exception approvals, and response tickets. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [How User Account Control works](https://learn.microsoft.com/en-us/windows/security/application-security/application-control/user-account-control/how-it-works) — Microsoft ## Primary reference - Name: How User Account Control works - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/application-security/application-control/user-account-control/how-it-works - Source publication date: 2026-04-23 ## Citation and use Preferred citation: “Preserve UAC token boundaries in privileged workflows,” DSE Security, https://update.dsesecurity.com/updates/preserve-uac-token-boundaries-in-privileged-workflows/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve unknown DNS record types through generic presentation syntax > Use RFC 3597 — Handling of Unknown DNS Resource Record (RR) Types to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/preserve-unknown-dns-record-types-through-generic-presentation-syntax/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:35+00:00 - Modified: 2026-08-27T12:18:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3597 — Handling of Unknown DNS Resource Record (RR) Types to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3597 — Handling of Unknown DNS Resource Record (RR) Types ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Preserve unknown DNS record types through generic presentation syntax. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3597 — Handling of Unknown DNS Resource Record (RR) Types](https://www.rfc-editor.org/rfc/rfc3597.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - The generic master-file form for an unknown RR type uses a type code and a length-prefixed hexadecimal representation of its RDATA. The research record locates this support at Section 5 (Text Representation). - DNS servers and resolvers must handle unknown RR types transparently without requiring type-specific RDATA knowledge. The research record locates this support at Section 3 (Transparency). - A new RR type must not embed compressed domain names in its RDATA, because older servers cannot decompress an unknown format. The research record locates this support at Section 4 (Domain Name Compression). Only the traced statements above are asserted as source facts. Apply the review to authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Section 5 (Text Representation), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 3 (Transparency), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4 (Domain Name Compression), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Section 5 (Text Representation); Section 3 (Transparency); Section 4 (Domain Name Compression) to the observed environment. Useful domain evidence includes zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 3597 — Handling of Unknown DNS Resource Record (RR) Types](https://www.rfc-editor.org/rfc/rfc3597.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 3597 — Handling of Unknown DNS Resource Record (RR) Types - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3597.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve unknown DNS record types through generic presentation syntax,” DSE Security, https://update.dsesecurity.com/updates/preserve-unknown-dns-record-types-through-generic-presentation-syntax/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Preserve user-profile disk paths during an RDS file-server move > Which profile-disk path must be updated when an RDS collection uses a migrated file server? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-206-preserve-user-profile-disk-paths-during-an-rds-file-server-move/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:45+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Which profile-disk path must be updated when an RDS collection uses a migrated file server? ## Potentially affected Administrators migrating a file server that holds user-profile disks for an RDS collection. ## DSE recommendation Create a source-to-destination path map and have the RDS and storage owners review it together. ## Article ## Source facts For a collection with its UVHD template enabled, Microsoft directs administrators to update the User Profile Disks location when the file server moves. The profile disks must remain available at the same relative path within the new location. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/migrate-rds-role-services). ## Applicability Confirm whether the collection actually uses the documented user-profile disk arrangement. Identify the existing location, target file server, and relative disk paths before moving data. Review the wider RDS migration prerequisites separately; this check addresses the profile-storage handoff after that plan is established. ## DSE recommendation Create a source-to-destination path map and have the RDS and storage owners review it together. Record the collection property that will change and preserve its initial value. Use representative test users and a recoverable profile set during the pilot. Agree on the migration window and the way to restore the previous path if acceptance fails. Keep ordinary user data out of the change record. ## Verification Inspect the target profile-disk layout against the recorded relative paths, then verify the updated collection property. Sign in with the approved test users and confirm their expected profile content and application settings. Repeat after sign-out and a new session. Record inaccessible or unexpected profiles individually and resolve the path discrepancy before retiring the old location. ## Official references [Microsoft Learn: Migrate your Remote Desktop Services deployment](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/migrate-rds-role-services). Source reviewed September 8, 2026. ## Primary reference - Name: Migrate your Remote Desktop Services deployment - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/migrate-rds-role-services - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Preserve user-profile disk paths during an RDS file-server move,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-206-preserve-user-profile-disk-paths-during-an-rds-file-server-move/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prevent and detect unauthorized entry into airport secured areas > Use 49 CFR 1542.201 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/prevent-and-detect-unauthorized-entry-into-airport-secured-areas/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:34+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.201 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.201 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Prevent and detect unauthorized entry into airport secured areas. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.201 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.201) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, the rule requires that each airport operator required to establish a secured area prevent and detect the unauthorized entry, presence, and movement of individuals and ground vehicles into and within the secured area by doing the following: establish and carry out measures for controlling entry to secured areas of the airport in accordance with section 1542.207. The research record locates this support at 49 CFR 1542.201(b)(1), read with 49 CFR 1542.201(b) (eCFR anchor p-1542.201(b)(1)). - Under 49 CFR 1542, the rule requires that each airport operator required to establish a secured area prevent and detect the unauthorized entry, presence, and movement of individuals and ground vehicles into and within the secured area by doing the following: train each individual before granting unescorted access to the secured area, as required in section 1542.213(b). The research record locates this support at 49 CFR 1542.201(b)(5), read with 49 CFR 1542.201(b) (eCFR anchor p-1542.201(b)(5)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces only where the source and recorded environment align. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 49 CFR 1542.201(b)(1), read with 49 CFR 1542.201(b) (eCFR anchor p-1542.201(b)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.201(b)(5), read with 49 CFR 1542.201(b) (eCFR anchor p-1542.201(b)(5)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from 49 CFR 1542.201(b)(1), read with 49 CFR 1542.201(b) (eCFR anchor p-1542.201(b)(1)); 49 CFR 1542.201(b)(5), read with 49 CFR 1542.201(b) (eCFR anchor p-1542.201(b)(5)) through approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records. Record what was collected, where, when, by whom, and which system or role it represents. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [49 CFR 1542.201 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.201) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.201 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.201 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prevent and detect unauthorized entry into airport secured areas,” DSE Security, https://update.dsesecurity.com/updates/prevent-and-detect-unauthorized-entry-into-airport-secured-areas/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prevent route-reflector loops with cluster and originator attributes > Use RFC 4456 — BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/prevent-route-reflector-loops-with-cluster-and-originator-attributes/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:18+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4456 — BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4456 — BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Prevent route-reflector loops with cluster and originator attributes. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4456 — BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)](https://www.rfc-editor.org/rfc/rfc4456.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A route reflector creates ORIGINATOR_ID from the original speaker’s BGP Identifier, and a router should ignore a route whose ORIGINATOR_ID equals its own identifier. The research record locates this support at Section 8 (Avoiding Routing Information Loops), ORIGINATOR_ID. - Each reflector must prepend its local cluster ID to CLUSTER_LIST and should ignore an advertisement whose list already contains that local ID. The research record locates this support at Section 8 (Avoiding Routing Information Loops), CLUSTER_LIST. - Route selection treats ORIGINATOR_ID as the advertising speaker’s identifier and should prefer the shorter CLUSTER_LIST before the next tie-break step. The research record locates this support at Section 9 (Impact on Route Selection). Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Section 8 (Avoiding Routing Information Loops), ORIGINATOR_ID, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 8 (Avoiding Routing Information Loops), CLUSTER_LIST, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 9 (Impact on Route Selection), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Section 8 (Avoiding Routing Information Loops), ORIGINATOR_ID; Section 8 (Avoiding Routing Information Loops), CLUSTER_LIST; Section 9 (Impact on Route Selection) to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [RFC 4456 — BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)](https://www.rfc-editor.org/rfc/rfc4456.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4456 — BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4456.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prevent route-reflector loops with cluster and originator attributes,” DSE Security, https://update.dsesecurity.com/updates/prevent-route-reflector-loops-with-cluster-and-originator-attributes/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prevent split nuclear shipments from bypassing aggregate protection thresholds > Use 10 CFR 73.24 - Prohibitions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/prevent-split-nuclear-shipments-from-bypassing-aggregate-protection-thresholds/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:09:57+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.24 - Prohibitions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.24 - Prohibitions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Prevent split nuclear shipments from bypassing aggregate protection thresholds. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.24 – Prohibitions](https://www.ecfr.gov/current/title-10/section-73.24) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Absent specific NRC approval, a special-nuclear-material shipment above the stated plutonium, uranium-233, or uranium-235 thresholds may not travel on passenger aircraft. The research record locates this support at 10 CFR 73.24(a) (eCFR anchor p-73.24(a)). - When individually sub-formula shipments could collectively reach a formula quantity in transit, a licensee must log confirmed arrivals and schedule shipments below that aggregate threshold, unless it supplies the specified physical protection. The research record locates this support at 10 CFR 73.24(b)(1) and 73.24(b)(2), read with 10 CFR 73.24(b) (eCFR anchors p-73.24(b)(1) and p-73.24(b)(2)). Keep the evidence boundary at these traced claims. They support a review of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This covers only the shipment prohibitions and aggregation controls in 10 CFR 73.24. It does not select carriers, routes, packaging, or safeguards for a particular shipment. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 10 CFR 73.24(a) (eCFR anchor p-73.24(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.24(b)(1) and 73.24(b)(2), read with 10 CFR 73.24(b) (eCFR anchors p-73.24(b)(1) and p-73.24(b)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 10 CFR 73.24(a) (eCFR anchor p-73.24(a)); 10 CFR 73.24(b)(1) and 73.24(b)(2), read with 10 CFR 73.24(b) (eCFR anchors p-73.24(b)(1) and p-73.24(b)(2)). Favor asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [10 CFR 73.24 – Prohibitions](https://www.ecfr.gov/current/title-10/section-73.24) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.24 - Prohibitions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.24 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prevent split nuclear shipments from bypassing aggregate protection thresholds,” DSE Security, https://update.dsesecurity.com/updates/prevent-split-nuclear-shipments-from-bypassing-aggregate-protection-thresholds/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prioritize cyber risks by enterprise impact before selecting a response > Use IR 8286B, Prioritizing Cybersecurity Risk for Enterprise Risk Management to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/prioritize-cyber-risks-by-enterprise-impact-before-selecting-a-response/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:18:00+00:00 - Modified: 2026-08-27T12:18:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use IR 8286B, Prioritizing Cybersecurity Risk for Enterprise Risk Management to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of IR 8286B, Prioritizing Cybersecurity Risk for Enterprise Risk Management ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Prioritize cyber risks by enterprise impact before selecting a response. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [IR 8286B, Prioritizing Cybersecurity Risk for Enterprise Risk Management](https://csrc.nist.gov/pubs/ir/8286/b/upd1/final) from National Institute of Standards and Technology supports the following bounded statements: - NIST IR 8286B describes prioritizing identified cybersecurity risks by their potential impact on enterprise objectives. The research record locates this support at Abstract. - It describes adding priority and response information to a cybersecurity risk register in support of an enterprise risk register. The research record locates this support at Abstract. Only the traced statements above are asserted as source facts. Apply the review to essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives after confirming that the source and deployed context match. ## What the source does not establish The report does not set universal scoring thresholds, risk appetite, or an automatically correct treatment for a specific organization. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Abstract, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Abstract, which observable configuration, record, or test can confirm applicability here? - Within essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, which versions, roles, and configuration states define the review population? - Could identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Abstract; Abstract to the observed environment. Useful domain evidence includes business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [IR 8286B, Prioritizing Cybersecurity Risk for Enterprise Risk Management](https://csrc.nist.gov/pubs/ir/8286/b/upd1/final) — National Institute of Standards and Technology ## Primary reference - Name: IR 8286B, Prioritizing Cybersecurity Risk for Enterprise Risk Management - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/ir/8286/b/upd1/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prioritize cyber risks by enterprise impact before selecting a response,” DSE Security, https://update.dsesecurity.com/updates/prioritize-cyber-risks-by-enterprise-impact-before-selecting-a-response/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prioritize home-health patients when services are interrupted > Use 42 CFR 484.102 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/prioritize-home-health-patients-when-services-are-interrupted/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:02+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 484.102 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 484.102 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Prioritize home-health patients when services are interrupted. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 484.102 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-484.102) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 484, the rule requires that if elected, the unified and integrated emergency preparedness program do all of the following: include integrated policies and procedures that meet the requirements set forth in paragraph (b) of this section, a coordinated communication plan and training and testing programs that meet the requirements of paragraphs (c) and (d) of this section, respectively. The research record locates this support at 42 CFR 484.102(e)(5), read with 42 CFR 484.102(e) (eCFR anchor p-484.102(e)(5)). - Under 42 CFR 484, the rule requires that the HHA develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 484.102(d) (eCFR anchor p-484.102(d)). Keep the evidence boundary at these traced claims. They support a review of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish HHA-specific federal condition of participation; patient acuity, geographic dispersion, caregiver support, transportation, communications, state law, and survey guidance require local prioritization. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 484.102(e)(5), read with 42 CFR 484.102(e) (eCFR anchor p-484.102(e)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 484.102(d) (eCFR anchor p-484.102(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to 42 CFR 484.102(e)(5), read with 42 CFR 484.102(e) (eCFR anchor p-484.102(e)(5)); 42 CFR 484.102(d) (eCFR anchor p-484.102(d)) and to observable material such as business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [42 CFR 484.102 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-484.102) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 484.102 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-484.102 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prioritize home-health patients when services are interrupted,” DSE Security, https://update.dsesecurity.com/updates/prioritize-home-health-patients-when-services-are-interrupted/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prioritize password risks in one cross-provider identity view > Use Investigate identity password protection to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/prioritize-password-risks-in-cross-provider-identity-view/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:10+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Investigate identity password protection to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Investigate identity password protection ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Prioritize password risks in one cross-provider identity view. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Investigate identity password protection](https://learn.microsoft.com/en-us/defender-for-identity/password-protection) from Microsoft supports the following bounded statements: - The Password protection page consolidates leaked credentials, exposed passwords, weak password policies, and configuration issues into a prioritized view. The research record locates this support at Opening product description. - Its identity sources can include on-premises Active Directory, Microsoft Entra ID, federated identities, Okta, and SaaS applications connected through Defender for Cloud Apps. The research record locates this support at Opening product description. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows and the conditions the source actually describes. ## What the source does not establish A listed risk requires owner validation and source-specific remediation; the view does not establish that every credential store or provider is covered. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening product description, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening product description, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing and sanitize protected material before retention. ## Verification and evidence Build a reproducible chain from Opening product description; Opening product description to the observed environment. Useful domain evidence includes alert records, investigation timelines, analyst actions, tuning or exclusion approvals, remediation results, and case closure; label every item with scope, timestamp, collector, and stable identifier. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Investigate identity password protection](https://learn.microsoft.com/en-us/defender-for-identity/password-protection) — Microsoft ## Primary reference - Name: Investigate identity password protection - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/password-protection - Source publication date: 2026-08-24 ## Citation and use Preferred citation: “Prioritize password risks in one cross-provider identity view,” DSE Security, https://update.dsesecurity.com/updates/prioritize-password-risks-in-cross-provider-identity-view/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Probe a specific interface with ICMP Extended Echo under authorization > Use RFC 8335 — PROBE: A Utility for Probing Interfaces to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/probe-a-specific-interface-with-icmp-extended-echo-under-authorization/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:17+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8335 — PROBE: A Utility for Probing Interfaces to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8335 — PROBE: A Utility for Probing Interfaces ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Probe a specific interface with ICMP Extended Echo under authorization. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8335 — PROBE: A Utility for Probing Interfaces](https://www.rfc-editor.org/rfc/rfc8335.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An ICMP Extended Echo Request MUST contain exactly one Interface Identification Object; with L set it may identify a local interface by name, index, or address, while L clear requires an address. The research record locates this support at Section 2 (ICMP Extended Echo Request). - A node MUST silently discard an Extended Echo Request unless the feature, L-bit setting, query type, and source are explicitly authorized and the source is unicast and destination is not multicast. The research record locates this support at Section 4 (ICMP Message Processing). - Supporting nodes MUST offer controls for enabling Extended Echo, permitted L-bit settings, query types, and source prefixes; the feature and all query types are disabled by default. The research record locates this support at Section 8 (Security Considerations). Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Section 2 (ICMP Extended Echo Request), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4 (ICMP Message Processing), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 8 (Security Considerations), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from Section 2 (ICMP Extended Echo Request); Section 4 (ICMP Message Processing); Section 8 (Security Considerations) to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 8335 — PROBE: A Utility for Probing Interfaces](https://www.rfc-editor.org/rfc/rfc8335.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8335 — PROBE: A Utility for Probing Interfaces - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8335.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Probe a specific interface with ICMP Extended Echo under authorization,” DSE Security, https://update.dsesecurity.com/updates/probe-a-specific-interface-with-icmp-extended-echo-under-authorization/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect an NPS configuration export and review its import limits > What must be reviewed before importing an exported NPS configuration? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-212-protect-an-nps-configuration-export-and-review-its-import-limits/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:39+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know What must be reviewed before importing an exported NPS configuration? ## Potentially affected Administrators moving Network Policy Server settings between Windows servers. ## DSE recommendation Store the export in an access-controlled location and name the administrators authorized to handle it. ## Article ## Source facts Importing an NPS configuration replaces the destination settings rather than merging with them. Microsoft prohibits this procedure when the source NPS database version is newer than the destination database. SQL Server logging settings are excluded from the export and must be configured manually on the receiving NPS. A Netsh export contains unencrypted RADIUS shared secrets in its XML file. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-export). ## Applicability Identify the source and destination roles and verify the supported export and import method for their server versions. Review the complete configuration scope before treating the file as a single-policy backup. Account for server-specific endpoints and logging destinations in the transfer plan. ## DSE recommendation Store the export in an access-controlled location and name the administrators authorized to handle it. Record the source configuration and capture the destination’s current settings before import. Have the receiving owner review clients, remote servers, policy order, and logging configuration for that environment. Use a nonproduction transfer exercise before replacing settings on an active authentication server. ## Verification Refresh the management view and compare the imported settings with the approved transfer inventory. Test representative local and forwarded requests, accounting where applicable, and a request that should be rejected. Record the configuration differences and functional results separately. Remove temporary transfer access according to the approved handling plan once the import is accepted. ## Official references [Microsoft Learn: Export an NPS Configuration for Import on Another Server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-export). Source reviewed September 8, 2026. ## Primary reference - Name: Export an NPS Configuration for Import on Another Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-manage-export - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Protect an NPS configuration export and review its import limits,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-212-protect-an-nps-configuration-export-and-review-its-import-limits/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect and implement TSA Security Directives within required time and distribution limits > Use 49 CFR 1542.303 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/protect-and-implement-tsa-security-directives-within-required-time-and-distribution-limits/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:21+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.303 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.303 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Protect and implement TSA Security Directives within required time and distribution limits. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.303 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.303) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, in the event that the airport operator is unable to implement the measures in the Security Directive, the airport operator must submit proposed alternative measures and the basis for submitting the alternative measures to TSA for approval. The research record locates this support at 49 CFR 1542.303(d) (eCFR anchor p-1542.303(d)). - Under 49 CFR 1542, the rule requires that each airport operator that receives a Security Directive within the time prescribed in the Security Directive, verbally acknowledge receipt of the Security Directive to TSA. The research record locates this support at 49 CFR 1542.303(c)(1), read with 49 CFR 1542.303(c) (eCFR anchor p-1542.303(c)(1)). Keep the evidence boundary at these traced claims. They support a review of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 49 CFR 1542.303(d) (eCFR anchor p-1542.303(d)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.303(c)(1), read with 49 CFR 1542.303(c) (eCFR anchor p-1542.303(c)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 49 CFR 1542.303(d) (eCFR anchor p-1542.303(d)); 49 CFR 1542.303(c)(1), read with 49 CFR 1542.303(c) (eCFR anchor p-1542.303(c)(1)). Favor asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [49 CFR 1542.303 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.303) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.303 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.303 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Protect and implement TSA Security Directives within required time and distribution limits,” DSE Security, https://update.dsesecurity.com/updates/protect-and-implement-tsa-security-directives-within-required-time-and-distribution-limits/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect and retain maritime-facility drill, incident, maintenance, and access records > Use 33 CFR 105.225 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/protect-and-retain-maritime-facility-drill-incident-maintenance-and-access-records/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:17+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.225 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.225 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Protect and retain maritime-facility drill, incident, maintenance, and access records. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.225 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.225) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that the following records be kept: for each occurrence of maintenance, calibration, and testing, record the date and time, and the specific security equipment involved. The research record locates this support at 33 CFR 105.225(b)(5), read with 33 CFR 105.225(b) (eCFR anchor p-105.225(b)(5)). - Under 33 CFR 105, the rule requires that any record required by this part be protected from unauthorized access or disclosure. The research record locates this support at 33 CFR 105.225(c) (eCFR anchor p-105.225(c)). Only the traced statements above are asserted as source facts. Apply the review to access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths after confirming that the source and deployed context match. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.225(b)(5), read with 33 CFR 105.225(b) (eCFR anchor p-105.225(b)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.225(c) (eCFR anchor p-105.225(c)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to 33 CFR 105.225(b)(5), read with 33 CFR 105.225(b) (eCFR anchor p-105.225(b)(5)); 33 CFR 105.225(c) (eCFR anchor p-105.225(c)) and to observable material such as asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [33 CFR 105.225 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.225) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.225 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.225 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Protect and retain maritime-facility drill, incident, maintenance, and access records,” DSE Security, https://update.dsesecurity.com/updates/protect-and-retain-maritime-facility-drill-incident-maintenance-and-access-records/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect CJIS cabling and displays beyond the secure-room door > CJIS physical protection extends to transmission paths and output devices. Trace cable, closet, jack, monitor, printer, and other exposure beyond the room entrance. - Canonical URL: https://update.dsesecurity.com/updates/protect-cjis-cabling-and-displays-beyond-the-secure-room-door/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:44+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Access Control, Cybersecurity, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know CJIS physical protection extends to transmission paths and output devices. Trace cable, closet, jack, monitor, printer, and other exposure beyond the room entrance. ## Potentially affected CJIS-scope facilities where criminal justice information traverses internal cabling, communications spaces, wall jacks, displays, printers, or other output devices. ## DSE recommendation Map every in-scope transmission and output point, assign physical protection and inspection controls, and test that unauthorized reach does not bypass the secure-area boundary. ## Article Bottom line: a locked room does not protect a cable that leaves through an accessible ceiling, an active jack in a public area, or a display visible from outside the boundary. Physical scope follows the information path and output, not only the server-room door. ## Source fact: CJIS policy addresses transmission paths and output devices The [FBI CJIS Security Policy v6.1 — PE-4 and PE-5](https://le.fbi.gov/file-repository/cjis_security_policy_v6-1_20260625.pdf#page=209), dated June 25, 2026, addresses physical protection for information-system distribution and transmission lines and devices. Its examples include locked wiring closets, locked or disconnected jacks, conduit or cable trays, and sensors for physical tampering. The policy also addresses controlling access to output from devices such as monitors and printers. The examples reveal two separate exposure paths: connecting to or altering the transmission infrastructure, and observing or removing information after a legitimate system outputs it. ## Source boundary and applicability CJIS requirements apply based on the information, agency relationship, system and facility boundary, contracts, and direction from the responsible CJIS authority. The policy examples do not mandate the same physical measure for every cable or device, nor do they replace encryption, network access control, media protection, or personnel controls. A qualified assessment must select controls for the actual risk and architecture. ## Applicability questions - Where does in-scope information travel between secure endpoints, including shared risers and service spaces? - Which patch panels, splices, jacks, converters, wireless bridges, and cabinets are physically reachable? - Which displays, printers, scanners, removable media, and maintenance interfaces expose output? - Are unused ports disconnected, blocked, authenticated, monitored, or otherwise controlled? - Who may service each path, and how is work authorized and observed? ## DSE recommendation: survey the complete physical information route The following steps are DSE recommendations based on the cited source. Overlay the logical data flow on a physical drawing showing rooms, ceilings, risers, closets, cabinets, wall plates, conduits, output devices, and public sight lines. Classify each point by reachability, information exposure, existing lock or enclosure, electronic protection, inspection frequency, and responsible owner. Remove or disable unnecessary paths through approved change control. Test cabinet and closet access, unused jack state, tamper alert delivery where implemented, screen visibility, print collection, and service-person workflow. Coordinate with network, facilities, CJIS security, safety, and accessibility owners; physical protection must not create unapproved egress or maintenance hazards. ## Verification and evidence Retain the approved scope, sanitized route drawing, cable and output inventory, closet and cabinet access review, port-state evidence, tamper test, sight-line assessment, service logs, deficiency tickets, and periodic inspection results. Protect the detailed map because it can disclose sensitive facility and network information. ## Official references - [FBI CJIS Security Policy v6.1 — PE-4 and PE-5](https://le.fbi.gov/file-repository/cjis_security_policy_v6-1_20260625.pdf#page=209) – Federal Bureau of Investigation; June 25, 2026 ## Primary reference - Name: FBI CJIS Security Policy v6.1 — PE-4 and PE-5 - Authority: le.fbi.gov - URL: https://le.fbi.gov/file-repository/cjis_security_policy_v6-1_20260625.pdf#page=209 - Source publication date: 2026-06-25 ## Citation and use Preferred citation: “Protect CJIS cabling and displays beyond the secure-room door,” DSE Security, https://update.dsesecurity.com/updates/protect-cjis-cabling-and-displays-beyond-the-secure-room-door/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect dialysis patients when treatment sites or utilities fail > Use 42 CFR 494.62 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/protect-dialysis-patients-when-treatment-sites-or-utilities-fail/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:56+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 494.62 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 494.62 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Protect dialysis patients when treatment sites or utilities fail. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 494.62 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-494.62) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 494, the rule requires that if elected, the unified and integrated emergency preparedness program do all of the following: include integrated policies and procedures that meet the requirements set forth in paragraph (b) of this section, a coordinated communication plan and training and testing programs that meet the requirements of paragraphs (c) and (d) of this section, respectively. The research record locates this support at 42 CFR 494.62(e)(5), read with 42 CFR 494.62(e) (eCFR anchor p-494.62(e)(5)). - Under 42 CFR 494, the rule requires that the dialysis facility develop and maintain an emergency preparedness training, testing and patient orientation program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 494.62(d) (eCFR anchor p-494.62(d)). The source support ends with the statements listed above. Use them to examine essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives in the applicable environment, not to imply a wider guarantee. ## What the source does not establish ESRD-facility federal condition; water, power, treatment schedule, patient education, alternate facilities, transport, clinical decisions, state law, and survey guidance require detailed planning. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 494.62(e)(5), read with 42 CFR 494.62(e) (eCFR anchor p-494.62(e)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 494.62(d) (eCFR anchor p-494.62(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 42 CFR 494.62(e)(5), read with 42 CFR 494.62(e) (eCFR anchor p-494.62(e)(5)); 42 CFR 494.62(d) (eCFR anchor p-494.62(d)). Favor business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [42 CFR 494.62 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-494.62) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 494.62 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-494.62 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Protect dialysis patients when treatment sites or utilities fail,” DSE Security, https://update.dsesecurity.com/updates/protect-dialysis-patients-when-treatment-sites-or-utilities-fail/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect export shipments of low-significance special nuclear material > Use 10 CFR 73.73 - Export shipments of low-significance special nuclear material to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/protect-export-shipments-of-low-significance-special-nuclear-material/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:37+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.73 - Export shipments of low-significance special nuclear material to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.73 - Export shipments of low-significance special nuclear material ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Protect export shipments of low-significance special nuclear material. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.73 – Export shipments of low-significance special nuclear material](https://www.ecfr.gov/current/title-10/section-73.73) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, the rule requires that a licensee authorized to export special nuclear material of low strategic significance notify in writing the Director, Office of Nuclear Security and Incident Response, by email (preferred method) to AdvanceNotifications.Resource@nrc.gov or by using any appropriate method listed in section 73.4. The research record locates this support at 10 CFR 73.73(a)(1), read with 10 CFR 73.73(a) (eCFR anchor p-73.73(a)(1)). - Under 10 CFR 73, the rule requires that a licensee authorized to export special nuclear material of low strategic significance include the following information in the notification: the estimated time and date of arrival of the shipment at the destination. The research record locates this support at 10 CFR 73.73(a)(3)(v), read with 10 CFR 73.73(a)(3) and 10 CFR 73.73(a) (eCFR anchor p-73.73(a)(3)(v)). Keep the evidence boundary at these traced claims. They support a review of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish NRC regulation for defined exports; material category, destination, handoffs, notices, international obligations, and protected transport details require authorized review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.73(a)(1), read with 10 CFR 73.73(a) (eCFR anchor p-73.73(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.73(a)(3)(v), read with 10 CFR 73.73(a)(3) and 10 CFR 73.73(a) (eCFR anchor p-73.73(a)(3)(v)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 10 CFR 73.73(a)(1), read with 10 CFR 73.73(a) (eCFR anchor p-73.73(a)(1)); 10 CFR 73.73(a)(3)(v), read with 10 CFR 73.73(a)(3) and 10 CFR 73.73(a) (eCFR anchor p-73.73(a)(3)(v)). Favor asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [10 CFR 73.73 – Export shipments of low-significance special nuclear material](https://www.ecfr.gov/current/title-10/section-73.73) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.73 - Export shipments of low-significance special nuclear material - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.73 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Protect export shipments of low-significance special nuclear material,” DSE Security, https://update.dsesecurity.com/updates/protect-export-shipments-of-low-significance-special-nuclear-material/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect Layer 2 edges with explicit spanning-tree guardrails > A misplaced switch or unexpected bridge can change Layer 2 topology and disrupt a site. Define the intended spanning-tree root, classify ports, apply platform-appropriate protections, monitor topology changes, and test recovery. - Canonical URL: https://update.dsesecurity.com/updates/protect-layer-2-edges-with-spanning-tree-guardrails/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T12:56:00+00:00 - Modified: 2026-08-17T19:22:10+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know A misplaced switch or unexpected bridge can change Layer 2 topology and disrupt a site. Define the intended spanning-tree root, classify ports, apply platform-appropriate protections, monitor topology changes, and test recovery. ## Potentially affected Campus and branch switching; trunks and access ports; wireless bridges; phones and downstream switches; building systems; surveillance and access-control networks; redundant links; monitoring; and outage response. ## DSE recommendation Document the intended Layer 2 topology and roots, classify every edge and infrastructure port, apply supported guard features, monitor topology change, control unauthorized switching, and rehearse isolation and recovery. ## Article ## Source facts: spanning tree depends on an intended topology Cisco’s [Borderless Campus 1.0 Design Guide](https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/Borderless_Campus_Network_1-0/Borderless_Campus_1-0_Design_Guide.pdf) describes a hierarchical campus design and recommends deliberately controlling the spanning-tree topology. The design guidance places root roles in the distribution layer and discusses features intended to protect the topology from unexpected bridge protocol data units or inappropriate root elections. Cisco’s [Catalyst STP troubleshooting guidance](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/28943-170.html) explains several distinct mechanisms. PortFast changes how an edge port reaches forwarding. BPDU Guard can disable a PortFast-enabled port when a BPDU is received. Root Guard prevents a port from becoming a path toward an unexpected root. Loop Guard addresses certain failures involving lost BPDUs on redundant paths. These controls solve different problems and should not be applied interchangeably. The sources describe Cisco technologies and terminology. They support the general need to declare edge versus infrastructure roles and protect the elected topology, but they do not establish the correct commands for every switch, operating system, virtual bridge, or mixed-vendor network. ## DSE recommendation: turn topology assumptions into enforced port roles Start with the physical and logical path the network is expected to use. A guardrail is safest when the team can explain what traffic and control messages should legitimately arrive on that exact port. - Map the Layer 2 domain. Record switches, stack or chassis relationships, VLANs, trunks, port channels, redundant paths, wireless bridges, hypervisor bridges, unmanaged downstream devices, and links that cross buildings or providers. Mark the intended root and secondary root for each relevant spanning-tree instance. - Classify every port. Distinguish end-station edges, approved downstream-switch links, trunks, peer links, routed links, provider handoffs, and intentionally unused ports. Do not infer the role only from a current link state; compare switch configuration with patching records and field inspection. - Choose protections by failure mode. Use platform-supported edge behavior only where a bridge is not expected. Consider BPDU protection on true edge ports, root protection on links that must not influence root selection, and loop protection on appropriate redundant paths. Validate interactions with link aggregation, multiple spanning-tree instances, and vendor-specific defaults. - Control unauthorized attachment. Disable unused ports, restrict access to telecommunications rooms, maintain switch and MAC inventories, and alert on new infrastructure-class devices. Network access control can add evidence, but a MAC address or device profile alone is not proof that a connected bridge is trustworthy. - Monitor topology signals. Collect root changes, topology-change notifications, blocked-port transitions, inconsistent states, guard activations, link flaps, CPU pressure, and broadcast or multicast growth. Correlate these events with change tickets and physical work so planned maintenance is distinguishable from an emerging loop. - Test safely. In a lab or approved maintenance window, confirm that an unexpected BPDU on an edge port produces the intended response, valid redundant links converge, monitoring receives the event, and recovery follows the documented procedure. Avoid tests that could bridge production segments without containment. - Write the recovery path. Define who may isolate a port, how to identify the originating device, what evidence to capture, when a guard condition may be cleared, and how service is validated afterward. Re-enabling a port without removing the cause can immediately recreate the outage. Factual boundary: Cisco feature names, defaults, and configuration syntax are platform-specific. Guard placement depends on the actual topology. Incorrect use can disable legitimate redundancy or strand downstream service, so validate root placement, protocol mode, vendor behavior, and recovery before deployment. Track unexpected root changes, unclassified ports, guard events without investigation, unmanaged switches, undocumented trunks, and recovery tests. A stable Layer 2 network is not one that never changes; it is one whose permitted changes are understood and whose unsafe changes are contained. ## Official references - Cisco, [Borderless Campus 1.0 Design Guide](https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/Borderless_Campus_Network_1-0/Borderless_Campus_1-0_Design_Guide.pdf). - Cisco, [Troubleshoot STP Issues on Catalyst Switches](https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/28943-170.html). ## Primary reference - Name: Cisco Borderless Campus 1.0 Design Guide - Authority: www.cisco.com - URL: https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/Borderless_Campus_Network_1-0/Borderless_Campus_1-0_Design_Guide.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Protect Layer 2 edges with explicit spanning-tree guardrails,” DSE Security, https://update.dsesecurity.com/updates/protect-layer-2-edges-with-spanning-tree-guardrails/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect long-term-care residents through shelter, evacuation, and continuity planning > Use 42 CFR 483.73 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/protect-long-term-care-residents-through-shelter-evacuation-and-continuity-planning/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:04+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 42 CFR 483.73 - Emergency preparedness to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 42 CFR 483.73 - Emergency preparedness ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Protect long-term-care residents through shelter, evacuation, and continuity planning. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [42 CFR 483.73 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-483.73) from Centers for Medicare & Medicaid Services via eCFR supports the following bounded statements: - Under 42 CFR 483, the rule requires that if elected, the unified and integrated emergency preparedness program do all of the following: include integrated policies and procedures that meet the requirements set forth in paragraph (b) of this section, a coordinated communication plan and training and testing programs that meet the requirements of paragraphs (c) and (d) of this section, respectively. The research record locates this support at 42 CFR 483.73(f)(5), read with 42 CFR 483.73(f) (eCFR anchor p-483.73(f)(5)). - Under 42 CFR 483, the rule requires that the LTC facility develop and maintain an emergency preparedness training and testing program that is based on the emergency plan set forth in paragraph (a) of this section, risk assessment at paragraph (a)(1) of this section, policies and procedures at paragraph (b) of this section, and the communication plan at paragraph (c) of this section. The research record locates this support at 42 CFR 483.73(d) (eCFR anchor p-483.73(d)). Keep the evidence boundary at these traced claims. They support a review of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish LTC-specific federal condition of participation; resident dependency, transfer agreements, staffing, generators, state rules, waivers, and survey guidance require site-specific analysis. A correct source interpretation can still be inapplicable to a particular design. Confirm identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at 42 CFR 483.73(f)(5), read with 42 CFR 483.73(f) (eCFR anchor p-483.73(f)(5)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 42 CFR 483.73(d) (eCFR anchor p-483.73(d)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Tie each conclusion back to 42 CFR 483.73(f)(5), read with 42 CFR 483.73(f) (eCFR anchor p-483.73(f)(5)); 42 CFR 483.73(d) (eCFR anchor p-483.73(d)) and to observable material such as business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [42 CFR 483.73 – Emergency preparedness](https://www.ecfr.gov/current/title-42/section-483.73) — Centers for Medicare & Medicaid Services via eCFR ## Primary reference - Name: 42 CFR 483.73 - Emergency preparedness - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-42/section-483.73 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Protect long-term-care residents through shelter, evacuation, and continuity planning,” DSE Security, https://update.dsesecurity.com/updates/protect-long-term-care-residents-through-shelter-evacuation-and-continuity-planning/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect stored spent fuel and high-level waste as a distinct facility mission > Use 10 CFR 73.51 - Stored spent fuel and high-level radioactive waste to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/protect-stored-spent-fuel-and-high-level-waste-as-a-distinct-facility-mission/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:47+00:00 - Modified: 2026-08-27T13:06:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 10 CFR 73.51 - Stored spent fuel and high-level radioactive waste to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 10 CFR 73.51 - Stored spent fuel and high-level radioactive waste ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Protect stored spent fuel and high-level waste as a distinct facility mission. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [10 CFR 73.51 – Stored spent fuel and high-level radioactive waste](https://www.ecfr.gov/current/title-10/section-73.51) from U.S. Nuclear Regulatory Commission via eCFR supports the following bounded statements: - Under 10 CFR 73, the rule requires that each licensee subject to this section establish and maintain a physical protection system with the objective of providing high assurance that activities involving spent nuclear fuel and high-level radioactive waste do not constitute an unreasonable risk to public health and safety. The research record locates this support at 10 CFR 73.51(b)(1) (eCFR anchor p-73.51(b)(1)). - Under 10 CFR 73, the rule requires that spent nuclear fuel and high-level radioactive waste be stored only within a protected area so that access to this material requires passage through or penetration of two physical barriers, one barrier at the perimeter of the protected area and one barrier offering substantial penetration resistance. The research record locates this support at 10 CFR 73.51(d)(1) (eCFR anchor p-73.51(d)(1)). These statements are the factual basis for this document. Do not extend them into a broader assurance. Review access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths only where the source and recorded environment align. ## What the source does not establish NRC regulation for defined storage installations and material; licensing basis, site configuration, response, and protected security information require authorized technical and legal review. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 10 CFR 73.51(b)(1) (eCFR anchor p-73.51(b)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 10 CFR 73.51(d)(1) (eCFR anchor p-73.51(d)(1)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from 10 CFR 73.51(b)(1) (eCFR anchor p-73.51(b)(1)); 10 CFR 73.51(d)(1) (eCFR anchor p-73.51(d)(1)) through asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Record what was collected, where, when, by whom, and which system or role it represents. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [10 CFR 73.51 – Stored spent fuel and high-level radioactive waste](https://www.ecfr.gov/current/title-10/section-73.51) — U.S. Nuclear Regulatory Commission via eCFR ## Primary reference - Name: 10 CFR 73.51 - Stored spent fuel and high-level radioactive waste - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-10/section-73.51 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Protect stored spent fuel and high-level waste as a distinct facility mission,” DSE Security, https://update.dsesecurity.com/updates/protect-stored-spent-fuel-and-high-level-waste-as-a-distinct-facility-mission/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect syslog in transit without mistaking TLS for log durability > Authenticate and encrypt syslog transport while separately engineering buffering, retention, integrity, and collector availability. - Canonical URL: https://update.dsesecurity.com/updates/protect-syslog-in-transit-with-tls/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:45+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Authenticate and encrypt syslog transport while separately engineering buffering, retention, integrity, and collector availability. ## Potentially affected Infrastructure that sends syslog messages across untrusted, shared, or administratively separate networks ## DSE recommendation Qualify certificate-based syslog over TLS end to end and test what happens when the collector or trust path is unavailable. ## Article TLS can protect syslog messages while they cross the network, but it cannot make a full collector available or recover events a sender discarded. Secure transport and durable evidence are related requirements that need separate tests. ## Source fact: [IETF RFC 5425](https://www.rfc-editor.org/rfc/rfc5425.html) defines a TLS transport mapping for syslog. It specifies how a syslog transport sender and receiver establish a TLS connection, frame messages, and use certificates or configured fingerprints to authenticate peers. The RFC discusses authorization based on certificate identity and the protection TLS provides against disclosure and modification in transit. The mapping is connection-oriented and includes requirements for closure and error handling. Its security discussion distinguishes authenticated operation from configurations that do not sufficiently verify the peer. The standard governs transport; it does not define how long a device buffers during failure, how a collector stores an event, or how a downstream analytics system preserves integrity. ## Boundary Device support varies by TLS version, cipher configuration, certificate validation, name matching, message format, framing, and queue behavior. Encrypting a link does not establish the trustworthiness of the source event or the collector. TLS interception, load balancers, relays, and translation to an unprotected protocol create additional boundaries. Certificate expiration or time failure can interrupt logging if operations has not planned the dependency. ## Applicability questions - Which sources support RFC 5425-compatible framing and authenticated TLS rather than a vendor-specific approximation? - What identity should each sender validate, and which trust anchors issue collector certificates? - How many messages and how much time can each source buffer during a connection failure? - Where does transport encryption terminate, and is every onward hop protected appropriately? - How are certificate expiry, failed handshakes, queue saturation, and dropped events alerted? ## DSE recommendation: Map each source-to-storage path, including relays and load balancers. Establish supported TLS and identity-validation profiles for device classes, preferably with a managed certificate lifecycle. Do not suppress peer verification merely to obtain encryption. In a lab, test valid connection, unknown issuer, wrong name, expired certificate, receiver restart, network interruption, queue exhaustion, and recovery. Size local or relay buffering from measured event rates and the planned collector recovery time. Use redundant collectors only after confirming how clients distribute, retry, or fail over. Keep retention, access, immutability, time synchronization, and integrity controls in the logging platform’s own design. Provide an operational path to renew certificates before expiration without losing the trust check. ## Verification and evidence Retain topology, trust-chain and name-validation settings, sender queue limits, certificate inventory, packet captures showing negotiated protection without exposing private keys, collector receipt counts, and failure-test results. Reconcile messages generated at a controlled source with messages stored after an interruption. Alert evidence should show that TLS or queue failure reaches an operator through a channel that does not depend solely on the affected log path. ## Official references - [IETF RFC 5425](https://www.rfc-editor.org/rfc/rfc5425.html) - [IETF RFC 5424, The Syslog Protocol](https://www.rfc-editor.org/rfc/rfc5424.html) ## Primary reference - Name: RFC 5425: Transport Layer Security (TLS) Transport Mapping for Syslog - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5425.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Protect syslog in transit without mistaking TLS for log durability,” DSE Security, https://update.dsesecurity.com/updates/protect-syslog-in-transit-with-tls/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protect virtual machines through the virtual network they actually use > VM traffic may traverse virtual switches, overlays, host paths, and distributed controls. Design segmentation, redundancy, traffic enforcement, and monitoring against the real path. - Canonical URL: https://update.dsesecurity.com/updates/virtual-network-vm-protection/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:00+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know VM traffic may traverse virtual switches, overlays, host paths, and distributed controls. Design segmentation, redundancy, traffic enforcement, and monitoring against the real path. ## Potentially affected Organizations operating virtual machines on hypervisors, private clouds, hosted platforms, or software-defined virtual networks. ## DSE recommendation Map actual VM traffic and control points, isolate management, apply explicit segmentation and filtering, monitor virtual paths, and test redundancy and policy during migration and host failure. ## Article Bottom line: a virtual machine can communicate through paths that never reach the physical device an operator expects to enforce or observe the traffic. Protect the VM by mapping virtual switches, overlays, distributed policy, host interfaces, management paths, and external gateways as one network. ## Source fact: what NIST addresses [NIST SP 800-125B](https://csrc.nist.gov/pubs/sp/800/125/b/final) treats virtual machines as important compute resources hosting applications and identifies virtual-network configuration as a component of their protection. The publication analyzes configuration options for network segmentation, path redundancy, firewall traffic control, and VM traffic monitoring. The source supports evaluating controls inside the virtualization layer, not only at the physical perimeter. Its 2016 publication date also makes current platform documentation essential for product-specific implementation. ## What the source does not establish NIST does not certify a hypervisor, overlay, distributed firewall, or cloud network. A configured segment does not prove isolation if routing, inherited policy, host networking, administrative access, or migration changes the path. Redundancy does not guarantee useful failover under load or preserve security policy automatically. Applicability depends on platform architecture, tenancy, traffic patterns, overlay and underlay design, migration behavior, provider responsibilities, and the location of monitoring and enforcement. ## Applicability questions - Which virtual and physical paths carry VM data, storage, migration, backup, cluster, and management traffic? - Where are segmentation and firewall decisions made, and can another layer override or bypass them? - Which east-west flows remain within a host or overlay and therefore avoid physical monitoring points? - What policy follows a VM during migration, scaling, restore, or disaster recovery? - Which shared control-plane or network failure can affect both primary and redundant paths? ## DSE recommendation: validate the virtual path The following steps are DSE recommendations based on the cited source. - Diagram hypervisors or hosts, virtual switches, overlays, segments, routers, gateways, enforcement points, monitoring points, management interfaces, and external networks. - Separate virtualization management from ordinary workload traffic and restrict administrative identities, consoles, APIs, and automation. - Define permitted flows from application requirements. Test both the intended path and plausible same-host, cross-host, overlay, migration, backup, and recovery paths. - Place monitoring where it can observe the traffic of interest. Document blind spots and minimize sensitive payload capture. - Validate path redundancy with realistic load and failed components. Confirm that routing, filtering, identity, logging, and application behavior remain correct after convergence. - Recheck effective policy after migration, cloning, templating, restore, platform upgrade, or disaster-recovery activation. ## Verification and evidence Retain current topology, permitted-flow matrix, platform configuration exports, management access review, allowed and denied flow tests, monitoring samples, migration test, failure and recovery results, and change approvals. Record the exact platform version and workload placement used for each test. ## Official references - [NIST SP 800-125B — Secure Virtual Network Configuration for Virtual Machine Protection](https://csrc.nist.gov/pubs/sp/800/125/b/final) — National Institute of Standards and Technology; finalized March 7, 2016 ## Primary reference - Name: NIST SP 800-125B — Secure Virtual Network Configuration for Virtual Machine Protection - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/125/b/final - Source publication date: 2016-03-07 ## Citation and use Preferred citation: “Protect virtual machines through the virtual network they actually use,” DSE Security, https://update.dsesecurity.com/updates/virtual-network-vm-protection/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Protective DNS: evaluate the resolver, the data, and the bypass paths > Protective DNS can apply threat-informed policy to domain lookups, but selection must also address availability, privacy, logging, hybrid coverage, integrations, and traffic that bypasses DNS. - Canonical URL: https://update.dsesecurity.com/updates/protective-dns-provider-selection/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:26:27+00:00 - Modified: 2026-07-19T21:26:27+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Protective DNS can apply threat-informed policy to domain lookups, but selection must also address availability, privacy, logging, hybrid coverage, integrations, and traffic that bypasses DNS. ## Potentially affected Organizations evaluating or operating enterprise recursive DNS, protective DNS, roaming DNS clients, DNS security integrations, or policies that constrain alternate resolvers. ## DSE recommendation Define requirements, validate provider evidence and data use, design bypass resistance and hybrid coverage, pilot operational behavior, and retain complementary security controls. ## Article Protective DNS can stop some connections before an endpoint reaches a known or suspected malicious destination. It remains one layer: provider selection and deployment decisions determine which users are covered, what data is visible, and how easily controls can be bypassed. ## What protective DNS does Source fact: NIST SP 800-81 Rev. 3 treats protective DNS as an additional layer in zero-trust or defense-in-depth risk management. Policy at an enterprise recursive resolver can use domain intelligence and local rules to block or otherwise control resolution of known or suspected malicious destinations while producing DNS evidence for monitoring and investigation. Source fact: NIST addresses protective DNS, DNSSEC, and encrypted DNS as related but distinct safeguards. DNSSEC authenticates DNS data and protects its integrity. DoH, DoT, and DoQ protect DNS messages on supported transport paths. Neither capability alone determines that a domain is safe. DSE analysis: a connection made directly to an IP address may avoid a DNS policy decision entirely. Protective DNS therefore remains one layer; retain complementary endpoint, identity, email, web, firewall, and incident controls. ## Evaluate service and operating evidence DSE recommendation: define requirements before comparing providers: - malicious-domain, phishing, malware, command-and-control, and domain-generation detection; - DNSSEC validation and approved encrypted-DNS support; - alerts, historical logs, dashboards, API or security-platform integration, and investigation workflow; - high availability, performance, outage behavior, support, and change notification; - policies by user, device, group, or network and coverage for roaming, home, branch, and cloud-connected devices; - DNS-query ownership, retention, location, access, security use, and any non-security use by the provider. DSE recommendation: require current provider evidence and validate it in a pilot. Test expected blocking, false-positive release, alerts, query history, role separation, integration, latency, resolver failure, off-network use, and help-desk escalation. Document applications or devices that cannot use the intended architecture. ## Control bypass without breaking operations Where appropriate and tested, direct clients to approved resolvers and constrain unauthorized outbound DNS on port 53, DoT on port 853, and unapproved DoH destinations. Account for internal zones, VPN behavior, guest networks, mobile devices, failover, and applications with embedded resolvers. Continue endpoint, identity, email, web, firewall, and incident controls because protective DNS does not inspect every connection or prove an endpoint is clean. ## Applicability and limits SP 800-81 Rev. 3 is technical deployment guidance, not a provider certification, product test, or ranking. Capabilities and terms change, so buyers must validate current architecture, contract, privacy, performance, support, and risk themselves. NIST added a July 10, 2026 planning note pointing readers to potential errata; review that note before finalizing a design or control baseline. ## Official reference [NIST SP 800-81 Rev. 3](https://csrc.nist.gov/pubs/sp/800/81/r3/final) — current NIST guidance for secure DNS deployment, including protective DNS, resolver policy, logging, and encrypted DNS. ## Primary reference - Name: NIST SP 800-81 Rev. 3: Secure Domain Name System (DNS) Deployment Guide - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/81/r3/final - Source publication date: 2026-03-19 ## Citation and use Preferred citation: “Protective DNS: evaluate the resolver, the data, and the bypass paths,” DSE Security, https://update.dsesecurity.com/updates/protective-dns-provider-selection/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove a network device can be rebuilt from a known-good configuration > A copied running configuration is not yet a recovery capability. Prove that hardware, firmware, licensing, identity, certificates, secrets, dependencies, telemetry, and business traffic can be restored together. - Canonical URL: https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:19:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know A copied running configuration is not yet a recovery capability. Prove that hardware, firmware, licensing, identity, certificates, secrets, dependencies, telemetry, and business traffic can be restored together. ## Potentially affected Routers; switches; firewalls; wireless controllers; load balancers; configuration archives; firmware images; licenses; certificates; secrets; AAA; routing; monitoring; and network recovery plans. ## DSE recommendation Define a complete recovery package for each device class, protect and version it, rebuild representative equipment in isolation, validate management and business traffic, record timing and gaps, and repeat after material change. ## Article ## Source facts: known-good material supports secure device restoration CISA’s [Disable Cisco Smart Install Feature (CM0014)](https://www.cisa.gov/eviction-strategies-tool/info-countermeasures/CM0014) is a countermeasure for a specific legacy Cisco provisioning feature, not a general network-backup standard. CISA says Smart Install can be abused to access, copy, or poison startup configuration files or modify Cisco IOS. When administrators determine that a device was abused, the guidance says to isolate it and restore its image and configuration to a secure state; that may include a known-good configuration backup, a factory reset, and current vendor patches. It also says to preserve a tampered configuration or other evidence during investigation. NIST SP 800-128 describes baselines, change control, configuration monitoring, and the preservation of approved configuration information. CISA’s communications-infrastructure hardening guidance emphasizes secure management, centralized logging, visibility, backups, and preparation for recovery from unauthorized change. A text export alone may not recreate the device. Recovery can depend on compatible hardware, bootloader and firmware, feature licenses, certificates and private keys, secret values omitted from exports, identity services, routing neighbors, controller state, cloud entitlements, cabling, upstream configuration, time, DNS, and vendor-specific restore behavior. A successful command import also does not prove that production services or security controls work. ## DSE recommendation: test a full device recovery package Choose representative critical devices and prove the rebuild in an isolated environment or approved maintenance exercise. Treat every discovered dependency as a corrective action, not an informal note. - Define the recovery target. Record device role, critical services, site, hardware and module identifiers, software train, desired recovery time, acceptable data loss, configuration owner, support status, and approved replacement models. Prioritize devices that are single points of failure or trust boundaries. - Assemble the package. Preserve startup and running configuration, firmware and hashes, boot variables, licenses or entitlement steps, certificates and renewal details, secrets through an approved vault, inventory, diagrams, port mapping, dependencies, console settings, recovery contacts, and a dated known-good reference. - Protect the evidence. Encrypt sensitive backups, separate backup administration from device administration, use immutable or offline copies where appropriate, log access, restrict exports, and verify integrity. Keep recovery material available when normal identity, DNS, network, or cloud control planes are down. - Start from a clean state. Use spare or lab hardware that represents the production class, or a vendor-supported virtual equivalent when it can test the required behavior. Follow the documented initialization path, install the intended firmware, restore entitlement, and import configuration without hidden technician shortcuts. - Validate management. Test console access, named administrator authentication, AAA fallback, role authorization, time, DNS, certificate trust, management routing, configuration archive, logging, monitoring, backups, and alert delivery. Confirm default accounts and unexpected services are not left active. - Validate forwarding and policy. Exercise representative VLANs, routes, redundancy, VPNs, NAT, access policy, inspection, quality of service, multicast, wireless, or load-balancing functions relevant to the device. Confirm failover and recovery rather than testing only a ping to the management address. - Record and repeat. Capture elapsed time, manual decisions, failed steps, unavailable files, incompatible commands, missing secrets, vendor dependencies, and business tests. Update the package and runbook, retest unresolved gaps, and schedule another exercise after material hardware, firmware, identity, licensing, or topology change. Factual boundary: A lab rebuild reduces uncertainty but cannot reproduce every production dependency, traffic pattern, carrier condition, or latent hardware fault. Vendor procedures differ, and some backups are not portable across models or software versions. Confirm support and change requirements for the exact platform. Measure configuration-backup success, integrity verification, recovery-package completeness, tested device classes, rebuild time, manual steps, missing dependencies, business-test pass rate, and age of the last exercise. The meaningful claim is not “we back up the switches.” It is “we have recently rebuilt this class of device from protected material and verified the services it must restore.” ## Official references - CISA, [Disable Cisco Smart Install Feature](https://www.cisa.gov/eviction-strategies-tool/info-countermeasures/CM0014), Countermeasure CM0014. - NIST, [Guide for Security-Focused Configuration Management of Information Systems](https://csrc.nist.gov/pubs/sp/800/128/upd1/final), SP 800-128 Update 1. - CISA, [Enhanced Visibility and Hardening Guidance for Communications Infrastructure](https://www.cisa.gov/resources-tools/resources/enhanced-visibility-and-hardening-guidance-communications-infrastructure). ## Primary reference - Name: CISA Disable Cisco Smart Install Feature (CM0014) - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/eviction-strategies-tool/info-countermeasures/CM0014 - Source publication date: 2025-03-14 ## Citation and use Preferred citation: “Prove a network device can be rebuilt from a known-good configuration,” DSE Security, https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove an AD CS certification authority can be restored—not merely backed up > Validate the complete Certification Authority recovery set, including database, private keys, configuration, templates, revocation publishing, and HSM steps. - Canonical URL: https://update.dsesecurity.com/updates/prove-ad-cs-certification-authority-restore/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:22+00:00 - Modified: 2026-08-26T13:27:46+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Validate the complete Certification Authority recovery set, including database, private keys, configuration, templates, revocation publishing, and HSM steps. ## Potentially affected Organizations operating Microsoft Active Directory Certificate Services certification authorities ## DSE recommendation Perform an isolated CA restore rehearsal using protected backups and verify issuance, revocation, publication, and relying-party validation. ## Article A CA database copy without its private key, configuration, publication paths, and hardware-security-module procedure may be impossible to use safely. The recovery proof is a functioning isolated CA and validated certificate lifecycle, not a green backup job. ## Source fact: [Microsoft’s Windows Server guidance](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/migrate-certification-authority) for migrating an Active Directory Certificate Services certification authority identifies the artifacts needed to move and restore CA operation. Its process includes backing up the CA database and private key, exporting CA registry settings, retaining CAPolicy.inf where used, recording enterprise certificate templates, and preserving information needed for certificate-revocation-list publication. It also directs customers using a hardware security module to follow the HSM vendor’s backup procedure. The guidance describes restoring the CA role and data and then verifying the migrated service. Although framed as migration, those documented dependencies are directly relevant to recovery planning. Successful restoration of files alone does not prove that issuance, revocation, enrollment, chain building, or relying-party access to CRLs works. ## Boundary The exact process depends on supported Windows Server versions, CA type and hierarchy, cryptographic provider, HSM, key exportability, host identity, database state, extensions, publication URLs, Active Directory, web enrollment, NDES, OCSP, and custom integrations. Microsoft guidance and HSM-vendor procedures must be checked for the exact environment. A recovery exercise must not create a second active CA with the same identity in production or publish test revocation data into live paths. ## Applicability questions - Which root, policy, issuing, and subordinate CAs exist, and what order must they recover? - Where are CA database, private key, registry settings, CAPolicy.inf, templates, HSM material, and passwords protected? - Which DNS, HTTP, LDAP, file, OCSP, and firewall paths publish or serve chain and revocation information? - Can recovery operators access media and HSM support without the failed identity infrastructure? - What issuance pause prevents conflicting database or serial-number state? ## DSE recommendation: Document the CA topology and collect the supported backup set through an approved, protected process. Separate private-key material from ordinary operational backups and test access by authorized recovery roles. Preserve installed role services, configuration, URLs, templates, service identities, HSM dependencies, and recovery order. Establish criteria for declaring the original CA unavailable before an alternate instance can issue. Restore into an isolated network with production publication blocked. Confirm service start, database integrity, CA identity, key access, extensions, templates, and configuration. Issue a test certificate from a dedicated template, revoke it, publish a test CRL to an isolated endpoint, and validate both the good and revoked states from a representative relying party. Measure the process and correct undocumented dependencies before destroying the exercise environment securely. ## Verification and evidence Keep backup logs, media inventory, key-custody approvals, configuration exports, HSM procedure and test evidence, restore transcript, CA identity checks, issued and revoked test certificates, CRL validation, relying-party results, recovery time, and improvements. Do not place private keys or passwords in the evidence package. Repeat after CA renewal, HSM, OS, hierarchy, template, or publication-path changes. ## Official references - [Microsoft Learn: Migrate a certification authority](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/migrate-certification-authority) ## Primary reference - Name: Migrate a certification authority in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/migrate-certification-authority - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove an AD CS certification authority can be restored—not merely backed up,” DSE Security, https://update.dsesecurity.com/updates/prove-ad-cs-certification-authority-restore/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove BitLocker Network Unlock across firmware, DHCP, and WDS > Use Network Unlock to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/prove-bitlocker-network-unlock-across-dependencies/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:48+00:00 - Modified: 2026-08-27T13:01:31+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Use Network Unlock to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Network Unlock ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Prove BitLocker Network Unlock across firmware, DHCP, and WDS. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Network Unlock](https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/network-unlock) from Microsoft supports the following bounded statements: - Network Unlock can automatically unlock BitLocker OS volumes on a wired corporate network during reboot. The research record locates this support at Opening overview. - It requires compatible UEFI DHCP support and combines a TPM-held key with network key material handled by the unlock server. The research record locates this support at Opening overview; sections: System requirements; Network Unlock sequence. Only the traced statements above are asserted as source facts. Apply the review to Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows after confirming that the source and deployed context match. ## What the source does not establish Treat firmware, DHCP, certificate, WDS, and network reachability as one tested dependency chain. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview; sections: System requirements; Network Unlock sequence, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows security controls, protected identities, audit policy, telemetry, exclusions, administrative roles, and response workflows, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, certificate trust, time, endpoint management, telemetry pipelines, and security operations, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Opening overview; sections: System requirements; Network Unlock sequence through policy and feature state, security events, test detections, administrative assignments, exception approvals, and response tickets. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Network Unlock](https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/network-unlock) — Microsoft ## Primary reference - Name: Network Unlock - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/network-unlock - Source publication date: 2025-07-29 ## Citation and use Preferred citation: “Prove BitLocker Network Unlock across firmware, DHCP, and WDS,” DSE Security, https://update.dsesecurity.com/updates/prove-bitlocker-network-unlock-across-dependencies/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove Cluster-Aware Updating against the workload—not just the cluster > Cluster-Aware Updating orchestrates node maintenance, role movement, patching, restart, and return, but many clustered workloads can still experience a planned-failover interruption. - Canonical URL: https://update.dsesecurity.com/updates/windows-cluster-aware-updating-workload-proof/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:03+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Cluster-Aware Updating orchestrates node maintenance, role movement, patching, restart, and return, but many clustered workloads can still experience a planned-failover interruption. ## Potentially affected Windows Server failover clusters and Azure Local systems using or considering Cluster-Aware Updating. ## DSE recommendation Run readiness checks, preview each update run, test workload failover under realistic load, define stop conditions, and retain node and service evidence for every run. ## Article Bottom line: Cluster-Aware Updating (CAU) automates the sequence of draining a node, moving clustered roles, installing updates, restarting if needed, restoring roles, and advancing to the next node. Microsoft states that many clustered roles can experience a transient interruption during planned failover. Availability must be proven at the client and workload, not inferred from a successful CAU run. ## Source fact: what Microsoft documents Microsoft’s [CAU overview](https://learn.microsoft.com/en-us/windows-server/failover-clustering/cluster-aware-updating) describes remote-updating and self-updating modes for Windows Server failover clusters. During an updating run, CAU places a node in maintenance, moves roles, applies updates and dependencies, restarts when necessary, exits maintenance, restores roles, and repeats for the next node. The feature integrates with Windows Update Agent and WSUS through a built-in plug-in and has another built-in hotfix plug-in, plus an extensibility model. Updating Run Profiles hold settings such as retry behavior, and the tools can preview, apply, monitor, and report updates. Microsoft says continuously available Hyper-V and SMB Transparent Failover workloads can be coordinated with no service impact in supported designs, while many other clustered roles can experience a transient client interruption. Requirements and best-practice validation apply. ## What the source does not establish CAU does not make a workload continuously available, prove application retry behavior, validate database consistency, or guarantee every update is cluster-compatible. A green cluster state after a node returns does not establish that client transactions, storage, networking, replication, monitoring, backup, and dependencies are healthy. A third-party plug-in also requires separate validation. ## Applicability questions - Which Windows Server or Azure Local version, cluster type, workload, update source, and CAU mode are used? - Can each role move cleanly, and what do clients observe during planned failover? - Is capacity sufficient to drain one node under peak load and during another component fault? - Which pre-update and post-update checks, scripts, retries, and stop conditions are required? - Do firmware, drivers, agents, databases, and third-party plug-ins have their own sequencing or support requirements? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Run Microsoft’s CAU readiness and cluster validation checks and resolve warnings that affect the intended workload. - Exercise planned role movement and node restart under representative load before scheduling automated patching. - Define a run profile with maintenance window, retries, stop conditions, node order, update source, and evidence capture. - Preview the run, review updates and dependencies, and have workload owners approve application-specific risks. - Monitor client transactions, cluster roles, storage, network, replication, and applications throughout the run and after every node. ## Verification and evidence - Preserve CAU mode, run profile, preview, update list, validation output, approvals, and rollback decision. - Capture node drain, role movement, update, restart, return, and run-report events. - Record client-visible interruption, transaction results, latency, capacity, and application health. - Confirm every node has the intended update state and the cluster has no unexpected owner, storage, or network condition. ## Official references - [Cluster-Aware Updating overview](https://learn.microsoft.com/en-us/windows-server/failover-clustering/cluster-aware-updating) — Microsoft ## Primary reference - Name: Cluster-Aware Updating overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/cluster-aware-updating - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove Cluster-Aware Updating against the workload—not just the cluster,” DSE Security, https://update.dsesecurity.com/updates/windows-cluster-aware-updating-workload-proof/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove DHCP renewal and rebinding before shortening lease time > Test DHCP client state transitions, relay paths, capacity, and server failover before using shorter leases for operational flexibility. - Canonical URL: https://update.dsesecurity.com/updates/prove-dhcp-renewal-and-rebinding/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:41+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Test DHCP client state transitions, relay paths, capacity, and server failover before using shorter leases for operational flexibility. ## Potentially affected IPv4 networks that rely on DHCP for endpoint addressing, including relayed and redundant-server designs ## DSE recommendation Measure renewal and rebinding behavior with representative clients and failure scenarios before changing lease duration or server topology. ## Article A shorter DHCP lease can speed address reuse or policy changes, but it also increases normal renewal traffic and reduces the time clients can continue through a server or relay outage. The safe value comes from observed client and infrastructure behavior. ## Source fact: [IETF RFC 2131](https://www.rfc-editor.org/rfc/rfc2131.html) defines DHCP for allocating reusable network addresses and delivering configuration parameters to hosts. A client obtains a lease and moves through defined states. While BOUND, it can begin renewal with the server that supplied the lease. If renewal does not succeed, the client later enters REBINDING and can seek an extension from any available DHCP server. If the lease ultimately expires without renewal, the client must stop using the address. The protocol includes lease-time and renewal/rebinding timing information supplied through DHCP options. It also supports relay agents so clients on one subnet can reach servers elsewhere. These mechanisms explain the protocol sequence; they do not establish a particular organization’s server capacity, relay availability, address-pool size, or endpoint implementation quality. ## Boundary This article addresses DHCP for IPv4. DHCPv6 has different specifications and must be assessed separately. Client implementations may retry, sleep, roam, or cache configuration differently. DHCP server failover behavior is product- or protocol-specific and is not proven by RFC 2131 alone. A successful lease does not prove that DNS registration, network-access policy, default gateway, or application reachability is correct. ## Applicability questions - Which subnets, device classes, and occupancy patterns drive peak lease demand? - Are relay agents, routing paths, security rules, and both servers independent enough for the claimed resilience? - How do sleeping, wireless, voice, building, and minimally managed clients renew and rebind? - How much outage tolerance does the proposed lease leave after accounting for client timing? - Can monitoring distinguish pool exhaustion, relay failure, server failure, and client rejection? ## DSE recommendation: Baseline leases issued per minute, renewal rates, pool utilization, conflicts, declines, and server resource use across normal and peak periods. Segment results by scope and client class. In a representative test network, observe packet-level behavior through initial allocation, renewal, rebinding, server loss, relay loss, restoration, and lease expiry. Include clients that sleep or leave the network during the sequence. Model the increased request rate and reduced outage window before shortening a lease. Change a limited set of scopes first, watch server and relay capacity, and maintain adequate address headroom. Verify server redundancy according to the specific product’s supported design. Coordinate dynamic DNS, network access control, IP address management, and logging dependencies so that faster churn does not create stale identity data. ## Verification and evidence Retain scope configurations, pool and request baselines, server and relay inventories, synchronized packet captures, client state timelines, outage-test results, and capacity alerts. Evidence should show that representative clients retain or regain valid configuration within the accepted objective and that the address pool remains healthy. Record exact lease settings and test dates so results are not reused after a material change. ## Official references - [IETF RFC 2131](https://www.rfc-editor.org/rfc/rfc2131.html) ## Primary reference - Name: RFC 2131: Dynamic Host Configuration Protocol - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2131.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove DHCP renewal and rebinding before shortening lease time,” DSE Security, https://update.dsesecurity.com/updates/prove-dhcp-renewal-and-rebinding/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove dMSA migration through account and event evidence > Use Setting up delegated Managed Service Accounts (dMSA) in Windows Server 2025 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/prove-dmsa-migration-through-account-and-event-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:40+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Setting up delegated Managed Service Accounts (dMSA) in Windows Server 2025 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Setting up delegated Managed Service Accounts (dMSA) in Windows Server 2025 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Prove dMSA migration through account and event evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Setting up delegated Managed Service Accounts (dMSA) in Windows Server 2025](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-set-up-dmsa) from Microsoft supports the following bounded statements: - AD automatically manages dMSA credentials instead of requiring manual password administration. The research record locates this support at Opening overview. - The setup workflow covers creation, migration completion, and review of dMSA event logs. The research record locates this support at Sections: Create a standalone dMSA; Complete account migration; View dMSA event logs. Only the traced statements above are asserted as source facts. Apply the review to forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles after confirming that the source and deployed context match. ## What the source does not establish Only supported Windows Server 2025 workloads should enter the migration pilot. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: Create a standalone dMSA; Complete account migration; View dMSA event logs, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations Opening overview; Sections: Create a standalone dMSA; Complete account migration; View dMSA event logs adjacent to the sanitized artifacts used for comparison. Prefer directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Setting up delegated Managed Service Accounts (dMSA) in Windows Server 2025](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-set-up-dmsa) — Microsoft ## Primary reference - Name: Setting up delegated Managed Service Accounts (dMSA) in Windows Server 2025 - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-set-up-dmsa - Source publication date: 2025-05-30 ## Citation and use Preferred citation: “Prove dMSA migration through account and event evidence,” DSE Security, https://update.dsesecurity.com/updates/prove-dmsa-migration-through-account-and-event-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove frame rate at the recorder, not only at the camera > A camera setting does not guarantee the same frame rate reaches storage. Validate the entire path under representative load and with production image features enabled. - Canonical URL: https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:36:09+00:00 - Modified: 2026-08-25T21:36:16+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Briefing - DSE priority: Important - Topics: Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know A camera setting does not guarantee the same frame rate reaches storage. Validate the entire path under representative load and with production image features enabled. ## Potentially affected Systems with evidentiary or analytic tasks that depend on a controlled minimum frame rate through cameras, networks, recorders, and clients. ## DSE recommendation Measure recorded frame cadence during the hardest production condition and record any feature, network, or VMS setting that can reduce it. ## Article Bottom line: the frame-rate value shown in a camera interface is an instruction or limit, not proof of the cadence stored by the recorder. Processing load, competing streams, network capacity, VMS configuration, and recording load can change the result. ## Source fact: full frame rate depends on the complete system Axis’s [Controlled full frame rate](https://whitepapers.axis.com/en-us/controlled-full-frame-rate) paper states that a configured frame rate cannot be guaranteed through a system without sufficient capacity across the path. It identifies camera features and processing demands that may affect available performance, including analytics, electronic image stabilization, audio, and distortion correction. It also notes that VMS configuration can alter device settings. The acceptance point is therefore the recorded and retrievable result. A live client can look smooth while the archive is thinner, or a recorder can meet the target during daytime and fall below it when night processing and motion increase. ## Source boundary and applicability The paper describes Axis technology and considerations; it is not a performance guarantee for any product combination. The necessary cadence depends on the security task, exposure time, motion, compression, resolution, scene complexity, and whether an analytics engine samples the same stream. A higher number is not automatically better evidence. ## Applicability questions - What minimum recorded cadence does the observation, recognition, transaction, or forensic task actually require? - Which stream is archived, and can the VMS override camera frame-rate or profile settings? - Which features are enabled simultaneously on the camera? - What are the peak camera, switch, uplink, recorder, storage, and client loads? - Do event mode, low light, multiple viewers, or an export change performance? ## DSE recommendation: test cadence where evidence is consumed The following steps are DSE recommendations based on the cited source. Define the required minimum from the operational task, then stage representative motion with production resolution, exposure, compression, analytics, stabilization, audio, privacy, and secondary streams enabled. Create normal and peak-load tests, including the lighting condition that produces the highest processing or bitrate demand. Retrieve the archive through the normal investigator workflow and measure actual presentation timestamps or inter-frame intervals rather than judging smoothness by eye. If the target is missed, change one constrained resource or feature at a time and document the tradeoff. Protect the accepted camera profile from undocumented VMS overwrites. Use change control because reducing exposure, resolution, analytics, or other image functions may solve cadence while degrading the original task. ## Verification and evidence Retain the task requirement, camera and recorder exports, feature list, topology, utilization samples, retrieved native clip, measurement method, measured minimum and distribution, test scene, and approval of any tradeoff. Repeat after firmware, VMS, stream-profile, analytics, switch, server, or storage changes. ## Official references - [Controlled full frame rate](https://whitepapers.axis.com/en-us/controlled-full-frame-rate) – Axis Communications ## Primary reference - Name: Controlled full frame rate - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/controlled-full-frame-rate - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove frame rate at the recorder, not only at the camera,” DSE Security, https://update.dsesecurity.com/updates/prove-frame-rate-at-the-recorder-not-only-at-the-camera/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove in-building responder radio coverage without creating interference > An emergency responder communications enhancement system must serve the frequencies and critical areas approved by the authority and license holder while controlling oscillation, unwanted emissions, power, supervision, and maintenance. - Canonical URL: https://update.dsesecurity.com/updates/prove-responder-radio-coverage-without-creating-interference/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:28:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity - Reading time: 3 minutes ## What you need to know An emergency responder communications enhancement system must serve the frequencies and critical areas approved by the authority and license holder while controlling oscillation, unwanted emissions, power, supervision, and maintenance. ## Potentially affected Public-safety radio coverage inside buildings, bi-directional amplifiers, distributed antenna systems, donor and interior antennas, coaxial cable, survivability, standby power, fire alarm supervision, permits, acceptance tests, annual tests, and building alterations. ## DSE recommendation Engage the authority having jurisdiction and frequency license holder before design, measure the building with approved methods, install only the authorized listed solution, acceptance-test coverage and interference controls, and maintain a controlled retest baseline. ## Article ## Source facts: responder communications systems require coordinated approval and testing [NFPA 1225, 2022 edition](https://link.nfpa.org/all-publications/655/2022), addresses emergency services communications and includes requirements for in-building emergency responder communications enhancement systems. These systems combine radio-frequency devices, antennas, cabling, power supplies, control circuitry, and programming to improve responder communications in and around a structure. The standard involves both the authority having jurisdiction and the frequency license holder. That coordination matters because the public-safety radio system belongs to an authorized licensee, and an in-building amplifier can affect coverage beyond the property. Design, component approval, installation, acceptance, permits, inspection, testing, supervision, and maintenance are connected responsibilities rather than separate purchases. NFPA 1225 does not establish that every building needs an enhancement system. The adopted fire code, authority having jurisdiction, frequency license holder, approved radio coverage criteria, FCC rules, and measured building performance determine the requirement and solution. Edition, local amendments, critical-area definitions, test grids, signal thresholds, and permit conditions vary. Only qualified and appropriately licensed parties should design or adjust radio-frequency equipment. ## DSE recommendation: commission a governed radio path, not a signal booster Begin with written contacts for the fire-code official, public-safety radio system owner or frequency license holder, system designer, installer, testing party, building owner, and fire alarm provider. Obtain current frequencies, technologies, coverage criteria, approved equipment requirements, test protocol, documentation format, and notification rules directly from the responsible authorities. - Prove the need. Survey the completed or representative building with calibrated equipment and the approved grid and procedure. Include designated critical areas such as command locations, fire-service access, stairs, elevator lobbies, equipment rooms, and other spaces identified by the authority. Preserve readings and floor plans. - Design for the actual radio system. Model donor signal, building loss, cable loss, antenna placement, required coverage, isolation, gain, noise, and potential interaction with neighboring sites. Separate public-safety requirements from commercial cellular or private-radio expectations. - Control the physical installation. Verify listed or approved components, pathway and cable protection, grounding and bonding, equipment-room access, environmental limits, labeling, antenna security, survivability, standby power, and required monitoring. Protect donor and interior antennas from later movement or obstruction. - Test harm as well as benefit. Acceptance testing should demonstrate required inbound and outbound coverage while checking oscillation, noise, unwanted emissions, gain behavior, interference, power transfer, battery duration, charger condition, alarms, supervisory signals, and shutdown or disable functions required by the authority or license holder. - Give alarms an owner. Route system trouble, component failure, antenna or cable fault, charger failure, and loss of normal power to a location that is actually monitored. Define who acknowledges, who may investigate, when authorities must be notified, and what interim response applies. - Preserve the baseline. Retain permits, approvals, frequency and technology data, design calculations, equipment and firmware, antenna locations, cable routes, test grids, calibrated-instrument records, acceptance results, alarm mapping, battery data, and approved settings. Restrict unauthorized access without making emergency maintenance impossible. Reassess after interior partitions, low-emissivity glazing, metal storage, structural additions, elevator or mechanical changes, roof work, antenna movement, radio-system changes, equipment replacement, water intrusion, lightning, or repeated responder complaints. A passing annual indicator does not reveal every material building change. Never let a contractor increase gain simply to improve a weak reading. Changes should follow the approved diagnostic and notification process and be retested for interference. A trustworthy enhancement system is invisible during ordinary operations but fully governed: authorities know it exists, responders receive usable coverage, faults are supervised, and the wider public-safety network remains protected. Give responding agencies a current equipment-room contact and access method that works after hours without publishing sensitive radio details to the general public. ## Official references - National Fire Protection Association, [NFPA 1225, Standard for Emergency Services Communications](https://link.nfpa.org/all-publications/655/2022), 2022 edition. - Federal Communications Commission, [Signal Boosters](https://www.fcc.gov/wireless/bureau-divisions/mobility-division/signal-boosters), regulatory information. ## Primary reference - Name: NFPA 1225: Standard for Emergency Services Communications, 2022 edition - Authority: National Fire Protection Association - URL: https://link.nfpa.org/all-publications/655/2022 - Source publication date: 2022-01-01 ## Citation and use Preferred citation: “Prove in-building responder radio coverage without creating interference,” DSE Security, https://update.dsesecurity.com/updates/prove-responder-radio-coverage-without-creating-interference/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove infrared imagery on the real materials and distances > Infrared reflectance differs from visible appearance. Test clothing, plates, surfaces, weather, and target distances in the actual night mode before relying on the image. - Canonical URL: https://update.dsesecurity.com/updates/prove-infrared-imagery-on-real-materials-and-distances/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:57+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Advisory - Topics: Video Surveillance - Reading time: 2 minutes ## What you need to know Infrared reflectance differs from visible appearance. Test clothing, plates, surfaces, weather, and target distances in the actual night mode before relying on the image. ## Potentially affected Day/night cameras using integrated or separate infrared illuminators for perimeter, parking, entrance, indoor dark-area, or evidentiary coverage. ## DSE recommendation Commission IR coverage with representative subjects and surfaces across the full field, and document where monochrome appearance changes or glare limit the security task. ## Article Bottom line: an object that appears dark, light, or distinctive to a person under visible light may look different in infrared. Night acceptance should use the materials, distances, weather, and camera modes that the actual investigation will face. ## Source fact: IR appearance and illumination behavior differ from visible light The Axis paper [IR in surveillance](https://whitepapers.axis.com/en-us/ir-in-surveillance) explains that a day/night camera removes its IR-cut filter and produces a monochrome image in IR mode. It notes that dark clothing can appear lighter under IR, discusses 850 nm and 940 nm illumination, and distinguishes integrated from standalone illumination. It also describes how a beam that does not match the camera view can create glare or leave inadequate coverage. These differences affect description and comparison. An operator should not infer visible color from a monochrome IR recording, and a daytime acceptance clip does not establish nighttime subject detail. ## Source boundary and applicability The paper is Axis guidance, not a guarantee for a camera, illuminator, material, or weather condition. Spectral response, filter behavior, wavelength, lens, exposure, subject reflectance, distance, moisture, insects, windows, domes, and nearby surfaces affect results. Thermal imaging is a different technology and should not be evaluated as reflected IR illumination. ## Applicability questions - Is the task detection, recognition, identification, plate capture, or event reconstruction? - Which visible colors or material differences might investigators incorrectly infer from the IR image? - Does the illuminator beam match the full field at the required distances? - Can walls, signs, plates, rain, fog, dust, or the camera cover cause backscatter or overexposure? - Is the night-mode transition timely, stable, and recorded with the expected settings? ## DSE recommendation: run an IR material-and-distance trial The following steps are DSE recommendations based on the cited source. Select representative clothing, vehicles, markings, signs, badges, and other task materials without using sensitive personal data unnecessarily. Record controlled passes at the nearest, nominal, and farthest points, including field edges and reflective backgrounds. Test the darkest normal condition and representative adverse conditions where safe and practical. Retrieve the archive and score only facts supportable from the IR image. Document that monochrome tone is not verified visible color. Adjust illumination, beam, camera position, exposure, or add targeted coverage if glare or falloff defeats the task. Train operators and investigators on these documented limitations so incident notes distinguish an observed infrared tone from a verified color or material characteristic. ## Verification and evidence Keep the scene plan, camera and illuminator models, wavelength, settings, distances, ambient and weather conditions, material list, native clips, task scores, transition timing, and accepted limitations. Re-test after cleaning, seasonal change, landscaping, housing, illuminator, camera, or exposure changes. ## Official references - [IR in surveillance](https://whitepapers.axis.com/en-us/ir-in-surveillance) – Axis Communications ## Primary reference - Name: IR in surveillance - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/ir-in-surveillance - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove infrared imagery on the real materials and distances,” DSE Security, https://update.dsesecurity.com/updates/prove-infrared-imagery-on-real-materials-and-distances/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove permit-space isolation, entry, rescue, and cancellation workflows > Use 29 CFR 1910.146 - Permit-required confined spaces to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/prove-permit-space-isolation-entry-rescue-and-cancellation-workflows/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:21+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.146 - Permit-required confined spaces to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.146 - Permit-required confined spaces ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Prove permit-space isolation, entry, rescue, and cancellation workflows. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.146 – Permit-required confined spaces](https://www.ecfr.gov/current/title-29/section-1910.146) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, a permit-space program must designate active roles, define each role’s duties, and give those employees the training required by paragraph (g). The research record locates this support at 29 CFR 1910.146(d)(8), read with 29 CFR 1910.146(d) (eCFR anchor p-1910.146(d)(8)). - Under 29 CFR 1910, an employer must let each authorized entrant or representative observe pre-entry and later permit-space testing or monitoring. The research record locates this support at 29 CFR 1910.146(d)(5)(iv), read with 29 CFR 1910.146(d)(5) (eCFR anchor p-1910.146(d)(5)(iv)). The source support ends with the statements listed above. Use them to examine critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Federal workplace rule; space classification, hazards, alternate procedures, contractor coordination, and rescue capability require site-specific competent evaluation. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.146(d)(8), read with 29 CFR 1910.146(d) (eCFR anchor p-1910.146(d)(8)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.146(d)(5)(iv), read with 29 CFR 1910.146(d)(5) (eCFR anchor p-1910.146(d)(5)(iv)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 29 CFR 1910.146(d)(8), read with 29 CFR 1910.146(d) (eCFR anchor p-1910.146(d)(8)); 29 CFR 1910.146(d)(5)(iv), read with 29 CFR 1910.146(d)(5) (eCFR anchor p-1910.146(d)(5)(iv)). Favor facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [29 CFR 1910.146 – Permit-required confined spaces](https://www.ecfr.gov/current/title-29/section-1910.146) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.146 - Permit-required confined spaces - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.146 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove permit-space isolation, entry, rescue, and cancellation workflows,” DSE Security, https://update.dsesecurity.com/updates/prove-permit-space-isolation-entry-rescue-and-cancellation-workflows/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove Profile A credential and schedule administration end to end > ONVIF Profile A covers selected access-control configuration functions. Test creation, update, revocation, scheduling, and events across the exact client and device. - Canonical URL: https://update.dsesecurity.com/updates/prove-profile-a-credential-and-schedule-administration-end-to-end/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:39+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Access Control, Cybersecurity - Reading time: 2 minutes ## What you need to know ONVIF Profile A covers selected access-control configuration functions. Test creation, update, revocation, scheduling, and events across the exact client and device. ## Potentially affected Multi-vendor PACS integrations relying on ONVIF Profile A for credentials, schedules, access rules, and access-control events. ## DSE recommendation Verify claimed Profile A conformance and run reversible lifecycle tests across the exact versions before accepting administrative interoperability. ## Article Bottom line: Profile A defines a useful interoperability boundary, not a promise that two products implement every administrative workflow identically. Acceptance should prove that an authorized change becomes the intended door decision and can be reversed and audited. ## Source fact: Profile A covers selected access-control configuration The official [ONVIF Profile A](https://www.onvif.org/profiles/onvif-profile-a/) page describes profile functions for access-control configuration. Its overview includes credentials, schedules, access rules, and events, with features identified as mandatory or conditional for conformant devices and clients. That feature model matters when evaluating a client-device pair. A function can be conditional, a client can expose only part of the model, or a product can be conformant while a local workflow depends on an extension outside Profile A. ## Source boundary and applicability The ONVIF page describes the profile and conformance concepts; it does not certify an unnamed product, prove two releases interoperate, or validate cybersecurity, database migration, door hardware, life safety, or identity governance. Check the official ONVIF conformant-products database and each vendor’s exact model, version, and supported feature statement. Profile A is not a substitute for Profile C or other interfaces where different functions are needed. ## Applicability questions - Are both the client and device officially conformant for the exact product and version? - Which required fields and functions are mandatory, conditional, or vendor-specific? - How are person identity, credential token, schedule, access rule, door, and event identifiers mapped? - What happens to existing assignments when a credential or schedule is updated or deleted? - Are administrative operations authenticated, authorized, encrypted, logged, and recoverable? ## DSE recommendation: test the complete reversible lifecycle The following steps are DSE recommendations based on the cited source. Build a requirements-to-profile matrix and mark each necessary operation as mandatory, conditional, or outside the profile. In a test tenant or approved maintenance window, create a test credential, assign a narrow rule and schedule, confirm entry only at the intended door and time, change the schedule, revoke the credential, and delete the test objects. Observe both client and device state after each step. Test duplicate identifiers, invalid values, clock differences, partial communication failure, controller offline operation, and resynchronization. Protect production doors with rollback, life-safety coordination, and a known mechanical or operational recovery path. Repeat the final test from a second authorized administrative client to expose hidden local caching or client-specific state before declaring the interface portable. ## Verification and evidence Retain official conformance records, version inventory, feature matrix, sanitized API or application logs, before-and-after object exports, access events, offline and recovery results, negative tests, rollback evidence, and acceptance signatures. Record every vendor extension needed so future replacement does not assume it is portable. ## Official references - [ONVIF Profile A](https://www.onvif.org/profiles/onvif-profile-a/) – ONVIF ## Primary reference - Name: ONVIF Profile A - Authority: ONVIF - URL: https://www.onvif.org/profiles/onvif-profile-a/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove Profile A credential and schedule administration end to end,” DSE Security, https://update.dsesecurity.com/updates/prove-profile-a-credential-and-schedule-administration-end-to-end/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove Profile C door commands, state, and alarms as one workflow > ONVIF Profile C addresses site information, door control, and event or alarm management. Verify that command, physical state, and returned event stay consistent. - Canonical URL: https://update.dsesecurity.com/updates/prove-profile-c-door-commands-state-and-alarms-as-one-workflow/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:38+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Access Control, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know ONVIF Profile C addresses site information, door control, and event or alarm management. Verify that command, physical state, and returned event stay consistent. ## Potentially affected Multi-vendor access-control integrations relying on ONVIF Profile C to control doors and consume physical-access events or alarms. ## DSE recommendation Run command-to-physical-state-to-event tests for every required door action and fault, including lost communications and restoration. ## Article Bottom line: a successful unlock command is only one-third of an access-control workflow. The integrator must also establish the actual lock and door state and confirm that the expected event or alarm returns to the consuming system. ## Source fact: Profile C spans door control and event management The official [ONVIF Profile C](https://www.onvif.org/profiles/onvif-profile-c/) page describes interoperability for physical access control. Its feature overview includes site information, door access control, and event and alarm management for conformant devices and clients. These functions form a chain but are not identical. A controller can accept a command while the lock does not release, the door-position input can disagree with the commanded state, or an alarm can be delayed or mapped to the wrong opening. ## Source boundary and applicability The profile page does not certify a product not present in the official conformance database, guarantee interoperability between exact releases, or approve a door’s fire, egress, accessibility, or security design. It also does not prove field wiring, sensor calibration, lock power, time synchronization, event retention, or cyber hardening. Required features and conditional behavior need product-level confirmation. ## Applicability questions - Which exact client and device versions claim Profile C conformance? - Which door commands, modes, states, and alarms are required by the operating concept? - How do ONVIF tokens map to local door, lock, sensor, and alarm identities? - What is the authoritative state when command response, lock feedback, and door contact disagree? - What is queued, lost, or repeated during communication failure and recovery? ## DSE recommendation: accept a three-part round trip The following steps are DSE recommendations based on the cited source. For every required operation, define the request, expected response, permitted physical transition, expected sensor state, event name, maximum timing, and operator display. Test authorized momentary unlock, relock, held-open and forced-open conditions, invalid command, unavailable device, and restoration. Use a safe test doorway or approved window with fire/life-safety and facility owners present. Observe the door and electrical feedback independently; do not accept an API success message as proof of movement. Verify duplicate and out-of-order events, time alignment, acknowledgement, retention, and client reconnection. Document vendor extensions and any condition that the profile does not carry. Include a no-motion test in which the controller accepts or rejects a request but the physical door cannot reach the expected state. Confirm the client displays the discrepancy and routes it to a responsible operator rather than reporting a completed unlock from command status alone. ## Verification and evidence Retain official conformance records, version and topology inventory, token mapping, test matrix, sanitized commands and responses, controller and client logs, physical observations, sensor measurements, alarm timing, failure and recovery results, rollback evidence, and acceptance signatures. ## Official references - [ONVIF Profile C](https://www.onvif.org/profiles/onvif-profile-c/) – ONVIF ## Primary reference - Name: ONVIF Profile C - Authority: ONVIF - URL: https://www.onvif.org/profiles/onvif-profile-c/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove Profile C door commands, state, and alarms as one workflow,” DSE Security, https://update.dsesecurity.com/updates/prove-profile-c-door-commands-state-and-alarms-as-one-workflow/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove supervised door inputs by opening and shorting the circuit > A normal door-contact test does not prove line supervision. Commission the exact controller and resistor scheme by creating safe open- and short-circuit faults. - Canonical URL: https://update.dsesecurity.com/updates/prove-supervised-door-inputs-by-opening-and-shorting-the-circuit/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:36+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Access Control - Reading time: 3 minutes ## What you need to know A normal door-contact test does not prove line supervision. Commission the exact controller and resistor scheme by creating safe open- and short-circuit faults. ## Potentially affected AXIS A1610 Network Door Controller installations using supervised door monitor, request-to-exit, or other inputs with end-of-line resistors. ## DSE recommendation Verify resistor placement and configured values, then create controlled normal, active, open-line, and short-line states and confirm distinct alarms reach the operator. ## Article Bottom line: seeing door open and door closed proves only two functional states. A supervised circuit is intended to distinguish expected operation from wiring faults or tampering, so acceptance must include controlled fault states at the end of the installed run. ## Source fact: the A1610 supports supervised inputs with end-of-line resistors The [AXIS A1610 Network Door Controller User Manual — Supervised inputs](https://help.axis.com/en-us/axis-a1610#supervised-inputs) documents supervised door-monitor and input connections using end-of-line resistors. It identifies supported resistor configurations and describes alarm behavior for an interrupted connection. The physical placement of the resistor matters. A resistor fitted inside the controller cabinet can make the panel see an expected value while leaving most of the field cable and contact outside the supervised boundary. ## Source boundary and applicability The manual applies to the A1610 and the documented hardware/firmware context. Terminal functions, resistor values, wiring limits, alarm names, and configuration differ across controllers and products. This article does not authorize live shorting, bypassing, or modifying energized field wiring. Qualified access-control and electrical personnel must use the exact manual, site design, and safe work procedure. ## Applicability questions - Which inputs are configured as supervised and which resistor scheme is documented for each? - Are the end-of-line components physically located at the monitored device or another approved endpoint? - Can the system distinguish normal, active, open, and short conditions? - Which event name, priority, notification, and ticket should each fault create? - Does an offline controller retain and forward the fault after reconnection? ## DSE recommendation: commission electrical state through operator response The following steps are DSE recommendations based on the cited source. Compare drawings, actual termination, configured supervision type, and the exact current manual before testing. In an approved maintenance window, have qualified personnel create each state with a supported test method at the field endpoint: normal, active, open-line, and short-line. Protect life safety, maintain alternate monitoring, and restore the circuit after every test. At the same time, verify controller indication, server event, operator alarm, timestamp, door identity, notification, acknowledgement, and recovery. Confirm a fault does not masquerade as an ordinary door opening or silently clear without history. Correct resistor placement and mapping under change control. Repeat one test at the cabinet and one at the field endpoint when the approved design allows it. Different results can reveal that only part of the installed conductor is supervised. ## Verification and evidence Retain approved point schedules, exact product and firmware, resistor and wiring documentation, photographs of authorized terminations, instrument or test method, event logs for every state, notification and acknowledgement evidence, restoration check, deficiency tickets, and qualified acceptance. Do not publish sensitive wiring details broadly. ## Official references - [AXIS A1610 Network Door Controller User Manual — Supervised inputs](https://help.axis.com/en-us/axis-a1610#supervised-inputs) – Axis Communications ## Primary reference - Name: AXIS A1610 Network Door Controller User Manual — Supervised inputs - Authority: Axis Communications - URL: https://help.axis.com/en-us/axis-a1610#supervised-inputs - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove supervised door inputs by opening and shorting the circuit,” DSE Security, https://update.dsesecurity.com/updates/prove-supervised-door-inputs-by-opening-and-shorting-the-circuit/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove the PoE system at its worst moment > A PoE port that powers a device on the bench does not prove the full switch can support every camera, reader, intercom, heater, illuminator, and edge function during cold start, restart, failover, or power-supply loss. - Canonical URL: https://update.dsesecurity.com/updates/prove-the-poe-system-at-its-worst-moment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Business Continuity, Networks & Infrastructure, Video Surveillance - Reading time: 4 minutes ## What you need to know A PoE port that powers a device on the bench does not prove the full switch can support every camera, reader, intercom, heater, illuminator, and edge function during cold start, restart, failover, or power-supply loss. ## Potentially affected Organizations powering cameras, readers, intercoms, wireless bridges, sensors, edge processors, and other security devices through Ethernet switches, injectors, extenders, or recorders. ## DSE recommendation Build a port-by-port maximum-power schedule, verify per-port class and total PSE budget, include cable and accessory effects, then test simultaneous cold start, power-supply loss, restart, priority, alarms, and recovery. ## Article ## Source fact: port power and system power are different limits In standards-based Power over Ethernet, the power-sourcing equipment (PSE) detects a powered device (PD), identifies or negotiates a power class, checks available capacity, and allocates power. Cisco’s current [PoE configuration guidance](https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/infra/poe/poe-configuration-guide/g-poe/c-poe-and-switch.html) explains that total available power depends on the switch and installed power supplies. Its troubleshooting guidance directs operators to compare connected devices, per-port allocation, and the remaining system budget. PoE class is not the same as observed consumption. A switch may reserve a class maximum while a device normally draws less, and power is lost in the cable before it reaches the PD. Axis’s December 2025 [camera power white paper](https://whitepapers.axis.com/en-us/typical-and-maximum-power-consumption-in-axis-cameras) distinguishes typical operation from maximum scenarios and notes that heater and infrared state matter. The exact values must come from the current datasheet for the exact product and configuration. ## DSE recommendation: create a power schedule before choosing the switch List every powered endpoint and every intermediate device: camera, reader, intercom, illuminator, microphone, speaker, heater, fan, enclosure, USB accessory, PoE extender, media converter, wireless bridge, and edge appliance. Record model, firmware, PSE port, supported PoE type and class, manufacturer maximum input, typical draw, temperature mode, accessory load, alternate power, cable route, and operational criticality. For each port, confirm that the switch can deliver the class and power the endpoint requests—not merely that both product sheets say PoE. Then calculate the total allocation using the switch’s documented budgeting method and actual power-supply configuration. Include stack members, modular cards, redundant-supply mode, and any derating or sharing rules in the manufacturer documentation. Keep engineering reserve as an explicit design choice rather than an undocumented subtraction. ## Test the loads that are easy to miss - Cold and dark: Exercise representative outdoor devices when heaters, infrared illumination, wipers, fans, or defogging functions are active. Do not substitute the room-temperature typical figure for the documented maximum. - Boot and negotiate: Power a representative device from a de-energized port and observe detection, class, requested and allocated power, startup duration, full-feature operation, and any reduced-power state. - All at once: Restart the PSE or an isolated test group so many devices request power together. Confirm that critical devices return, the intended port-priority policy is applied, and no endpoint remains silently degraded. - Reduced supply: In a controlled maintenance test, simulate the supported loss of a redundant power supply or stack-power path. Verify the recalculated budget, denied ports, alarms, UPS load, and recovery sequence. - Worst cable path: Test representative longest and most complex permanent links, including patch panels and approved extenders. Data connectivity alone does not prove adequate delivered power. ## Look beyond the green LED Validate the powered function, not only port status. Confirm live and recorded video, infrared range, heater state, PTZ movement, audio, intercom call, reader and lock workflow, edge analytics, accessory outputs, and alarm inputs. Some devices may boot in a lower-power mode or disable internal functions when insufficient power is available; the product interface and logs should be checked for warnings. Capture PSE model and software, power-supply inventory, total available and allocated power, per-port class and draw, device power status, cable test result, ambient conditions, syslog messages, and start and recovery times. Cisco documents faults such as undervoltage, overvoltage, overtemperature, and short circuit that can remove port power and produce logs; alarm collection should prove those events reach an owner. ## Connect PoE to continuity planning A UPS supports the PSE, but its advertised runtime is not proof of runtime under the actual PoE load. Repeat the critical-service test on UPS power and after the planned shutdown or generator transition. Document which endpoints may be shed first and what safety, egress, security, or evidence consequences follow. Coordinate any door-system test with the authority responsible for life-safety and access operation. Recalculate and retest after adding devices, accessories, colder operating profiles, firmware features, new power supplies, switch stacks, extenders, or UPS loads. Trend power and environmental alerts where the platform supports them. A reliable PoE design is not the sum of typical watts; it is evidence that the complete powered system survives its defined failure modes. ## Official sources - [Cisco: PoE, powered device, and switch](https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/infra/poe/poe-configuration-guide/g-poe/c-poe-and-switch.html) - [Cisco: Troubleshoot Power over Ethernet](https://www.cisco.com/c/en/us/support/docs/switches/catalyst-9200-series-switches/215636-troubleshooting-power-over-ethernet-poe.html) - [Axis: Typical and maximum power consumption in cameras](https://whitepapers.axis.com/en-us/typical-and-maximum-power-consumption-in-axis-cameras) - [Ethernet Alliance Gen2 PoE Certification Test Plan](https://ethernetalliance.org/poecert/EA_Gen2_PoE_Certification_Test_Plan.pdf) ## Primary reference - Name: Cisco PoE Configuration Guide — Guidelines for PoE - Authority: www.cisco.com - URL: https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/infra/poe/poe-configuration-guide/g-poe/r-guidelines-for-poe.html - Source publication date: 2025-09-15 ## Citation and use Preferred citation: “Prove the PoE system at its worst moment,” DSE Security, https://update.dsesecurity.com/updates/prove-the-poe-system-at-its-worst-moment/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove VMS archiver failover under full load—not just configuration state > A configured standby does not prove that all cameras will transfer, record, remain viewable, merge cleanly, and return under production load. Validate the exact failure, takeover, degraded operation, recovery, and evidence path. - Canonical URL: https://update.dsesecurity.com/updates/prove-vms-archiver-failover-under-full-load/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:11:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, IT, Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know A configured standby does not prove that all cameras will transfer, record, remain viewable, merge cleanly, and return under production load. Validate the exact failure, takeover, degraded operation, recovery, and evidence path. ## Potentially affected VMS recording and archiving servers, standby or failover recorders, edge storage, camera streams, management services, storage, certificates, service accounts, networks, operators, retention, alarms, exports, and recovery procedures. ## DSE recommendation Document the supported failover design and capacity, establish pretest evidence and stop criteria, invoke only vendor-approved failure methods, measure every phase under representative load, verify recordings and exports, and close all gaps before relying on resilience claims. ## Article ## Source facts: failover has product-specific behavior and limitations Milestone Systems’ [failover recording server documentation](https://doc.milestonesys.com/latest/en-US/feature_flags/ff_recordingserverfailover/mc_failoverrecordingserversexplained.htm) describes hot-standby and cold-standby operation, device-level choices for full, live-only, or no failover support, takeover, and later merging of recordings. It explicitly says failover does not provide complete redundancy and describes periods in which some older, archived, or failover-period recordings may be unavailable to clients. The documentation also specifies a supported method for validating a merge: make the recording server unavailable by stopping its service or shutting down its computer. It says manually pulling a network cable or blocking the network with a test tool is not a valid method for that validation. The exact behavior applies to the documented Milestone product and version. Axis similarly describes [primary, redundant, and failover storage concepts](https://www.axis.com/solutions/recording-solutions), including edge or alternative storage when primary storage is unavailable. Different platforms use different triggers, delays, supported codecs, merge behavior, capacity rules, and licenses. RAID, server failover, camera edge recording, backup, and disaster recovery address different failure modes and must not be treated as interchangeable. ## DSE recommendation: test every state the operator and investigator depend on Start with an approved design record: protected cameras and streams, primary recorder, standby assignment, mode, maximum supported load, storage, edge-storage dependencies, management services, certificates, accounts, network paths, alarms, retention, and recovery owner. Compare deployed configuration with current vendor documentation and licensing before scheduling a test. - Define success and stop conditions. Set maximum acceptable detection and takeover times, permitted recording gap, cameras that must remain live, required playback and export behavior, capacity thresholds, merge completion, and return-to-primary criteria. Establish when the test leader must restore service. - Build representative load. Use ordinary production streams and an authorized window that reflects busy recording, operator viewing, analytics, and archive activity. A one-camera laboratory test cannot qualify a standby expected to receive hundreds of streams. - Capture pretest evidence. Verify time, health, recording, retention, current alarms, storage headroom, service state, and a short retrievable clip from every priority class. Confirm backups and an out-of-band communication path. - Invoke the documented failure. Follow the product’s supported validation procedure. Record the exact action and time. Observe detection, alarm delivery, stream reconnection, recording start, live viewing, playback, client errors, standby processor and storage load, and network utilization. - Operate in the degraded state. Find and export events created after takeover. Test authorized user permissions, maps, bookmarks, audio and metadata where required. State clearly which historical or archived footage is unavailable rather than masking the limitation. - Restore and reconcile. Return the primary system under the approved process. Measure handback, recording merge or edge retrieval, duplicate or missing intervals, timeline availability, retention calculations, alarms, and final standby readiness. Export samples that span before, during, and after the event. Reconcile each camera against expected intervals; aggregate “server healthy” status is insufficient. Preserve logs and screenshots, note any deliberate test gap, and assign corrective work with retest criteria. Include a standby already occupied by another failed recorder, exhausted edge storage, a certificate problem, and management-service loss in later risk-based scenarios if the product supports those designs. This test proves only the documented topology, load, version, and scenario. Repeat it after material camera growth, bitrate change, software upgrade, storage change, certificate or account change, network redesign, or failover reassignment. Resilience exists when usable recordings survive a controlled failure and recovery—not when the configuration page says they should. Do not begin if the standby is already degraded, capacity is unknown, monitoring cannot distinguish primary from failover, or restoration authority is unavailable. Pause immediately if priority cameras stop without the approved alternate, storage approaches the defined safety threshold, or handback threatens existing evidence. Reschedule after the prerequisite is corrected; an unsafe resilience test creates the outage it was meant to prevent. ## Official references - Milestone Systems, [Failover recording server explained](https://doc.milestonesys.com/latest/en-US/feature_flags/ff_recordingserverfailover/mc_failoverrecordingserversexplained.htm). - Axis Communications, [Recording solutions: redundant and failover storage](https://www.axis.com/solutions/recording-solutions). ## Primary reference - Name: Milestone Systems: Failover recording server explained - Authority: doc.milestonesys.com - URL: https://doc.milestonesys.com/latest/en-US/feature_flags/ff_recordingserverfailover/mc_failoverrecordingserversexplained.htm - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove VMS archiver failover under full load—not just configuration state,” DSE Security, https://update.dsesecurity.com/updates/prove-vms-archiver-failover-under-full-load/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove VRRP failover from the client path, not the master-state display > Test virtual-router failover with real client traffic and upstream dependencies instead of relying on VRRP state alone. - Canonical URL: https://update.dsesecurity.com/updates/prove-vrrp-failover-from-the-client-path/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:50+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Test virtual-router failover with real client traffic and upstream dependencies instead of relying on VRRP state alone. ## Potentially affected LANs and routed segments that use VRRP for a resilient IPv4 or IPv6 default gateway ## DSE recommendation Exercise master loss, path loss, and recovery while measuring client impact, convergence, and asymmetric dependencies. ## Article A backup router becoming VRRP master proves that an election occurred. It does not prove that a client can resolve the gateway, traverse security policy, reach upstream services, and keep acceptable sessions through the transition. ## Source fact: [IETF RFC 5798](https://www.rfc-editor.org/rfc/rfc5798.html) defines VRRP version 3 for IPv4 and IPv6. A group of routers represents a virtual router, and an election assigns responsibility for forwarding traffic sent to the virtual router’s addresses. The router in the Master state performs that function; Backup routers can assume it when the current Master is no longer available according to the protocol’s state and timer logic. The specification defines advertisements, priority, address ownership, state transitions, and timing behavior. Those mechanisms provide gateway redundancy at the virtual-router layer. They do not measure an application transaction, validate an upstream route, or determine whether a firewall, NAT state, dynamic-routing adjacency, load balancer, or WAN path also failed over. ## Boundary Observed convergence depends on configured advertisement intervals, priority, preemption choices, link detection, implementation, and the surrounding network. VRRP authentication or broader first-hop security must be evaluated separately for the deployed version and platform. A test on one VLAN does not establish behavior for every virtual router, and a clean ICMP result does not guarantee that long-lived application sessions survive. ## Applicability questions - Which client segments depend on each virtual router, and which services are operationally critical? - Do both routers have equivalent upstream routing, firewall, NAT, DHCP-relay, and telemetry dependencies? - What event should trigger takeover: chassis loss, interface loss, tracked-route loss, or another condition? - Is preemption intended, and could restoration cause a second avoidable interruption? - What client-impact and recovery-time thresholds have service owners approved? ## DSE recommendation: Create a per-group dependency map from an actual client port through the virtual gateway to representative DNS, identity, Internet, and application endpoints. Confirm equivalent configuration and reachability on both routers. During an approved window, run continuous probes plus at least one stateful transaction, then test the failures the design claims to tolerate: master shutdown, relevant link loss, tracked upstream loss, and restoration. Measure first failed transaction, last failed transaction, packet loss, route convergence, neighbor-table behavior, and application reconnect. Observe both directions for asymmetric routing. If a dependency does not move with the virtual address, either add a supported tracking mechanism or narrow the continuity claim. Rehearse a safe method to hold the known-good router as Master during troubleshooting. ## Verification and evidence Retain configurations, topology and dependency diagrams, firmware versions, synchronized timestamps, VRRP and routing logs, packet captures, probe output, and application-test results. Evidence should distinguish protocol takeover time from end-to-end recovery time. Record the exact injected failure and restoration sequence so later tests can reproduce it, and repeat after material topology, timer, or platform changes. ## Official references - [IETF RFC 5798](https://www.rfc-editor.org/rfc/rfc5798.html) ## Primary reference - Name: RFC 5798: Virtual Router Redundancy Protocol Version 3 for IPv4 and IPv6 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc5798.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Prove VRRP failover from the client path, not the master-state display,” DSE Security, https://update.dsesecurity.com/updates/prove-vrrp-failover-from-the-client-path/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove wide dynamic range where bright and dark collide > WDR specifications do not prove a usable image at a bright entrance, garage, tunnel, or reflective lobby. Test the installed camera through changing light and motion, then preserve the configuration and evidence. - Canonical URL: https://update.dsesecurity.com/updates/prove-camera-wide-dynamic-range-in-real-scene/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:43:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Advisory - Topics: Video Surveillance - Reading time: 3 minutes ## What you need to know WDR specifications do not prove a usable image at a bright entrance, garage, tunnel, or reflective lobby. Test the installed camera through changing light and motion, then preserve the configuration and evidence. ## Potentially affected Cameras covering entrances, loading areas, garages, tunnels, windows, reflective interiors, vehicle approaches, and other high-contrast scenes; VMS streams and operator workstations. ## DSE recommendation Build a scene-specific WDR test matrix, compare recorded results with representative motion and changing light, and approve the setting that best preserves the evidence the site actually needs. ## Article ## Source facts: WDR performance has more than one dimension Axis Communications’ March 2026 [Wide dynamic range](https://whitepapers.axis.com/en-us/wide-dynamic-range) white paper explains why entrances, parking garages, tunnels, direct sun, shadows, windows, and reflected light challenge a surveillance camera. A camera without adequate dynamic-range handling may expose the bright area or the dark area, but fail to preserve useful detail in both at once. The source also explains that no WDR technique is optimal for every scene. Combining exposures is a common way to extend usable range, but objects may move between those exposures and create motion-related artifacts. Other methods can enhance local contrast while offering different tradeoffs. Axis characterizes practical WDR through reach, motion, and appearance, and cautions that a stated decibel value does not express the complete result. Scene complexity, movement, processing, noise, and the selected method all matter. That distinction is important in security work. A static sample frame can look balanced while a moving person, opening door, rotating fan, flashing light, or vehicle is doubled, smeared, clipped, or otherwise hard to interpret. A manufacturer’s specification supports product selection; it does not certify the installed view. ## DSE recommendation: accept the evidence, not the number Define what must remain usable on both sides of the contrast boundary. At a lobby entrance, that may be a face moving from outdoor daylight into a dim interior. In a garage, it may be a vehicle, driver, or plate near the opening. Mark the required location and movement path before changing settings. - Establish a controlled baseline. Record the camera model, firmware, lens, orientation, exposure mode, WDR setting, frame rate, stream resolution, compression profile, and VMS recording profile. Save a short recorded sample before adjustment. - Test the relevant sun and light states. Include the brightest expected backlight, night lighting, headlights where applicable, interior lights on and off, automatic day/night transition, and rapid changes caused by an opening door or moving cloud. Do not claim year-round proof from one convenient afternoon. - Add representative motion. Use an authorized person or vehicle moving at expected speed through the critical area. Inspect individual frames and normal-speed playback for ghosting, duplicated edges, blur, color shifts, flicker, noise, and lost detail. - Compare practical configurations. Where the product permits it, compare the manufacturer-supported WDR modes or WDR on and off. Adjust only within documented capabilities. A stronger setting is not automatically better if it introduces artifacts that defeat the operational task. - Judge the recorded stream. Retrieve footage through the production VMS and normal operator workstation. Check the configured substream and main recording stream separately if operators view one but investigations export the other. - Verify adjacent functions. Confirm that analytics, privacy masks, overlays, event rules, and bandwidth remain correct after an exposure change. A setting that improves a face but destabilizes an event trigger may move rather than solve the problem. Use a simple test record: condition, target path, setting, observed artifact, operational result, reviewer, and retained sample. Capture both a passing result and the known limitation. If no configuration meets the requirement, change the lens, angle, lighting, mounting position, or camera rather than masking the gap with a favorable still image. Recheck the view after firmware changes that affect imaging, camera replacement, refocus, construction, new glass treatments, lighting changes, or seasonal shifts that materially alter the scene. WDR acceptance should remain tied to the site’s evidence requirement. The useful question is not “How many dB does this camera advertise?” It is “Can the recorded system show the required moving detail in the hardest expected contrast condition?” Retain an accepted sample for later maintenance reviews. Comparing the same movement, location, lighting condition, and recorded stream is more reliable than relying on memory or a subjective “looks good” judgment. ## Official reference - Axis Communications, [Wide dynamic range](https://whitepapers.axis.com/en-us/wide-dynamic-range), March 2026. ## Primary reference - Name: Axis Communications: Wide dynamic range - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/wide-dynamic-range - Source publication date: 2026-03-01 ## Citation and use Preferred citation: “Prove wide dynamic range where bright and dark collide,” DSE Security, https://update.dsesecurity.com/updates/prove-camera-wide-dynamic-range-in-real-scene/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Prove Windows DHCP failover before the primary server is unavailable > A configured DHCP failover relationship is not proof of client continuity. Test both partner paths, relays, lease renewal, new leases, DNS updates, state transitions, scope replication, monitoring, and controlled recovery before relying on it. - Canonical URL: https://update.dsesecurity.com/updates/windows-dhcp-failover-operational-testing/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:15:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know A configured DHCP failover relationship is not proof of client continuity. Test both partner paths, relays, lease renewal, new leases, DNS updates, state transitions, scope replication, monitoring, and controlled recovery before relying on it. ## Potentially affected Windows Server 2016 through 2025 DHCPv4 failover partners; DHCP scopes, leases, reservations, options, policies, DNS dynamic updates, IP helper addresses, routed networks, monitoring, and client onboarding. ## DSE recommendation Build a low-risk failover exercise for each relationship, reconcile scope configuration in the correct replication direction, observe both server and client behavior through outage and recovery, and retain logs, leases, timings, and exceptions. ## Article ## Source facts: Windows DHCP failover is a two-server DHCPv4 design Microsoft’s [DHCP failover overview](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-failover) says two Windows DHCP servers share IPv4 scope information, active leases, and availability state so either can serve clients under the configured relationship. A relationship is always between two DHCP servers, although one server can participate in multiple relationships with different partners. Windows supports load-balance mode, in which the partners divide client lease work, and hot-standby mode, in which an active server normally responds while a standby reserves capacity. DHCP failover applies to DHCPv4 scopes; Microsoft does not support it for DHCPv6 scopes. Clients must be able to reach both partners directly or through relay configuration. When the servers are on remote networks, relay devices therefore need a path to each service endpoint. Initial configuration replicates scopes and leases, but later scope-setting changes are not automatically synchronized in every case. Microsoft says administrators must manually replicate changed scope settings and warns that replication overwrites the partner with the settings from the server where replication is initiated. With partners on different Windows Server versions, Microsoft directs administrators to make the change and initiate replication from the newer operating-system version. The partners use TCP port 647 for failover communication. They maintain separate synchronized lease databases and monitor each other’s state. If DHCP performs DNS dynamic updates for clients, both partners must use the same DNS credentials. Microsoft documents Admin and Operational event channels, audit logs, and performance counters for relationship state, communication, binding updates, queue conditions, and transitions. ## DSE recommendation: run a controlled client-centered exercise Start with a written relationship map: partner names and addresses, mode, scopes, maximum client lead time, standby reserve or load split, state-switch settings, DHCP relay addresses, DNS update credentials, monitoring, owners, and representative test VLANs. Export the configuration and current leases before the exercise. - Establish normal state. Confirm both partners report the expected relationship state, scope settings match, binding-update queues are stable, time is synchronized, and event logs show no unexplained communication or replication error. - Test both network paths. Verify a client broadcast reaches both partners through the actual relay path. Do not infer relay redundancy from successful traffic to only the primary server. - Use controlled clients. On an approved test segment, record existing leases, then test renewal of a current lease and allocation to a new or cleared test client. Confirm address, mask, gateway, DNS servers, suffixes, lease duration, reservations, policies, and any vendor-specific option needed by that segment. - Exercise partner loss. Through an approved method, make one partner unavailable or isolate the relevant service path. Observe the state transition, client renewal, new lease behavior, monitoring alert, log entries, and time required. Repeat in the opposite direction during a separate controlled step. - Verify DNS behavior. Where DHCP updates DNS, confirm forward and reverse records are created, refreshed, and cleaned through each partner with the intended ownership behavior. - Recover deliberately. Restore communication, watch the relationship return through its recovery states, reconcile lease databases and queues, and confirm normal allocation resumes without duplicate addresses. Avoid using uncontrolled production client churn as the test mechanism. Choose a scope and time with enough free addresses and an approved rollback path. Do not manually declare a partner down or alter state timers without understanding the lease implications and Microsoft’s failover behavior. Record every action and observable transition. Retain the before-and-after exports, test-client identifiers, lease timestamps, server states, event records, relay configuration, DNS results, monitor notifications, observed recovery time, and unresolved exceptions. Repeat after DHCP server replacement, relay or routing changes, major scope restructuring, DNS credential changes, operating-system upgrades, or a material failover incident. The acceptance criterion is not merely “relationship: normal.” It is that real clients can renew and obtain the correct configuration through either partner, operations can see the transition, and the pair can return to a synchronized normal state. ## Official references - Microsoft Learn, [DHCP failover in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-failover), March 11, 2025. - Microsoft Learn, [DHCP failover events in Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-failover-events), April 25, 2025. ## Primary reference - Name: Microsoft Learn: DHCP failover in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/dhcp-failover - Source publication date: 2025-03-11 ## Citation and use Preferred citation: “Prove Windows DHCP failover before the primary server is unavailable,” DSE Security, https://update.dsesecurity.com/updates/windows-dhcp-failover-operational-testing/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Provide documented seafarer, visitor, and welfare access through regulated maritime facilities > Use 33 CFR 105.237 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/provide-documented-seafarer-visitor-and-welfare-access-through-regulated-maritime-facilities/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:14+00:00 - Modified: 2026-08-27T13:09:37+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.237 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.237 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Provide documented seafarer, visitor, and welfare access through regulated maritime facilities. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.237 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.237) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the individuals to whom the facility owner or operator must provide the access described in this section include representatives of seafarers’ welfare and labor organizations. The research record locates this support at 33 CFR 105.237(b)(3), read with 33 CFR 105.237(b) (eCFR anchor p-105.237(b)(3)). - Under 33 CFR 105, the rule requires that the facility owner or operator ensure that the access described in this section is provided through one or more of the following methods: arrangements with seafarers’ welfare organizations to facilitate the access described in this section. The research record locates this support at 33 CFR 105.237(d)(4), read with 33 CFR 105.237(d) (eCFR anchor p-105.237(d)(4)). Keep the evidence boundary at these traced claims. They support a review of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. No current deployment state or change approval follows from the source alone. Validate identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at 33 CFR 105.237(b)(3), read with 33 CFR 105.237(b) (eCFR anchor p-105.237(b)(3)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.237(d)(4), read with 33 CFR 105.237(d) (eCFR anchor p-105.237(d)(4)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 33 CFR 105.237(b)(3), read with 33 CFR 105.237(b) (eCFR anchor p-105.237(b)(3)); 33 CFR 105.237(d)(4), read with 33 CFR 105.237(d) (eCFR anchor p-105.237(d)(4)). Favor approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records, linked to stable identifiers, time, and operator. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [33 CFR 105.237 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.237) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.237 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.237 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Provide documented seafarer, visitor, and welfare access through regulated maritime facilities,” DSE Security, https://update.dsesecurity.com/updates/provide-documented-seafarer-visitor-and-welfare-access-through-regulated-maritime-facilities/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Provide law-enforcement support for airport security and response > Use 49 CFR 1542.215 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/provide-law-enforcement-support-for-airport-security-and-response/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:27+00:00 - Modified: 2026-08-27T13:12:21+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 49 CFR 1542.215 -- Airport Security to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 49 CFR 1542.215 -- Airport Security ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Provide law-enforcement support for airport security and response. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [49 CFR 1542.215 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.215) from Transportation Security Administration via eCFR supports the following bounded statements: - Under 49 CFR 1542, in accordance with section 1542.217, each airport operator required to have a security program under section 1542.103(a) or (b) must provide: law enforcement personnel in the number and manner adequate to support its security program. The research record locates this support at 49 CFR 1542.215(a)(1), read with 49 CFR 1542.215(a) (eCFR anchor p-1542.215(a)(1)). - Under 49 CFR 1542, the rule requires that each airport required to have a security program under section 1542.103(c) ensure that the procedures by which to request law enforcement support are provided to each aircraft operator or foreign air carrier that has a security program under part 1544 or 1546 of this chapter. The research record locates this support at 49 CFR 1542.215(b)(2), read with 49 CFR 1542.215(b) (eCFR anchor p-1542.215(b)(2)). Only the traced statements above are asserted as source facts. Apply the review to access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths after confirming that the source and deployed context match. ## What the source does not establish Applies only to airport operators, tenants, personnel, and areas covered by 49 CFR part 1542 and the cited section. Confirm the TSA-approved security program and current directives; this is not legal advice or a universal access-control standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 49 CFR 1542.215(a)(1), read with 49 CFR 1542.215(a) (eCFR anchor p-1542.215(a)(1)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 49 CFR 1542.215(b)(2), read with 49 CFR 1542.215(b) (eCFR anchor p-1542.215(b)(2)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to 49 CFR 1542.215(a)(1), read with 49 CFR 1542.215(a) (eCFR anchor p-1542.215(a)(1)); 49 CFR 1542.215(b)(2), read with 49 CFR 1542.215(b) (eCFR anchor p-1542.215(b)(2)) and to observable material such as asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [49 CFR 1542.215 — Airport Security](https://www.ecfr.gov/current/title-49/section-1542.215) — Transportation Security Administration via eCFR ## Primary reference - Name: 49 CFR 1542.215 -- Airport Security - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-49/section-1542.215 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Provide law-enforcement support for airport security and response,” DSE Security, https://update.dsesecurity.com/updates/provide-law-enforcement-support-for-airport-security-and-response/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Publish AAAA and IP6.ARPA data as separate forward and reverse decisions > Use RFC 3596 — DNS Extensions to Support IP Version 6 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/publish-aaaa-and-ip6-arpa-data-as-separate-forward-and-reverse-decisions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:34+00:00 - Modified: 2026-08-27T12:18:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 3596 — DNS Extensions to Support IP Version 6 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 3596 — DNS Extensions to Support IP Version 6 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Publish AAAA and IP6.ARPA data as separate forward and reverse decisions. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 3596 — DNS Extensions to Support IP Version 6](https://www.rfc-editor.org/rfc/rfc3596.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An AAAA record stores one 128-bit IPv6 address in network byte order for its owner name. The research record locates this support at Section 2.1 (Format). - An AAAA query returns the IPv6 address records associated with the queried name; it does not perform reverse mapping. The research record locates this support at Section 2.3 (AAAA Query). - IPv6 reverse lookup names reverse the address’s hexadecimal nibbles and append the IP6.ARPA suffix. The research record locates this support at Section 2.5 (IP6.ARPA Domain). Only the traced statements above are asserted as source facts. Apply the review to authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Section 2.1 (Format), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.3 (AAAA Query), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 2.5 (IP6.ARPA Domain), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Build a reproducible chain from Section 2.1 (Format); Section 2.3 (AAAA Query); Section 2.5 (IP6.ARPA Domain) to the observed environment. Useful domain evidence includes zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior; label every item with scope, timestamp, collector, and stable identifier. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 3596 — DNS Extensions to Support IP Version 6](https://www.rfc-editor.org/rfc/rfc3596.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 3596 — DNS Extensions to Support IP Version 6 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc3596.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Publish AAAA and IP6.ARPA data as separate forward and reverse decisions,” DSE Security, https://update.dsesecurity.com/updates/publish-aaaa-and-ip6-arpa-data-as-separate-forward-and-reverse-decisions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Publish and control a prohibited-items list for cruise-terminal screening > Use 33 CFR 105.515 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/publish-and-control-a-prohibited-items-list-for-cruise-terminal-screening/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:49+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.515 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.515 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Publish and control a prohibited-items list for cruise-terminal screening. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.515 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.515) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that the owner or operator of a cruise ship terminal obtain from the Coast Guard and maintain a Prohibited Items List (PIL) consisting of dangerous substances and devices for purposes of section 105.290(a). The research record locates this support at 33 CFR 105.515(a) (eCFR anchor p-105.515(a)). - Under 33 CFR 105, the rule requires that facility personnel report the discovery of a prohibited item introduced by violating security measures at a cruise ship terminal as a breach of security in accordance with section 101.305(b) of this subchapter. The research record locates this support at 33 CFR 105.515(d) (eCFR anchor p-105.515(d)). Keep the evidence boundary at these traced claims. They support a review of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.515(a) (eCFR anchor p-105.515(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.515(d) (eCFR anchor p-105.515(d)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, including exceptions? - What baseline for identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of credentials, readers, controllers, panels, door hardware, access decisions, monitoring, and life-safety interfaces, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity sources, DNS where used, time, networks, power, fire systems, monitoring, and authorized operators before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations 33 CFR 105.515(a) (eCFR anchor p-105.515(a)); 33 CFR 105.515(d) (eCFR anchor p-105.515(d)). Favor approved configuration exports, access-event tests, controller state, door inspections, alarm handling, and exception records, linked to stable identifiers, time, and operator. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [33 CFR 105.515 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.515) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.515 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.515 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Publish and control a prohibited-items list for cruise-terminal screening,” DSE Security, https://update.dsesecurity.com/updates/publish-and-control-a-prohibited-items-list-for-cruise-terminal-screening/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Publish CAA only after mapping every legitimate certificate issuer > Use DNS Certification Authority Authorization records to express issuance policy without disrupting approved certificate workflows. - Canonical URL: https://update.dsesecurity.com/updates/publish-caa-after-mapping-certificate-issuers/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:48+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use DNS Certification Authority Authorization records to express issuance policy without disrupting approved certificate workflows. ## Potentially affected Public DNS names for which one or more certification authorities issue publicly trusted certificates ## DSE recommendation Inventory direct and delegated issuance paths, publish a tested CAA policy, and monitor both DNS and certificate issuance changes. ## Article CAA records can narrow which public certification authorities are authorized to issue for a domain, but an incomplete issuer inventory can block a legitimate renewal. Treat CAA as a managed issuance policy with owners and tests, not a one-time DNS hardening entry. ## Source fact: [IETF RFC 8659](https://www.rfc-editor.org/rfc/rfc8659.html) defines the DNS Certification Authority Authorization resource record. A domain holder can use CAA properties to identify certification authorities authorized to issue certificates for the domain and can provide an incident-reporting contact. The specification describes how a certification authority finds the relevant CAA record set, including processing across DNS names and aliases. A compliant public certification authority evaluates the applicable policy before issuance. The record expresses current authorization; it is not used by browsers or other relying parties to decide whether an already issued certificate is valid. The RFC also notes that CAA does not prevent an authorized authority from mis-issuing and that DNSSEC can protect record authenticity but is not a prerequisite for using CAA. ## Boundary CAA enforcement depends on the issuing authority and the certificate context. It does not inventory certificates, revoke existing certificates, validate private-PKI workflows, or replace account security at the authority. DNS delegation, CNAMEs, parent-domain policy, issuer-specific parameters, and automation vendors can alter the applicable record set. The correct value must come from the selected authority’s current documentation, not a guessed brand name. ## Applicability questions - Which internal teams, hosting providers, CDNs, managed services, and emergency processes request public certificates? - Which issuer identifiers and parameters do those authorities currently require? - Do wildcard issuance and ordinary issuance need different authorization? - How do aliases, delegated subdomains, and acquired domains affect policy discovery? - Is there a controlled emergency path for adding an approved issuer before a renewal deadline? ## DSE recommendation: Build an issuance map from certificate-transparency monitoring, certificate-manager inventories, DNS zones, procurement records, and service-owner interviews. Confirm each issuer’s official CAA identifier and any account-binding parameter. Include certificates obtained indirectly by SaaS, CDN, and domain-validation automation. Model the record lookup for representative names, then publish to a noncritical delegated name and complete real issuance and renewal tests. Introduce production records in stages with normal DNS change control. Assign ownership for additions, removals, incident contact handling, and acquisitions. Monitor CAA answers from external resolvers and alert on unexpected record changes or public certificates from an unapproved authority. ## Verification and evidence Retain the approved issuer map, authority documentation, zone changes, DNS responses with timestamps, issuance and renewal results, and certificate-transparency alerts. Test a permitted workflow and, where the authority offers a safe validation method, confirm that a nonpermitted issuer is rejected without ordering an unnecessary certificate. Review the map before removing an issuer and before large renewal windows. ## Official references - [IETF RFC 8659](https://www.rfc-editor.org/rfc/rfc8659.html) ## Primary reference - Name: RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8659.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Publish CAA only after mapping every legitimate certificate issuer,” DSE Security, https://update.dsesecurity.com/updates/publish-caa-after-mapping-certificate-issuers/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Publish certificate policy securely to disconnected domain clients > Use Certificate Enrollment Policy Web Service overview to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/publish-certificate-policy-to-disconnected-domain-clients/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:12+00:00 - Modified: 2026-08-27T12:58:59+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Certificate Enrollment Policy Web Service overview to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Certificate Enrollment Policy Web Service overview ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Publish certificate policy securely to disconnected domain clients. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Certificate Enrollment Policy Web Service overview](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-enrollment-policy-web-service-overview) from Microsoft supports the following bounded statements: - The policy web service supplies enrollment-policy information to non-domain or temporarily disconnected domain clients. The research record locates this support at Opening overview. - It queries AD DS over LDAP or LDAPS and supports policy retrieval, enrollment, and renewal over HTTPS. The research record locates this support at Opening overview. Only the traced statements above are asserted as source facts. Apply the review to certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles after confirming that the source and deployed context match. ## What the source does not establish Protect the IIS application identity, LDAP path, server certificate, and authentication choice. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles are in and out of scope? - Which condition in Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of certification authorities, templates, enrollment paths, certificate subjects, private-key handling, and delegated PKI roles, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, time, domain-controller reachability, HTTP or LDAP publication, and protected administrative identities, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations Opening overview; Opening overview adjacent to the sanitized artifacts used for comparison. Prefer CA and template exports, enrollment tests, certificate chains, access-control entries, event logs, and revocation-path checks, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Certificate Enrollment Policy Web Service overview](https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-enrollment-policy-web-service-overview) — Microsoft ## Primary reference - Name: Certificate Enrollment Policy Web Service overview - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-enrollment-policy-web-service-overview - Source publication date: 2025-02-14 ## Citation and use Preferred citation: “Publish certificate policy securely to disconnected domain clients,” DSE Security, https://update.dsesecurity.com/updates/publish-certificate-policy-to-disconnected-domain-clients/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Put a licensed fire-protection engineer over records-storage system design > Use 36 CFR 1234.12 - Records storage fire safety to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/put-a-licensed-fire-protection-engineer-over-records-storage-system-design/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:11:31+00:00 - Modified: 2026-08-27T13:07:00+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 36 CFR 1234.12 - Records storage fire safety to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 36 CFR 1234.12 - Records storage fire safety ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Put a licensed fire-protection engineer over records-storage system design. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [36 CFR 1234.12 – Records storage fire safety](https://www.ecfr.gov/current/title-36/section-1234.12) from National Archives and Records Administration via eCFR supports the following bounded statements: - Under 36 CFR 1234, the rule requires that all record storage and adjoining areas be protected by a professionally-designed fire-safety detection and suppression system that is designed to limit the maximum anticipated loss in any single fire event involving a single ignition and no more than 8 ounces of accelerant to a maximum of 300 cubic feet of records destroyed by fire. The research record locates this support at 36 CFR 1234.12(s) (eCFR anchor p-1234.12(s)). - Under 36 CFR 1234, the rule requires that the fire detection and protection systems be designed or reviewed by a licensed fire protection engineer. The research record locates this support at 36 CFR 1234.12(a) (eCFR anchor p-1234.12(a)). The source support ends with the statements listed above. Use them to examine critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Federal records-storage regulation with incorporated standards; record configuration, sprinkler and detection design, fire code, professional seals, waivers, and NARA review require qualified engineering. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at 36 CFR 1234.12(s) (eCFR anchor p-1234.12(s)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 36 CFR 1234.12(a) (eCFR anchor p-1234.12(a)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, including exceptions? - What baseline for identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from 36 CFR 1234.12(s) (eCFR anchor p-1234.12(s)); 36 CFR 1234.12(a) (eCFR anchor p-1234.12(a)) to the observed environment. Useful domain evidence includes facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [36 CFR 1234.12 – Records storage fire safety](https://www.ecfr.gov/current/title-36/section-1234.12) — National Archives and Records Administration via eCFR ## Primary reference - Name: 36 CFR 1234.12 - Records storage fire safety - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-36/section-1234.12 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Put a licensed fire-protection engineer over records-storage system design,” DSE Security, https://update.dsesecurity.com/updates/put-a-licensed-fire-protection-engineer-over-records-storage-system-design/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Put duties, access controls, communications, and response procedures into the Facility Security Plan > Use 33 CFR 105.405 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/put-duties-access-controls-communications-and-response-procedures-into-the-facility-security-plan/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:54+00:00 - Modified: 2026-08-27T13:09:38+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Video Surveillance - Reading time: 3 minutes ## What you need to know Use 33 CFR 105.405 -- Maritime Security: Facilities to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 33 CFR 105.405 -- Maritime Security: Facilities ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Put duties, access controls, communications, and response procedures into the Facility Security Plan. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [33 CFR 105.405 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.405) from U.S. Coast Guard via eCFR supports the following bounded statements: - Under 33 CFR 105, the rule requires that if the FSP does not follow the order as it appears in the list, the facility owner or operator ensure that the FSP contains an index identifying the location of each of the following sections: security measures for access control, including the facility’s TWIC Program and designated public access areas. The research record locates this support at 33 CFR 105.405(a)(10), read with 33 CFR 105.405(a) (eCFR anchor p-105.405(a)(10)). - Under 33 CFR 105, the rule requires that if the FSP does not follow the order as it appears in the list, the facility owner or operator ensure that the FSP contains an index identifying the location of each of the following sections: security incident procedures. The research record locates this support at 33 CFR 105.405(a)(15), read with 33 CFR 105.405(a) (eCFR anchor p-105.405(a)(15)). Only the traced statements above are asserted as source facts. Apply the review to access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths after confirming that the source and deployed context match. ## What the source does not establish Applies only to facilities within 33 CFR part 105 and the cited section. Confirm Coast Guard jurisdiction, the approved Facility Security Plan, the current MARSEC level, and any approved alternatives; this is not legal advice or a universal facility-design standard. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before translating the source into an operational decision. ## Applicability questions - For source statement 1 at 33 CFR 105.405(a)(10), read with 33 CFR 105.405(a) (eCFR anchor p-105.405(a)(10)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 33 CFR 105.405(a)(15), read with 33 CFR 105.405(a) (eCFR anchor p-105.405(a)(15)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, including exceptions? - What baseline for identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of access control, video, intrusion detection, communications, supporting facilities, operators, and documented response paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity, Windows DNS where used, time, networks, power, life-safety systems, vendors, and monitoring personnel before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to 33 CFR 105.405(a)(10), read with 33 CFR 105.405(a) (eCFR anchor p-105.405(a)(10)); 33 CFR 105.405(a)(15), read with 33 CFR 105.405(a) (eCFR anchor p-105.405(a)(15)) and to observable material such as asset and firmware inventories, configuration exports, event tests, inspections, alarm response records, and maintenance findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [33 CFR 105.405 — Maritime Security: Facilities](https://www.ecfr.gov/current/title-33/section-105.405) — U.S. Coast Guard via eCFR ## Primary reference - Name: 33 CFR 105.405 -- Maritime Security: Facilities - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-33/section-105.405 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Put duties, access controls, communications, and response procedures into the Facility Security Plan,” DSE Security, https://update.dsesecurity.com/updates/put-duties-access-controls-communications-and-response-procedures-into-the-facility-security-plan/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Put software-supply-chain checks inside the CI/CD path > A CI/CD pipeline carries source through build, test, package, and deployment operations. Protect each transition, identity, dependency, artifact, approval, and evidence record in the path. - Canonical URL: https://update.dsesecurity.com/updates/ci-cd-software-supply-chain-controls/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:04+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know A CI/CD pipeline carries source through build, test, package, and deployment operations. Protect each transition, identity, dependency, artifact, approval, and evidence record in the path. ## Potentially affected Organizations using automated continuous integration or deployment to build, test, package, promote, or deploy software and infrastructure changes. ## DSE recommendation Model the pipeline as a production supply chain, constrain its identities and inputs, verify artifact transitions, separate promotion authority where justified, and retain evidence that connects source to deployment. ## Article Bottom line: a deployment pipeline is not just an efficiency tool. It is a chain of privileged operations that converts source and dependencies into an artifact and then changes production. Security checks are strongest when they are part of those transitions and leave verifiable evidence. ## Source fact: what NIST addresses [NIST SP 800-204D](https://csrc.nist.gov/pubs/sp/800/204/d/final) describes continuous integration and continuous deployment pipelines as flow processes that move software through stages such as build, test, package, and deploy. NIST treats these operations as part of the software supply chain and outlines strategies for integrating supply-chain security measures into CI/CD pipelines, particularly in cloud-native DevSecOps environments. The source supports evaluating the path as a system rather than treating a source repository or final scanner as the whole supply chain. ## What the source does not establish The publication does not certify a pipeline product or define a universal set of mandatory tools. Automation does not establish integrity by itself: a fast, repeatable process can reproduce a compromised input or over-privileged change. A generated bill of materials, signature, or scan report is only useful when its origin, scope, verification, and decision role are understood. Applicability depends on the development model, artifact types, deployment targets, supplier inputs, secrets, signing or attestation mechanisms, and the consequences of unauthorized or erroneous release. ## Applicability questions - Which sources, dependencies, build images, actions, plugins, and external services can influence the artifact? - Which human and machine identities can change pipeline logic, approve promotion, publish artifacts, or deploy? - What immutable information connects source, inputs, build execution, test results, artifact, and deployment? - Which findings block movement, and who can approve a bounded exception? - Can the organization stop, revoke, or roll back a release if the pipeline or an input is later questioned? ## DSE recommendation: secure each transition The following steps are DSE recommendations based on the cited source. - Diagram stages, trust boundaries, inputs, outputs, identities, stores, external calls, approvals, and production destinations. Include infrastructure-as-code and administrative pipelines. - Pin and review executable dependencies such as build images, pipeline actions, plugins, and package sources. Record authorized provenance and update ownership. - Use narrowly scoped automation identities and short-lived credentials where supported. Separate the ability to change the pipeline from the ability to approve or perform consequential promotion when risk warrants it. - Generate and protect evidence at each stage: source revision, resolved dependencies, build environment, test results, artifact digest, approval, promotion, and deployment result. - Verify artifacts when they cross a trust boundary. Define what happens when provenance, integrity, policy, or required evidence cannot be validated. - Rehearse containment: pause the path, revoke a credential or artifact, locate deployments, restore a known release, and preserve logs for investigation. ## Verification and evidence Trace one deployed release backward to an immutable artifact, build execution, exact source and dependencies, tests, policy decisions, identities, and approvals. Then sample a denied unapproved change and a rollback. Record any stage that depends on mutable labels, shared credentials, or evidence outside retention. ## Official references - [NIST SP 800-204D — Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines](https://csrc.nist.gov/pubs/sp/800/204/d/final) — National Institute of Standards and Technology; published February 2024 - [NIST SP 800-218 — Secure Software Development Framework](https://csrc.nist.gov/pubs/sp/800/218/final) — National Institute of Standards and Technology ## Primary reference - Name: NIST SP 800-204D — Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/sp/800/204/d/final - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Put software-supply-chain checks inside the CI/CD path,” DSE Security, https://update.dsesecurity.com/updates/ci-cd-software-supply-chain-controls/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Qualify an accelerated-networking configuration before enabling it > Which platform checks should precede Windows Server Accelerated Networking? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-220-qualify-an-accelerated-networking-configuration-before-enabling-it/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:31+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Which platform checks should precede Windows Server Accelerated Networking? ## Potentially affected Administrators evaluating Accelerated Networking for Windows Server 2025 Datacenter clustered VMs. ## DSE recommendation Have the virtualization and network owners review the built-in prerequisite results, hardware support, Compute intent, and planned failover capacity. ## Article ## Source facts Microsoft describes Accelerated Networking as using SR-IOV virtual functions to let VM traffic bypass the Hyper-V software-switch layer. The documented cluster prerequisite is Windows Server 2025 Datacenter. The page excludes standalone nonclustered servers and Windows Server Standard edition from this feature. Its prerequisites include Network ATC with a valid Compute intent. The network hardware must support SR-IOV, with that support enabled in firmware. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/networking/technologies/accelerated-networking/accelerated-networking). ## Applicability Verify the platform, hardware, and documented Pay-as-you-go or Software Assurance entitlement requirements. Identify the workload’s network-performance requirement and virtual switch. Treat a compatible NIC as only one prerequisite rather than proof that the entire deployment qualifies. ## DSE recommendation Have the virtualization and network owners review the built-in prerequisite results, hardware support, Compute intent, and planned failover capacity. Record the intended VM population and the resources available when a node is unavailable. Pilot the configuration with a representative workload and preserve a recoverable networking configuration. Set measurable acceptance criteria before enabling the feature broadly. ## Verification Confirm that the intended VMs use the supported accelerated path and compare actual workload measurements with the baseline. Exercise the agreed failover case and observe resource allocation as well as connectivity. Investigate a failed prerequisite or unexpected network path instead of treating nominal adapter speed as the acceptance result. ## Official references [Microsoft Learn: Accelerated Networking for Windows Server](https://learn.microsoft.com/en-us/windows-server/networking/technologies/accelerated-networking/accelerated-networking). Source reviewed September 8, 2026. ## Primary reference - Name: Accelerated Networking for Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/accelerated-networking/accelerated-networking - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Qualify an accelerated-networking configuration before enabling it,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-220-qualify-an-accelerated-networking-configuration-before-enabling-it/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Qualify EAP-TLS 1.3 across supplicants, RADIUS, and certificates > Test the complete 802.1X authentication chain before introducing TLS 1.3 behavior for EAP-TLS. - Canonical URL: https://update.dsesecurity.com/updates/qualify-eap-tls-13-end-to-end/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:43+00:00 - Modified: 2026-08-25T21:43:56+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Test the complete 802.1X authentication chain before introducing TLS 1.3 behavior for EAP-TLS. ## Potentially affected Wired and wireless 802.1X environments that use EAP-TLS with diverse clients, authenticators, RADIUS services, and certificate infrastructure ## DSE recommendation Qualify EAP-TLS 1.3 as an end-to-end compatibility change and retain a controlled transition profile for unsupported clients. ## Article EAP-TLS 1.3 is not a RADIUS-server toggle in isolation. The supplicant, authenticator path, EAP implementation, RADIUS service, certificate chain, revocation services, identity mapping, and authorization policy all participate in a successful access decision. ## Source fact: [IETF RFC 9190](https://www.rfc-editor.org/rfc/rfc9190.html) defines how TLS 1.3 is used with the Extensible Authentication Protocol TLS method. The specification is intended to remain backward compatible with existing EAP-TLS deployments while incorporating TLS 1.3 behavior and security properties. It discusses changes to the exchange, key derivation, resumption, privacy, and certificate-related processing. TLS 1.3 provides forward secrecy for relevant handshakes, and the EAP-TLS design includes mechanisms that can improve peer identity privacy. The RFC also addresses certificate validation and revocation checking. These protocol properties depend on correct implementation and configuration; they do not prove that an organization issues suitable certificates or maps an authenticated identity to the right network access. ## Boundary Client operating systems and device-management states may support different TLS versions, certificate stores, server-name validation, resumption modes, and user-versus-machine identities. Network devices that merely relay EAP can still impose packet-size or timeout behavior. A successful authentication test does not establish authorization, VLAN assignment, posture, or application access. Backward compatibility in the standard does not guarantee compatibility among every product combination. ## Applicability questions - Which supplicant versions, device classes, authenticators, and RADIUS implementations are actually deployed? - Which server and client certificate profiles, names, trust anchors, and revocation methods are required? - Do onboarding, machine startup, user sign-in, roaming, resumption, and passwordless devices follow different paths? - What happens to an unsupported client: explicit denial, controlled legacy profile, or an unintended open fallback? - Can support staff distinguish certificate, TLS, EAP, identity, and authorization failures? ## DSE recommendation: Create a test matrix from managed inventory and authentication logs, not only currently approved hardware lists. Include every material supplicant and authenticator release plus the production RADIUS and certificate chain. Test new enrollment, renewal, revoked and expired certificates, wrong server name, missing trust anchor, device restart, user transition, roaming, and session resumption. Confirm that failed validation never falls through to a weaker network unintentionally. Deploy server-side telemetry and support runbooks before widening the profile. Roll out to a controlled device group, observe failure reasons, then expand by client class. If a legacy profile is necessary, isolate it, name the supported population, restrict authorization, assign an owner, and set a review date. Coordinate certificate-policy and RADIUS changes so their combined effect is tested. ## Verification and evidence Retain the compatibility matrix, EAP and TLS settings, certificate profiles, controlled authentication traces, RADIUS decision logs, assigned policy or VLAN, negative-test results, and exception list. A complete proof includes successful network and application access for approved clients, expected denial for invalid credentials, and monitoring that identifies the cause without logging private keys or unnecessary sensitive identity data. ## Official references - [IETF RFC 9190](https://www.rfc-editor.org/rfc/rfc9190.html) ## Primary reference - Name: RFC 9190: EAP-TLS 1.3 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9190.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Qualify EAP-TLS 1.3 across supplicants, RADIUS, and certificates,” DSE Security, https://update.dsesecurity.com/updates/qualify-eap-tls-13-end-to-end/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Qualify PowerShell Direct as a host-to-guest administration path > What conditions must hold before using PowerShell Direct for a Windows virtual machine? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-170-qualify-powershell-direct-as-a-host-to-guest-administration-path/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:21+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What conditions must hold before using PowerShell Direct for a Windows virtual machine? ## Potentially affected Hyper-V administrators considering PowerShell Direct for a local Windows guest. ## DSE recommendation Define one bounded administrative action and the expected guest before opening a session. ## Article ## Source facts PowerShell Direct runs PowerShell in a Windows guest from its Hyper-V host without depending on guest networking or remote-management configuration. Microsoft requires the virtual machine to be local, running, and to have a configured user profile. The operator must be a Hyper-V administrator on the host and provide valid credentials for the guest. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/powershell-direct). ## Applicability Check the host and guest versions against the current source, then confirm the virtual machine identifier and its actual host. Keep host privileges and guest authentication as two separate prerequisites. An unavailable guest network is only one part of the access decision. ## DSE recommendation Define one bounded administrative action and the expected guest before opening a session. Use the authorized guest account and protect its credentials through the approved handling process. Have the operator record the guest identity from inside the session before running the intended command. For repeatable work, decide when the session will be closed and who owns cleanup. ## Verification Use a harmless inventory command on a representative guest and compare its output with the known guest identity. Confirm the command executed inside that guest rather than on the host. Record failures by prerequisite: host authorization, VM location and state, guest credentials, or supported version. Close the session and retain a sanitized result. ## Official references [Microsoft Learn: Manage Windows Virtual Machines with PowerShell Direct](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/powershell-direct). Source reviewed September 8, 2026. ## Primary reference - Name: Manage Windows Virtual Machines with PowerShell Direct - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/powershell-direct - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Qualify PowerShell Direct as a host-to-guest administration path,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-170-qualify-powershell-direct-as-a-host-to-guest-administration-path/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Qualify RDS IP virtualization for an application compatibility issue > When should an RDS application be tested with per-session or per-program IP virtualization? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-209-qualify-rds-ip-virtualization-for-an-application-compatibility-issue/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:42+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know When should an RDS application be tested with per-session or per-program IP virtualization? ## Potentially affected Administrators investigating IP-address-related compatibility for Winsock applications on on-premises RDS session hosts. ## DSE recommendation Choose a representative application and a small set of concurrent test users. ## Article ## Source facts Microsoft documents per-session and per-program IP virtualization for Winsock applications on Remote Desktop session hosts. The cited IP-virtualization procedure applies only to on-premises environments. The feature assigns individual addresses to sessions to address compatibility problems when multiple users otherwise share one address. The documented configuration supports a single selected network adapter, even when more than one adapter is enabled. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/internet-protocol-virtualization). ## Applicability Establish the actual application symptom and confirm that the vendor’s requirements involve the network identity of sessions or programs. Review the session-host version and selected adapter against the source. Keep this compatibility assessment separate from granting users additional network access. ## DSE recommendation Choose a representative application and a small set of concurrent test users. Record the original network and application behavior, the intended virtualization scope, and the chosen adapter. Ask the application and network owners to agree on address allocation and expected observations. Preserve the original configuration and avoid applying a host-wide compatibility change before the symptom is reproducible. ## Verification Run the affected transaction concurrently in the approved pilot sessions. Compare observed addresses, application behavior, and any failure messages with the baseline. Test an unrelated application to detect unintended effects. Retain the exact scope and adapter configuration with the results, and expand only after the original compatibility problem is demonstrably resolved. ## Official references [Microsoft Learn: Remote Desktop IP virtualization in Windows Server](https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/internet-protocol-virtualization). Source reviewed September 8, 2026. ## Primary reference - Name: Remote Desktop IP virtualization in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/internet-protocol-virtualization - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Qualify RDS IP virtualization for an application compatibility issue,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-209-qualify-rds-ip-virtualization-for-an-application-compatibility-issue/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Qualify the account model for live migration in a workgroup cluster > What authentication prerequisites distinguish workgroup-cluster live migration? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-227-qualify-the-account-model-for-live-migration-in-a-workgroup-cluster/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:24+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What authentication prerequisites distinguish workgroup-cluster live migration? ## Potentially affected Administrators planning live migration within Windows Server 2025 workgroup clusters. ## DSE recommendation Have the virtualization and identity owners document how the required node accounts will be provisioned, protected, rotated, and removed. ## Article ## Source facts Microsoft distinguishes workgroup clustering, introduced earlier, from workgroup-cluster live migration support introduced with Windows Server 2025. The documented setup requires a running cluster of at least two nodes and matching local account names and passwords on the nodes. The cluster uses self-signed PKU2U certificates for movement between hosts rather than Kerberos in this workflow. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/live-migration-workgroup-cluster). ## Applicability Confirm that the proposed hosts and cluster match the current support requirements. Identify the local-account lifecycle and the operators responsible for each node. Do not transfer assumptions from a domain-based constrained-delegation design into the workgroup procedure. ## DSE recommendation Have the virtualization and identity owners document how the required node accounts will be provisioned, protected, rotated, and removed. Keep credentials out of runbooks and ordinary evidence files. Select a representative VM and confirm its source and destination configuration before a pilot. Include a recovery management path if account consistency or the migration relationship fails. ## Verification Perform the approved live move and verify the VM’s resulting host and application behavior. Record the documented authentication configuration and any failed connection separately from storage or hardware compatibility issues. Check the operational procedure after an approved account-lifecycle exercise. Accept the workflow only when its local-account ownership is maintainable across every intended node. ## Official references [Microsoft Learn: Use live migration with workgroup clusters in Windows Server](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/live-migration-workgroup-cluster). Source reviewed September 8, 2026. ## Primary reference - Name: Use live migration with workgroup clusters in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/live-migration-workgroup-cluster - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Qualify the account model for live migration in a workgroup cluster,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-227-qualify-the-account-model-for-live-migration-in-a-workgroup-cluster/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Race IPv6 and IPv4 connection attempts from one interleaved candidate list > Use RFC 8305 — Happy Eyeballs Version 2: Better Connectivity Using Concurrency to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/race-ipv6-and-ipv4-connection-attempts-from-one-interleaved-candidate-list/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:16+00:00 - Modified: 2026-08-27T12:53:57+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8305 — Happy Eyeballs Version 2: Better Connectivity Using Concurrency to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8305 — Happy Eyeballs Version 2: Better Connectivity Using Concurrency ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Race IPv6 and IPv4 connection attempts from one interleaved candidate list. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8305 — Happy Eyeballs Version 2: Better Connectivity Using Concurrency](https://www.rfc-editor.org/rfc/rfc8305.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A dual-stack client SHOULD issue AAAA first and A immediately afterward, treat resolution asynchronously, and avoid waiting for both address families before beginning connection establishment. The research record locates this support at Section 3 (Hostname Resolution Query Handling). - The client MUST first apply destination-address selection, then SHOULD interleave IPv6 and IPv4 candidates; historical address data MUST NOT cross interfaces and SHOULD be flushed after a network change. The research record locates this support at Section 4 (Sorting Addresses). - Connection attempts SHOULD be staggered but may overlap; after one succeeds, other unfinished attempts SHOULD be canceled, and a subsequent attempt MUST NOT begin within 10 milliseconds of the previous one. The research record locates this support at Section 5 (Connection Attempts). Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. A correct source interpretation can still be inapplicable to a particular design. Confirm DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at Section 3 (Hostname Resolution Query Handling), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4 (Sorting Addresses), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5 (Connection Attempts), which observable configuration, record, or test can confirm applicability here? - Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population? - Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from Section 3 (Hostname Resolution Query Handling); Section 4 (Sorting Addresses); Section 5 (Connection Attempts) to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 8305 — Happy Eyeballs Version 2: Better Connectivity Using Concurrency](https://www.rfc-editor.org/rfc/rfc8305.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8305 — Happy Eyeballs Version 2: Better Connectivity Using Concurrency - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8305.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Race IPv6 and IPv4 connection attempts from one interleaved candidate list,” DSE Security, https://update.dsesecurity.com/updates/race-ipv6-and-ipv4-connection-attempts-from-one-interleaved-candidate-list/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Raise Active Directory functional levels only after every domain controller earns the change > The Windows Server 2025 AD DS functional level permits only Windows Server 2025 domain controllers. Inventory every domain and DC, prove replication and recovery, remove incompatible controllers, and validate dependencies before raising either level. - Canonical URL: https://update.dsesecurity.com/updates/active-directory-functional-level-upgrade-readiness/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T09:23:00+00:00 - Modified: 2026-08-11T14:12:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Checklist - DSE priority: Important - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know The Windows Server 2025 AD DS functional level permits only Windows Server 2025 domain controllers. Inventory every domain and DC, prove replication and recovery, remove incompatible controllers, and validate dependencies before raising either level. ## Potentially affected Active Directory forests and domains; Windows Server domain controllers; DNS, time, SYSVOL, directory-integrated applications, identity synchronization, backup, monitoring, and disaster-recovery processes. ## DSE recommendation Capture the current forest and domain state, map the Microsoft interoperability matrix to every domain controller, resolve replication and SYSVOL issues, test directory recovery, and approve the functional-level change as a separate controlled event. ## Article ## Source facts: functional level governs domain-controller compatibility Microsoft’s [AD DS functional-level documentation](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels) says forest and domain functional levels determine available Active Directory Domain Services capabilities and which Windows Server versions may run as domain controllers. They do not determine the operating systems allowed on ordinary member servers or workstations. The current interoperability table draws a consequential boundary. At the Windows Server 2025 forest and domain functional level, Windows Server 2025 is the supported domain-controller operating system. Windows Server 2016, 2019, and 2022 domain controllers can coexist at the Windows Server 2016 functional level, and Microsoft notes that Windows Server 2019 and 2022 did not introduce newer functional levels of their own. A domain functional level may be higher than its forest functional level, but it cannot be lower than the forest functional level. Microsoft identifies optional 32K database pages as a capability associated with the Windows Server 2025 domain functional level. That feature is not a reason to skip compatibility work: it has its own planning and enablement requirements. Microsoft also states that domains at the Windows Server 2016 functional level must use DFS Replication for SYSVOL. The documented PowerShell controls for raising levels are Set-ADDomainMode and Set-ADForestMode. A domain-controller operating-system upgrade, schema preparation, adding or replacing a controller, and raising a functional level are related but separate changes. Microsoft’s domain-controller upgrade guidance generally favors adding newer servers as domain controllers, moving roles and dependencies, and demoting older controllers rather than treating the functional-level command as the migration itself. ## DSE recommendation: require an identity-service readiness packet Build one packet for the forest and one for every domain before scheduling the change. The packet should be understandable to the person making the go/no-go decision and useful to the person responding if an application fails later. - Inventory the topology. Record every domain, site, subnet, domain controller, global catalog, writable or read-only role, operating-system version, FSMO role, DNS role, replication connection, and time source. Reconcile the inventory with live directory data. - Apply the compatibility gate. Compare every domain controller with Microsoft’s table for the intended level. Find offline, isolated, lab-connected, recovery, or forgotten controllers—not just servers that appear in the main management console. - Prove directory health. Review replication across every naming context and site, DNS registration and resolution, SYSVOL and NETLOGON availability, DFSR state, time synchronization, event logs, backup status, and monitoring. Resolve unexplained errors before the change. - Map consumers. Test applications and appliances that use LDAP, Kerberos, DNS, service accounts, directory searches, federation, certificate services, identity synchronization, or hard-coded domain-controller addresses. Record owners and representative workflows. - Prove recovery. Verify system-state protection and perform a documented recovery exercise appropriate to the environment. Identify Directory Services Restore Mode access, authoritative and non-authoritative restore procedures, console access, media, and escalation ownership. - Remove old controllers cleanly. Transfer or seize roles only through an approved plan, update dependent systems, demote supportedly, remove stale metadata when required, and confirm replication convergence before declaring the old version absent. Schedule the domain-level and forest-level raises as explicit changes after the platform migration has stabilized. Capture the before-and-after values, operator, commands or console actions, timestamps, replication results, DNS and sign-in tests, application checks, and monitoring state. Avoid bundling the raise with controller replacement, network work, certificate changes, or identity-sync upgrades unless the combined recovery plan has been deliberately tested. Finally, distinguish “eligible to raise” from “benefit approved.” The newest functional level should support a documented requirement or lifecycle plan. The safe outcome is a fully understood directory on compatible controllers with verified recovery—not a higher number displayed in an administration tool. ## Official references - Microsoft Learn, [Active Directory Domain Services functional levels](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels), October 30, 2025. - Microsoft Learn, [Upgrade domain controllers to a newer version of Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/upgrade-domain-controllers). ## Primary reference - Name: Microsoft Learn: Active Directory Domain Services functional levels - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels - Source publication date: 2025-10-30 ## Citation and use Preferred citation: “Raise Active Directory functional levels only after every domain controller earns the change,” DSE Security, https://update.dsesecurity.com/updates/active-directory-functional-level-upgrade-readiness/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Raise the RID pool after rollback to prevent identifier reuse > Use AD Forest Recovery - Raising RID pools to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/raise-rid-pool-after-rollback/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:26+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use AD Forest Recovery - Raising RID pools to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of AD Forest Recovery - Raising RID pools ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Raise the RID pool after rollback to prevent identifier reuse. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [AD Forest Recovery – Raising RID pools](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-raise-rid-pool) from Microsoft supports the following bounded statements: - Raising available RID pools prevents a restored domain from reallocating a RID used after the backup point. The research record locates this support at Opening overview. - The domain-wide RID space is maintained in the RID Manager object’s rIDAvailablePool attribute. The research record locates this support at Section: Active Directory RID Pools and rIDAvailablePool. The source support ends with the statements listed above. Use them to examine forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Perform RID arithmetic exactly as documented and record the pre- and post-change values. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section: Active Directory RID Pools and rIDAvailablePool, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to Opening overview; Section: Active Directory RID Pools and rIDAvailablePool and to observable material such as backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [AD Forest Recovery – Raising RID pools](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-raise-rid-pool) — Microsoft ## Primary reference - Name: AD Forest Recovery - Raising RID pools - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-raise-rid-pool - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Raise the RID pool after rollback to prevent identifier reuse,” DSE Security, https://update.dsesecurity.com/updates/raise-rid-pool-after-rollback/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Rank critical components by mission consequence, not replacement cost > The most expensive asset is not always the component whose loss matters most. Trace organizational goals through programs, systems, functions, and components so protection, acquisition, maintenance, and recovery follow operational consequence. - Canonical URL: https://update.dsesecurity.com/updates/rank-critical-components-by-mission-consequence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-11T10:41:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know The most expensive asset is not always the component whose loss matters most. Trace organizational goals through programs, systems, functions, and components so protection, acquisition, maintenance, and recovery follow operational consequence. ## Potentially affected Critical services, system architecture, business continuity, risk owners, capital planning, procurement, maintenance, spares, supplier oversight, incident response, and recovery sequencing. ## DSE recommendation Select one organizational goal, map the programs and systems that support it, decompose critical functions to components, apply documented criticality criteria, and validate priorities with operators and dependency owners. ## Article ## Source facts: criticality traces importance from goals to components NIST Internal Report 8179 describes a Criticality Analysis Process Model for prioritizing programs, systems, and components by their importance to organizational goals and the impact that inadequate operation or loss could have on those goals. NIST notes that finite resources make equal protection of every asset impractical. A structured analysis supports more defensible security, privacy, project, acquisition, maintenance, and upgrade decisions. The model follows a top-down path. It identifies organizational goals and objectives, the programs that support them, the systems that support those programs, the functions and capabilities those systems require, and the components and subcomponents that enable the functions. Baseline criticality is then adjusted using factors relevant to the operating environment, dependencies, threats, vulnerabilities, resilience, and other organizational considerations. Criticality is not identical to purchase price, vulnerability severity, asset count, or a general business label. A low-cost component may be essential because many high-consequence functions depend on it, because no substitute exists, or because its failure is difficult to detect. NIST designed the process for use with broader risk-management methods, not as a replacement for risk assessment. ## DSE recommendation: anchor analysis to one approved organizational goal Choose a specific goal or essential outcome and name its accountable owner. Define what successful performance means, how degradation is recognized, which time periods or conditions matter, and what consequence follows from failure. Avoid beginning with an inventory and declaring familiar assets critical; that bottom-up approach can preserve historical assumptions. Map the programs, services, and systems that materially support the goal. Include externally provided and manual capabilities. For each system, identify the functions required to deliver the outcome, then decompose those functions into components, subcomponents, people, data, facilities, communications, suppliers, and supporting services. ## DSE recommendation: score consequence and dependency transparently - Define the criteria first. Examples include safety, financial loss, legal or contractual impact, duration, affected population, substitutability, detectability, restoration difficulty, and cross-service dependency. - Separate loss modes. Unavailability, corrupted output, unauthorized control, confidentiality loss, degraded performance, and intermittent behavior can have different consequences. - Expose concentration. Identify common identity, power, time, network, data, facility, supplier, and administrative dependencies whose failure reaches several systems. - Test alternatives. Confirm whether a spare, manual process, different supplier, alternate site, or degraded mode actually performs the required function within the tolerable window. - Record uncertainty. Mark unknown component composition, opaque supplier dependencies, incomplete architecture, assumptions, and disputed scores. Uncertainty is a finding, not a reason to fabricate precision. ## DSE recommendation: turn the ranking into different treatment For the highest-criticality components, decide what must change: stronger access and change controls, integrity verification, monitoring, diverse alternatives, protected spares, supplier evidence, shorter recovery objectives, more frequent tests, specialized skills, or executive exception authority. Tie procurement and maintenance priorities to the analysis, and ensure incident plans identify which components may be isolated or restored first. Validate the map through walk-throughs and exercises with operators who understand hidden dependencies. Remove a supposedly critical component and see whether the alternate path works; remove a supposedly ordinary one and observe unexpected propagation. Reassess after mergers, architecture or supplier changes, new automated decisions, incidents, and altered organizational goals. Retain the scope, hierarchy, criteria, evidence, scores, dependencies, assumptions, participants, approvals, and resulting decisions. Compare the result with asset, incident, maintenance, and recovery records so plans use the same priorities. A ranked list without traceable reasoning will decay into opinion. A useful criticality analysis shows exactly how a component’s condition can affect an organizational outcome and what the organization chose to do about it. ## Official references - National Institute of Standards and Technology, [NISTIR 8179: Criticality Analysis Process Model—Prioritizing Systems and Components](https://csrc.nist.gov/pubs/ir/8179/final), April 9, 2018; reviewed August 11, 2026. ## Primary reference - Name: NISTIR 8179: Criticality Analysis Process Model - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/pubs/ir/8179/final - Source publication date: 2018-04-09 ## Citation and use Preferred citation: “Rank critical components by mission consequence, not replacement cost,” DSE Security, https://update.dsesecurity.com/updates/rank-critical-components-by-mission-consequence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Rank DNS data credibility before caching conflicting answers > Use RFC 2181 — Clarifications to the DNS Specification to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/rank-dns-data-credibility-before-caching-conflicting-answers/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:33+00:00 - Modified: 2026-08-27T12:18:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 2181 — Clarifications to the DNS Specification to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 2181 — Clarifications to the DNS Specification ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Rank DNS data credibility before caching conflicting answers. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 2181 — Clarifications to the DNS Specification](https://www.rfc-editor.org/rfc/rfc2181.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - A server must not merge response records with cached records to construct one RRset; it retains one complete set and ignores or replaces the other. The research record locates this support at Section 5.4 (Receiving RRSets). - Primary-zone and transferred-zone data rank above authoritative answer data, which ranks above non-authoritative answers and additional information. The research record locates this support at Section 5.4.1 (Ranking data), credibility tiers. - Unauthenticated additional data and non-authoritative authority data must not be cached in a way that later promotes them into answer data. The research record locates this support at Section 5.4.1 (Ranking data), least-trustworthy tier. Only the traced statements above are asserted as source facts. Apply the review to authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Section 5.4 (Receiving RRSets), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 5.4.1 (Ranking data), credibility tiers, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5.4.1 (Ranking data), least-trustworthy tier, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from Section 5.4 (Receiving RRSets); Section 5.4.1 (Ranking data), credibility tiers; Section 5.4.1 (Ranking data), least-trustworthy tier to the observed environment. Useful domain evidence includes zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior; label every item with scope, timestamp, collector, and stable identifier. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [RFC 2181 — Clarifications to the DNS Specification](https://www.rfc-editor.org/rfc/rfc2181.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 2181 — Clarifications to the DNS Specification - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc2181.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Rank DNS data credibility before caching conflicting answers,” DSE Security, https://update.dsesecurity.com/updates/rank-dns-data-credibility-before-caching-conflicting-answers/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Ransomware first response: a calm containment checklist > When ransomware or destructive encryption is suspected, activate the incident plan, isolate affected systems in a coordinated way, preserve evidence, use known-safe communications, protect identities and backups, and involve qualified responders before rebuilding. - Canonical URL: https://update.dsesecurity.com/updates/ransomware-first-response-checklist/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:57+00:00 - Modified: 2026-07-19T19:03:57+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know When ransomware or destructive encryption is suspected, activate the incident plan, isolate affected systems in a coordinated way, preserve evidence, use known-safe communications, protect identities and backups, and involve qualified responders before rebuilding. ## Potentially affected Organizations observing ransom notes, rapid file encryption, inaccessible systems, destructive activity, or credible ransomware and data-extortion indicators. ## DSE recommendation Activate the approved incident plan and contact the designated response lead immediately from a known-safe channel; do not begin an improvised cleanup. ## Article Suspected ransomware requires fast action, but improvised action can destroy evidence, interrupt unaffected services, or allow the attacker to observe the response. Use the organization’s approved incident-response plan and a known-safe communication channel. ## What the official source says Source fact: Part 2 of CISA’s #StopRansomware Guide provides a ransomware and data-extortion response checklist. CISA places the initial steps in sequence: determine which systems are impacted and immediately isolate them; power down devices only when they cannot otherwise be disconnected, recognizing that shutdown can remove evidence held in volatile memory; then continue coordinated containment and analysis. ## First-response checklist - Activate the plan. Contact the designated incident lead, executive decision-maker, IT/security responder, and other required advisers using verified contact information. - Start an incident record. Note who observed what, the exact time, affected systems, ransom-note details, unusual account activity, and actions taken. Separate confirmed observations from assumptions. - Isolate in a coordinated manner. Follow responder direction to remove affected devices or network segments from wired, wireless, remote-access, and cloud connectivity. Do not connect removable media. - Preserve evidence. Do not delete ransom notes, reimage systems, run cleanup tools, or broadly reset systems before qualified responders determine what evidence is needed. - Use known-safe communications. Assume ordinary email or collaboration tools may be visible to an attacker until evaluated. Use the approved out-of-band method. - Protect identities and remote access. Qualified administrators should evaluate involved accounts, privileged access, active sessions, remote services, cloud identities, and suspicious enrollment or recovery changes. - Protect backups and logs. Restrict access to backup administration, preserve relevant logs, and avoid attaching known-good backup media to a potentially compromised environment. - Engage required parties. Follow organizational procedures for legal counsel, cyber insurance, law enforcement, CISA, regulators, customers, employees, and communications. Applicability and timing require qualified review. ## Power and isolation decisions DSE recommendation: prefer coordinated network isolation when it can be performed safely. CISA notes that powering down may be necessary when a device cannot be disconnected, but it can eliminate volatile evidence. Do not use a universal “always shut down” or “never shut down” rule; follow the approved plan and responder direction. ## Do not rush into recovery Recovery should begin only after the team understands the likely entry path, affected scope, persistence risk, credential exposure, and clean recovery environment. Prioritize services using the approved critical-asset list. Validate backups before restoration and change affected credentials after systems are cleaned and persistence is addressed. This checklist is operational education, not digital-forensics, legal, regulatory, insurance, or ransom-payment advice. DSE should not be represented as providing those specialized services unless expressly contracted. Practical next step: print or securely store the incident contacts and isolation authority before an event. During an event, record every action and obtain qualified direction before cleanup or restoration. ## Primary reference - Name: CISA #StopRansomware Guide - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/resources-tools/resources/stopransomware-guide - Source publication date: 2023-10-19 ## Citation and use Preferred citation: “Ransomware first response: a calm containment checklist,” DSE Security, https://update.dsesecurity.com/updates/ransomware-first-response-checklist/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Re-certify physical access from the role owner—not from the cardholder list > A cardholder export shows what the system grants, not what a person still needs. Have accountable role and area owners affirm required access, challenge exceptions, remove stale grants, and verify the controller received the change. - Canonical URL: https://update.dsesecurity.com/updates/recertify-physical-access-from-the-role-owner/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-17T13:10:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Access Control, Cybersecurity - Reading time: 3 minutes ## What you need to know A cardholder export shows what the system grants, not what a person still needs. Have accountable role and area owners affirm required access, challenge exceptions, remove stale grants, and verify the controller received the change. ## Potentially affected Employees, contractors, visitors with recurring access, badges and mobile credentials, access levels, schedules, door groups, sensitive areas, HR and vendor lifecycle events, physical keys used as exceptions, PACS integrations, and audit evidence. ## DSE recommendation Build a complete identity-to-access inventory, route each grant to the accountable role and area owners with business context, expire or remove unsupported access, reconcile changes to field panels and exceptions, and retain evidence of decision and verification. ## Article ## Source facts: authorization lists are meant to be maintained and reviewed [NIST Special Publication 800-53 Revision 5.1](https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1-derived-OSCAL.pdf), control PE-2, calls for developing, approving, and maintaining a list of individuals authorized for physical access, issuing authorization credentials, reviewing the list at an organization-defined frequency, and removing people when access is no longer required. Its first enhancement addresses authorization based on position or role. CISA’s [Facility Access Control: An Interagency Security Committee Best Practice](https://www.cisa.gov/sites/default/files/2025-02/Facility%20Access%20Control%20-%20An%20Interagency%20Security%20Committee%20Best%20Practice-02-20.pdf) discusses the access-control process for federal facilities, including employees, visitors, screening, authentication, and physical access control systems. It stresses that risk and operations shape the selected controls. Both publications are U.S. federal guidance. They do not automatically impose a particular review interval or access model on a private organization. Applicable law, regulation, contract, collective bargaining, safety needs, building rules, and the organization’s risk decisions govern. The DSE process below is an operational recommendation, not a compliance determination. ## DSE recommendation: make need the input and system state the verified output Do not send managers a raw list of badge numbers and ask whether it “looks right.” Build a review package around people and work. For each identity, show employer or sponsor, status, role, home location, supervisor, contract end date, credential type, access levels, schedules, sensitive doors, last relevant use where lawful, and exceptions. Separate reliable source data from unresolved mismatches. - Define ownership. The manager or contract sponsor confirms that the person still requires access for assigned work. The area owner confirms that the role may enter the protected space. Security administers the system but should not invent the business need. - Review roles before people. Validate what each standard role should receive, including schedules and holidays. Removing obsolete doors from a role can correct many cardholders consistently. Keep high-risk and emergency roles narrow and named. - Challenge direct grants. Identify access outside a standard role, 24-hour schedules, broad master groups, temporary projects, transferred staff, dormant credentials, duplicate identities, indefinite contractors, and people whose manager or sponsor is missing. Require a reason, owner, and expiry. - Resolve lifecycle conflicts. Reconcile HR, contractor, training, licensing, safety, tenant, and PACS records. A person marked active in one system may have changed role or site in another. Escalate discrepancies rather than silently choosing the most permissive state. - Apply with control. Use approved change records, second review for sensitive areas, and a defined emergency-access path. Consider safety and continuity before mass removal. Do not use access history alone to revoke a grant that is legitimately needed only during rare events. - Verify the field result. Confirm removed access is absent from the credential, access level, downstream controller or lock, mobile credential service, visitor platform, and documented physical-key exception. Sample denied transactions or use an approved test credential without inconveniencing occupants. Track completion by decision quality, not by percentage of emails answered. An approval with no accountable owner, “keep all,” or an unresolved system mismatch is not complete. Age outstanding reviews, suspend or escalate according to policy, and give security leadership a view of unsupported high-risk access. Retain the reviewed population, data cutoff, decisions, approvers, changes, verification, unresolved exceptions, and next due date. Protect the review package because it maps people to secured areas. The result should answer two different questions with evidence: why the person needs entry, and whether the deployed system now enforces that approved need. Measure unsupported direct grants, overdue decisions, identities without sponsors, expired contractors still enabled, failed controller updates, and high-risk exceptions by age. Stop a review wave when source data is materially incomplete or the change pipeline cannot verify removals. Fix the data or deployment control first; a fast attestation on an unreliable population creates false assurance. ## Official references - National Institute of Standards and Technology, [SP 800-53 Revision 5.1](https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1-derived-OSCAL.pdf), PE-2 Physical Access Authorizations. - Cybersecurity and Infrastructure Security Agency, Interagency Security Committee, [Facility Access Control: An ISC Best Practice](https://www.cisa.gov/sites/default/files/2025-02/Facility%20Access%20Control%20-%20An%20Interagency%20Security%20Committee%20Best%20Practice-02-20.pdf). ## Primary reference - Name: NIST SP 800-53 Revision 5.1: Security and Privacy Controls for Information Systems and Organizations - Authority: National Institute of Standards and Technology - URL: https://csrc.nist.gov/CSRC/media/Projects/risk-management/800-53%20Downloads/800-53r5/SP_800-53_v5_1-derived-OSCAL.pdf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Re-certify physical access from the role owner—not from the cardholder list,” DSE Security, https://update.dsesecurity.com/updates/recertify-physical-access-from-the-role-owner/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Re-measure door force and closing speed after every hardware change > Locks, seals, closers, hinges, operators, and access-control changes interact. Re-test the completed opening because a compliant component can still produce a deficient doorway. - Canonical URL: https://update.dsesecurity.com/updates/remeasure-door-force-and-closing-speed-after-hardware-change/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:49+00:00 - Modified: 2026-08-25T21:36:17+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Checklist - DSE priority: Important - Topics: Access Control - Reading time: 2 minutes ## What you need to know Locks, seals, closers, hinges, operators, and access-control changes interact. Re-test the completed opening because a compliant component can still produce a deficient doorway. ## Potentially affected Accessible-route doors and gates changed by electric locks, latch hardware, closers, hinges, weather seals, operators, power transfers, or frame work. ## DSE recommendation Measure force and closing behavior after the complete hardware set is installed and adjusted, with fire-rated and local-code requirements resolved by qualified authorities. ## Article Bottom line: an electric strike, maglock, door-position switch, cable transfer, new seal, or access-control timing change can alter how a door opens, closes, and latches. The finished assembly should be measured again rather than accepted from component submittals. ## Source fact: accessibility standards specify closing time and opening force Sections 404.2.8 and 404.2.9 of the [2010 ADA Standards — Closing Speed and Opening Force](https://www.access-board.gov/ada/chapter/ch04/#40428-closing-speed) address closing speed and opening force. The standards specify a minimum closer sweep time from 90 degrees to 12 degrees, a separate minimum time for spring hinges, and a maximum force for opening specified non-fire-rated interior hinged, sliding, and folding doors. The text includes exceptions and treats fire doors differently for force. These criteria apply to the opening in operation. A closer’s model rating or an installer setting is not the same as a measurement after every latch, seal, hinge, and access-control component is engaged. ## Source boundary and applicability The Access Board standard is an authoritative federal source, but the correct requirement depends on doorway type, accessible route, fire rating, referenced standards, local adoption, existing-facility status, and authority having jurisdiction. The cited force provision does not set a universal five-pound maximum for every door. This article is not legal or code advice. ## Applicability questions - Is the door fire-rated, on an accessible route, or part of required egress? - Which closer, hinge, latch, lock, seal, operator, and transfer device affect movement? - Does access authorization fully release the latch before the user applies force? - Are measurements being taken at the correct location, direction, and door state? - Can seasonal pressure, temperature, flooring, or building airflow change performance? ## DSE recommendation: make operational measurement a closeout requirement The following steps are DSE recommendations based on the cited source. Have qualified door, accessibility, and fire/life-safety personnel identify the applicable criteria and measurement method. After final access-control programming and complete hardware adjustment, measure opening force and closing behavior in all relevant operating modes. Verify authorization, latch release, manual operation, relatching, door-position monitoring, and any automatic operator together. If adjustment improves force but prevents reliable latching or required fire-door behavior, stop and resolve the system-level conflict; do not defeat a closer, latch, or rated assembly. Re-test after seasonal commissioning where pressure or weather produces material variation. ## Verification and evidence Retain the applicable-criteria determination, door and hardware schedule, instrument identification, method, measured values, access-control state, environmental conditions, deficiency and correction record, and qualified sign-off. Add remeasurement to change control for strikes, maglocks, closers, seals, hinges, operators, fire interfaces, and unlock timing. ## Official references - [2010 ADA Standards, Sections 404.2.8 and 404.2.9 — Closing Speed and Opening Force](https://www.access-board.gov/ada/chapter/ch04/#40428-closing-speed) – United States Access Board ## Primary reference - Name: 2010 ADA Standards, Sections 404.2.8 and 404.2.9 — Closing Speed and Opening Force - Authority: www.access-board.gov - URL: https://www.access-board.gov/ada/chapter/ch04/#40428-closing-speed - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Re-measure door force and closing speed after every hardware change,” DSE Security, https://update.dsesecurity.com/updates/remeasure-door-force-and-closing-speed-after-hardware-change/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Read a Health Service fault as a possible root-cause summary > Why can one Storage Spaces Direct fault represent several affected components? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-150-read-a-health-service-fault-as-a-possible-root-cause-summary/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:41+00:00 - Modified: 2026-09-08T18:23:28+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know Why can one Storage Spaces Direct fault represent several affected components? ## Potentially affected Use this review when triaging a Health Service fault list. ## DSE recommendation Start with the reported cause and build a short impact map for the dependent resources. ## Article ## Source facts The Health Service monitors a Storage Spaces Direct cluster and produces faults for detected problems. It can combine effects that share an underlying cause. Microsoft’s example reports a failed server as the root fault rather than separately reporting every drive whose connectivity was lost with that server. The documented fault query returns nothing when no faults are present. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/failover-clustering/health-service-faults). ## Applicability Use this review when triaging a Health Service fault list. Identify the cluster, observation time, reported entity, and affected workload. Distinguish a consolidated report from an inventory of every component affected by the event. ## DSE recommendation Start with the reported cause and build a short impact map for the dependent resources. Correlate the fault with the corresponding node or hardware observations before opening separate incidents for each consequence. Assign an owner to the underlying problem and preserve the original fault details. Keep workload recovery evidence separate from disappearance of the initial fault. ## Verification After an approved correction, query faults again and compare the affected resource state with the original impact map. Test the selected workload operation and record any remaining dependent failure. If the fault list is empty, retain that observation with its timestamp rather than treating it as proof of every application’s health. Escalate discrepancies to the appropriate layer owner. ## Official references [Microsoft Learn: Health Service faults](https://learn.microsoft.com/en-us/windows-server/failover-clustering/health-service-faults). Source reviewed September 8, 2026. ## Primary reference - Name: Health Service faults - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/failover-clustering/health-service-faults - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Read a Health Service fault as a possible root-cause summary,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-150-read-a-health-service-fault-as-a-possible-root-cause-summary/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Read a RAS GRE benchmark in the context of its TCP session count > What does the documented RAS Gateway GRE experiment establish about a single TCP flow? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-226-read-a-ras-gre-benchmark-in-the-context-of-its-tcp-session-count/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:25+00:00 - Modified: 2026-09-08T18:29:34+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know What does the documented RAS Gateway GRE experiment establish about a single TCP flow? ## Potentially affected Administrators interpreting Microsoft's documented Windows Server version 1709 RAS GRE performance experiment. ## DSE recommendation Write a benchmark plan that records the TCP session count alongside the GRE gateway configuration. ## Article ## Source facts The cited Microsoft page reports a non-SDN test environment using Windows Server version 1709. Its gateway VMs are configured with ten cores and eight gigabytes of memory, with one active and one passive gateway. When the experiment changes from multiple TCP sessions to one TCP session, Microsoft reports that only one CPU core reaches maximum capacity on the gateway VMs. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/remote/remote-access/ras-gateway/RAS-Gateway-GRE-Perf). ## Applicability Treat the page as a versioned experiment rather than a present-day throughput promise. Compare its gateway role, VM resources, tunnel type, and session count with the system being assessed. Identify whether the actual application uses one sustained flow or many independent flows. ## DSE recommendation Write a benchmark plan that records the TCP session count alongside the GRE gateway configuration. Ask the application owner which flow pattern represents normal and peak use. Keep the active and passive gateway observations separate, and collect per-core evidence instead of only an overall CPU average. Use the historical result to shape questions for a current pilot, not to select an obsolete deployment. ## Verification Run the approved single-flow and multi-flow cases on the current supported platform. Compare per-core utilization and completed application traffic with the stated test conditions. Record the operating-system build and resource settings with every result. Explain differences from the historical experiment rather than reporting its numbers as measurements of the new system. ## Official references [Microsoft Learn: RAS Gateway GRE Tunnel Throughput and Performance](https://learn.microsoft.com/en-us/windows-server/remote/remote-access/ras-gateway/RAS-Gateway-GRE-Perf). Source reviewed September 8, 2026. ## Primary reference - Name: RAS Gateway GRE Tunnel Throughput and Performance - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/remote/remote-access/ras-gateway/RAS-Gateway-GRE-Perf - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Read a RAS GRE benchmark in the context of its TCP session count,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-226-read-a-ras-gre-benchmark-in-the-context-of-its-tcp-session-count/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Read objectVersion and rangeUpper before mapping AD and Exchange schema levels > Use Find the Current Active Directory Schema Version to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/read-objectversion-rangeupper-map-ad-exchange-schema-levels/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:04+00:00 - Modified: 2026-08-27T12:56:25+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: IT, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Find the Current Active Directory Schema Version to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Find the Current Active Directory Schema Version ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Read objectVersion and rangeUpper before mapping AD and Exchange schema levels. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Find the Current Active Directory Schema Version](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/find-active-directory-schema) from Microsoft supports the following bounded statements: - The Active Directory schema level is the objectVersion value on CN=Schema,CN=Configuration in the forest, which Microsoft maps to Windows Server versions in its objectVersion table. The research record locates this support at Finding the schema version; Mapping the objectVersion attribute. - The Exchange schema level is the rangeUpper value on CN=ms-Exch-Schema-Version-Pt, which Microsoft directs readers to map with the Exchange 2016 or Exchange 2019 version tables. The research record locates this support at Find the current Exchange Schema version; Mapping the rangeUpper attribute. Only the traced statements above are asserted as source facts. Apply the review to forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles after confirming that the source and deployed context match. ## What the source does not establish These lookups discover and map current values; they do not authorize, execute, or validate a schema extension or an Exchange upgrade. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Finding the schema version; Mapping the objectVersion attribute, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Find the current Exchange Schema version; Mapping the rangeUpper attribute, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles are in and out of scope? - Which condition in Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of forests, domains, controllers, directory partitions, trusts, sites, replication links, service accounts, and delegated roles, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Windows DNS, time synchronization, network reachability, PKI, backups, virtualization safeguards, and privileged identity before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations Finding the schema version; Mapping the objectVersion attribute; Find the current Exchange Schema version; Mapping the rangeUpper attribute adjacent to the sanitized artifacts used for comparison. Prefer directory and policy exports, replication and locator tests, event logs, trust state, role ownership, and controlled authentication tests, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Find the Current Active Directory Schema Version](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/find-active-directory-schema) — Microsoft ## Primary reference - Name: Find the Current Active Directory Schema Version - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/find-active-directory-schema - Source publication date: 2025-07-08 ## Citation and use Preferred citation: “Read objectVersion and rangeUpper before mapping AD and Exchange schema levels,” DSE Security, https://update.dsesecurity.com/updates/read-objectversion-rangeupper-map-ad-exchange-schema-levels/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Read storage-pool and virtual-disk health states separately > What does a Storage Spaces warning mean at the pool versus virtual-disk layer? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-204-read-storage-pool-and-virtual-disk-health-states-separately/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:47+00:00 - Modified: 2026-09-08T18:29:33+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 2 minutes ## What you need to know What does a Storage Spaces warning mean at the pool versus virtual-disk layer? ## Potentially affected Administrators investigating health and operational states in Storage Spaces or Storage Spaces Direct. ## DSE recommendation Create an incident record that traces the affected volume to its virtual disk, pool, and underlying drives. ## Article ## Source facts Microsoft says a pool warning means the pool remains accessible but has missing or failed drives and may have reduced resilience. An unknown or unhealthy pool is read-only until it returns to an acceptable health state. A virtual-disk warning has a different meaning: some data copies are unavailable, but at least one copy can still be read. [Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-states). ## Applicability Identify whether the reported state belongs to a physical drive, storage pool, virtual disk, or volume. Record health and operational status together. Do not translate the word warning into a single action without identifying the object and its documented meaning. ## DSE recommendation Create an incident record that traces the affected volume to its virtual disk, pool, and underlying drives. Preserve the initial state and any missing-device identifiers before attempting repair. Ask the storage owner to assess remaining resilience and the workload impact. Avoid deleting or recreating an object to clear an unexplained read-only condition. Establish which documented recovery action fits the actual object state. ## Verification Requery the same object identifiers after the approved corrective action and compare health, operational status, and application access with the initial record. Confirm restored resilience separately from basic readability. If the layer-level states disagree or a device remains missing, leave the finding open and escalate with the complete object relationship. ## Official references [Microsoft Learn: Storage Spaces and Storage Spaces Direct health and operational states](https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-states). Source reviewed September 8, 2026. ## Primary reference - Name: Storage Spaces and Storage Spaces Direct health and operational states - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/storage-spaces/storage-spaces-states - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Read storage-pool and virtual-disk health states separately,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-204-read-storage-pool-and-virtual-disk-health-states-separately/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Read System Insights forecasts with their status and local context > What evidence should accompany a System Insights capacity prediction? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-003-read-system-insights-forecasts-with-their-status-and-local-context/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:17:08+00:00 - Modified: 2026-09-08T18:17:13+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: Business Continuity, IT - Reading time: 1 minutes ## What you need to know What evidence should accompany a System Insights capacity prediction? ## Potentially affected Use this review when evaluating System Insights output for a Windows Server capacity decision. ## DSE recommendation Ask the server owner to describe planned changes that may affect the forecast. ## Article ## Source facts A System Insights capability applies a statistical or machine-learning model to system data. Additional capabilities can be introduced without an operating-system update. A result includes a status and explanatory description; Error or None can indicate that no prediction was made. The default forecasting models train on the individual machine and are intended to detect longer-term usage trends. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/manage/system-insights/understanding-capabilities). ## Applicability Use this review when evaluating System Insights output for a Windows Server capacity decision. Identify the capability, machine, and observation period. Read the explanatory result alongside the status rather than selecting a color alone. ## DSE recommendation Ask the server owner to describe planned changes that may affect the forecast. Keep the prediction, its interpretation, and the resulting capacity decision together. Separate a recommendation to investigate from an approved purchase or workload move. Establish who will revisit the prediction and which observed resource level would justify an earlier review. ## Verification Compare a retained prediction with later observed usage from the same server. Record both the time horizon and any workload changes between observations. Investigate missing or error results separately from a healthy prediction. Document where the forecast was useful and where the underlying deployment changed before using it for another planning cycle. ## Official references [Microsoft Learn: System Insights capabilities in Windows Server](https://learn.microsoft.com/en-us/windows-server/manage/system-insights/understanding-capabilities). Source reviewed September 8, 2026. ## Primary reference - Name: System Insights capabilities in Windows Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/system-insights/understanding-capabilities - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Read System Insights forecasts with their status and local context,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-003-read-system-insights-forecasts-with-their-status-and-local-context/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Read the Identity Security dashboard as posture and threat context, not proof of control > Use Identity Security dashboard overview (Preview) to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/read-identity-security-dashboard-as-context-not-proof/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:11+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Identity Security dashboard overview (Preview) to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Identity Security dashboard overview (Preview) ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Read the Identity Security dashboard as posture and threat context, not proof of control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Identity Security dashboard overview (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/dashboard) from Microsoft supports the following bounded statements: - The dashboard presents data for analyzing security posture, protection, vulnerabilities, and recommended actions. The research record locates this support at Opening overview. - Its graphs and widgets cover identity threat and response subjects including unauthorized access, account compromise, insider threats, and abnormal activity. The research record locates this support at Dashboard purpose paragraph. The source support ends with the statements listed above. Use them to examine identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The dashboard is marked Preview and is being rolled out gradually; displayed insights are not evidence that recommendations are complete or controls effective. No current deployment state or change approval follows from the source alone. Validate Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Dashboard purpose paragraph, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of identity alerts, investigations, remediation roles, evidence retention, escalation, exclusions, and incident workflows, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, time, cloud portals, endpoint data, network telemetry, privileged access, and response staffing in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening overview; Dashboard purpose paragraph. Favor alert records, investigation timelines, analyst actions, tuning or exclusion approvals, remediation results, and case closure, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Identity Security dashboard overview (Preview)](https://learn.microsoft.com/en-us/defender-for-identity/dashboard) — Microsoft ## Primary reference - Name: Identity Security dashboard overview (Preview) - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/dashboard - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Read the Identity Security dashboard as posture and threat context, not proof of control,” DSE Security, https://update.dsesecurity.com/updates/read-identity-security-dashboard-as-context-not-proof/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Read the U.S. Cyber Trust Mark as a baseline—not a blank check > The FCC’s voluntary U.S. Cyber Trust Mark is designed for qualifying consumer wireless IoT products and a QR-linked registry. It can strengthen procurement evidence, but it is not an enterprise architecture review or a forever-secure guarantee. - Canonical URL: https://update.dsesecurity.com/updates/read-the-u-s-cyber-trust-mark-as-a-baseline-not-a-blank-check/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Explainer - DSE priority: Information - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 4 minutes ## What you need to know The FCC’s voluntary U.S. Cyber Trust Mark is designed for qualifying consumer wireless IoT products and a QR-linked registry. It can strengthen procurement evidence, but it is not an enterprise architecture review or a forever-secure guarantee. ## Potentially affected Consumers and organizations evaluating consumer wireless IoT products, plus procurement teams considering whether the mark is relevant to cameras, sensors, appliances, or other connected products. ## DSE recommendation Verify the exact product in the official registry when operational, read its support and security details, then continue the organization’s own risk, architecture, privacy, lifecycle, and vendor review. ## Article ## Source fact: this is a voluntary consumer-IoT program In [FCC 24-26](https://docs.fcc.gov/public/attachments/FCC-24-26A1.pdf), the Federal Communications Commission established a voluntary cybersecurity labeling program for wireless consumer Internet of Things products. The FCC IoT Label combines the U.S. Cyber Trust Mark with a scannable QR code intended to lead to a public registry containing product-specific information. The program is based on minimum cybersecurity requirements informed by NIST’s consumer IoT baseline. The FCC rules define consumer IoT products as products intended primarily for consumer rather than enterprise or industrial use. They exclude FDA-regulated medical devices and NHTSA-regulated motor vehicles and equipment. A qualifying product can include an IoT device plus components necessary to use it beyond basic operational features, such as a backend or gateway. The mark is therefore not a general certification for every enterprise camera, access controller, server, network, installer, or deployment. ## Implementation status matters On April 13, 2026, the FCC [selected ioXt Alliance as a new Lead Administrator](https://docs.fcc.gov/public/attachments/DA-26-354A1.pdf) after the prior Lead Administrator withdrew. The notice says ioXt will support stakeholder work on additional standards and test procedures while the FCC retains oversight, and notes that prior recommendations were still under FCC review for public comment. DSE reviewed official FCC materials through August 4, 2026. Buyers should check the current FCC program page and registry rather than assuming that a logo, vendor announcement, or old screenshot represents an active authorization. ## What an authorized mark is designed to show When the program is operating for the relevant product class, an authorized mark means the identified consumer IoT product was tested and found to meet the FCC program requirements applicable to that authorization. A Cybersecurity Label Administrator—not the testing lab—licenses use of the mark, subject to FCC rules and oversight. The QR-linked record is essential because the small visual mark cannot convey product identity, support information, test scope, or lifecycle details by itself. This is more useful than a vendor’s unsupported statement that a product is secure. It supplies a governed baseline, a conformity-assessment process, an exact registry record, and consumer-facing information that a procurement file can preserve. ## What the mark does not prove - It does not mean the product has no vulnerabilities, cannot be compromised, or will remain secure forever. - It does not certify the buyer’s passwords, network segmentation, cloud configuration, mobile devices, integrations, installation, monitoring, or incident response. - It does not establish that the product is suitable for an enterprise, industrial, life-safety, evidentiary, regulatory, or high-availability use. - It does not replace FCC radio-frequency equipment authorization; FCC 24-26 treats the two processes separately. - It does not by itself answer privacy questions about sensors, data collection, retention, sharing, location, microphone use, or account deletion. - It does not establish compatibility, image quality, analytic accuracy, accessibility, physical durability, or support quality. These boundaries are DSE’s procurement interpretation of the FCC program scope, not a criticism of the mark and not legal advice. ## DSE recommendation: use a five-part evidence check - Match: Scan the QR code and independently reach the official registry. Match manufacturer, model, hardware and software identifiers, label status, and product components. A similar family name is not enough. - Read: Capture the support period, update mechanism, security information, and other registry fields applicable when the product is evaluated. Confirm who notifies owners and what happens when support ends. - Bound: Record the standards and testing scope that applied. Do not transfer a consumer-product result to an enterprise variant, later revision, unlisted gateway, or surrounding system. - Extend: Continue ordinary due diligence: data flows, identity, encryption, vulnerability disclosure, update history, logs, local and cloud dependence, reset, ownership transfer, export, deletion, availability, and vendor exit. - Recheck: Revisit the registry before purchase, deployment, major update, renewal, transfer, and continued use near the end of support. Preserve dated evidence with the procurement record. ## Make absence mean only absence Because participation is voluntary and scope is consumer wireless IoT, an unmarked product is not automatically insecure. It may be out of scope, not submitted, or still awaiting a mature product-class process. Conversely, a marked product is not automatically the best fit. DSE recommends treating the mark as one strong, bounded input in a risk-based procurement decision—and documenting why the total evidence supports the intended deployment. ## Official sources - [FCC 24-26, IoT Labeling Order](https://docs.fcc.gov/public/attachments/FCC-24-26A1.pdf) - [FCC DA 26-354, Lead Administrator selection](https://docs.fcc.gov/public/attachments/DA-26-354A1.pdf) - [Federal Register: Cybersecurity Labeling for Internet of Things](https://www.govinfo.gov/app/details/FR-2024-08-09/2024-17482) - [NISTIR 8425, Profile of the IoT Core Baseline for Consumer IoT Products](https://csrc.nist.gov/pubs/ir/8425/final) ## Primary reference - Name: FCC Public Notice DA 26-354 — U.S. Cyber Trust Mark Lead Administrator - Authority: docs.fcc.gov - URL: https://docs.fcc.gov/public/attachments/DA-26-354A1.pdf - Source publication date: 2026-04-13 ## Citation and use Preferred citation: “Read the U.S. Cyber Trust Mark as a baseline—not a blank check,” DSE Security, https://update.dsesecurity.com/updates/read-the-u-s-cyber-trust-mark-as-a-baseline-not-a-blank-check/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Reassess broad VPN access for a hybrid, least-privilege environment > Modern network-access guidance asks organizations to examine broad remote connectivity and compare risk-based, resource-level approaches without assuming every VPN requires replacement. - Canonical URL: https://update.dsesecurity.com/updates/hybrid-network-access-vpn-least-privilege/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T21:27:10+00:00 - Modified: 2026-07-19T21:27:10+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 2 minutes ## What you need to know Modern network-access guidance asks organizations to examine broad remote connectivity and compare risk-based, resource-level approaches without assuming every VPN requires replacement. ## Potentially affected Organizations using remote-access VPNs, cloud applications, hybrid networks, partner connectivity, remote administration, operational technology, SSE, SASE, or zero-trust access. ## DSE recommendation Inventory current access, map required resources, assess VPN and modern alternatives, design least-privilege policy, pilot operational behavior, and remove obsolete broad reachability. ## Article A remote-access design created for an on-premises network may grant more reach than a user needs in a hybrid environment. Modernization should begin with required business transactions and risk, not an assumption that a new service category is automatically safer. ## What the joint guidance says Source fact: CISA, FBI, and international partners published Modern Approaches to Network Access Security to help organizations understand vulnerabilities, threats, and practices associated with traditional remote access and VPN deployment, including business risk from misconfiguration. Source fact: The guidance encourages businesses of all sizes to evaluate approaches such as zero trust, Secure Service Edge, and Secure Access Service Edge. These architectures can provide greater activity visibility and more granular, risk-based access control through policy decisions. The guide addresses hybrid and cloud transitions and considers both IT and operational-technology networks. The agencies do not state that every VPN is inherently insecure or order every organization to replace one. They call for careful analysis of changing security needs and the risks of broad or misconfigured remote access. ## Map access at the resource level DSE recommendation: inventory every remote-access path, gateway, exposed management interface, VPN product, version, support state, authentication method, user and service identity, reachable route, privileged function, logging source, and emergency dependency. Identify unused paths and access that is broad only because the existing architecture makes narrowing difficult. - Map users, devices, partners, administrators, and services to the specific applications and transactions they require. - Document security, privacy, data-location, latency, availability, offline, safety, support, inspection, and logging requirements. - Compare a hardened retained VPN, resource-level zero-trust access, SSE, SASE, and hybrid combinations against those requirements. - Define least-privilege and context-aware policy, strong authentication, device expectations, session controls, and independent telemetry. - Preserve a tested emergency and rollback path that does not silently restore unnecessary broad access. ## Pilot the operating failure modes DSE recommendation: pilot with bounded users and resources. Test ordinary and privileged workflows, unmanaged or noncompliant devices, provider outage, identity outage, policy error, application incompatibility, latency, failover, investigation visibility, help-desk recovery, and rollback. Review denies and exceptions before expanding. After migration, remove obsolete routes, accounts, gateways, split tunnels, and firewall rules through change control. Continue monitoring vulnerabilities, support status, policy drift, unexpected destinations, and access that no longer has a business owner. ## Applicability and limits SSE and SASE describe architectural approaches, not guaranteed outcomes or certifications. Some environments will retain VPN connectivity because of application, availability, OT, performance, or support constraints. Vendor features and CISA’s dated vulnerability counts can change; use the current KEV catalog and current vendor information for decisions. ## Official reference [Modern Approaches to Network Access Security](https://www.cisa.gov/news-events/alerts/2024/06/18/cisa-and-partners-release-guidance-modern-approaches-network-access-security) — joint guidance on VPN risk and resource-focused alternatives. ## Primary reference - Name: CISA and partners: Modern Approaches to Network Access Security - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/news-events/alerts/2024/06/18/cisa-and-partners-release-guidance-modern-approaches-network-access-security - Source publication date: 2024-06-18 ## Citation and use Preferred citation: “Reassess broad VPN access for a hybrid, least-privilege environment,” DSE Security, https://update.dsesecurity.com/updates/hybrid-network-access-vpn-least-privilege/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Recognize, report, and contain a suspected phishing message > Treat phishing as a reporting and response workflow—not a quiz. Learn observable warning signs, preserve a safe report, avoid interacting with the message, and escalate immediately if a link, attachment, credential prompt, payment request, or MFA approval was used. - Canonical URL: https://update.dsesecurity.com/updates/recognize-report-contain-phishing/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:03:09+00:00 - Modified: 2026-07-19T19:03:09+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity - Reading time: 3 minutes ## What you need to know Treat phishing as a reporting and response workflow—not a quiz. Learn observable warning signs, preserve a safe report, avoid interacting with the message, and escalate immediately if a link, attachment, credential prompt, payment request, or MFA approval was used. ## Potentially affected Email, text, messaging, and phone users; managers; finance teams; and support personnel receiving suspicious communications. ## DSE recommendation Use the organization’s approved reporting method without clicking or forwarding active content, and call the support path immediately after any interaction. ## Article Phishing can arrive by email, text, collaboration app, social message, QR code, or phone call. The goal may be credential theft, malware delivery, fraudulent payment, sensitive-data collection, or an MFA approval. Staff do not need to prove that a message is malicious before reporting it. ## What the official source says Source fact: CISA’s action guide describes phishing as a tactic that can use email, text, social messages, or phone calls to persuade people to open harmful links or attachments, disclose information, or infect devices. CISA advises suspected targets not to click links or attachments and to report the message. ## Pause and inspect without interacting Warning signs can include unexpected urgency, emotional pressure, unusual payment or secrecy requests, a sender address that does not match the claimed organization, unexpected attachments, shortened links, unfamiliar sign-in pages, and an MFA prompt the user did not initiate. A polished logo, familiar writing style, prior conversation content, or a known sender name does not prove legitimacy; accounts and conversation threads can be compromised. DSE recommendation: do not click, scan a QR code, open an attachment, reply, call a number in the message, approve an MFA prompt, or use the message’s unsubscribe link. Verify unusual requests using a known contact method obtained independently, such as an existing directory entry or previously confirmed number. ## Report safely - Use the organization’s approved phishing-report button or support workflow. - If the method is unclear, contact the helpdesk through a known DSE or company address—not through the suspicious message. - Include the time received, delivery channel, claimed sender, and whether anyone interacted. - Avoid broadly forwarding live suspicious content. Follow support instructions for preserving headers or attachments. ## If someone interacted DSE recommendation: report immediately and state exactly what occurred: link opened, file opened, credentials entered, MFA prompt approved, information sent, payment initiated, software installed, or device behavior changed. Do not hide the interaction and do not wait for obvious symptoms. Stop additional work involving the suspicious content. Keep the device powered on unless the organization’s responder directs otherwise; however, if destructive activity is visibly spreading and support cannot be reached, follow the organization’s approved isolation procedure. Use another known-safe device or phone to contact support. Finance-related requests also require the organization’s established payment-fraud and bank-contact procedure. ## What not to conclude A warning sign does not prove malicious intent, and the absence of warning signs does not prove safety. Automated filtering also cannot guarantee that every harmful message is blocked. The responder should evaluate the message in the context of account activity, endpoint signals, mail-system data, and the organization’s procedures. Practical next step: make sure every employee can find the reporting method without opening a suspicious message. Test the route with a harmless simulation and correct any confusion about whom to call after an interaction. ## Primary reference - Name: CISA Personal Security Considerations: Action Guide for Critical Infrastructure Workers - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/sites/default/files/2024-06/personal-security-considerations-action-guide-critical-infrastructure-workers_06-07-2024_508.pdf - Source publication date: 2024-06-07 ## Citation and use Preferred citation: “Recognize, report, and contain a suspected phishing message,” DSE Security, https://update.dsesecurity.com/updates/recognize-report-contain-phishing/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Reconcile flammable-liquid storage rooms, cabinets, and transfer points > Use 29 CFR 1910.106 - Flammable liquids to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/reconcile-flammable-liquid-storage-rooms-cabinets-and-transfer-points/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:30+00:00 - Modified: 2026-08-27T13:04:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Access Control, Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 29 CFR 1910.106 - Flammable liquids to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 29 CFR 1910.106 - Flammable liquids ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Reconcile flammable-liquid storage rooms, cabinets, and transfer points. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [29 CFR 1910.106 – Flammable liquids](https://www.ecfr.gov/current/title-29/section-1910.106) from Occupational Safety and Health Administration via eCFR supports the following bounded statements: - Under 29 CFR 1910, equipment used to transfer Category 1 or 2 liquids, or Category 3 liquids flashing below 100 degrees F, between storage tanks and a loading rack may not also transfer Category 3 liquids flashing at or above 100 degrees F or Category 4 liquids. The research record locates this support at 29 CFR 1910.106(f)(3)(ii) (eCFR anchor p-1910.106(f)(3)(ii)). - Under 29 CFR 1910, the rule requires that the storage of flammable liquids in containers or portable tanks comply with subdivisions (iii) through (v) of this subparagraph. The research record locates this support at 29 CFR 1910.106(d)(5)(ii) (eCFR anchor p-1910.106(d)(5)(ii)). Keep the evidence boundary at these traced claims. They support a review of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Federal workplace rule; liquid category, quantity, process, occupancy, fire code, and incorporated standards determine the applicable controls. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 29 CFR 1910.106(f)(3)(ii) (eCFR anchor p-1910.106(f)(3)(ii)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 29 CFR 1910.106(d)(5)(ii) (eCFR anchor p-1910.106(d)(5)(ii)), which observable configuration, record, or test can confirm applicability here? - Which deployed instance of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of critical rooms, power, cooling, water, fire protection, alternate sites, physical barriers, and documented recovery paths, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate identity and access control, Windows DNS where networked services use it, time, communications, utilities, life-safety systems, vendors, and authorized responders before and after the test, and store only sanitized operational evidence. ## Verification and evidence Tie each conclusion back to 29 CFR 1910.106(f)(3)(ii) (eCFR anchor p-1910.106(f)(3)(ii)); 29 CFR 1910.106(d)(5)(ii) (eCFR anchor p-1910.106(d)(5)(ii)) and to observable material such as facility inventories, inspection records, alarm and shutdown tests, maintenance history, recovery exercises, and corrective actions. Preserve provenance and stable identifiers without copying secrets into the evidence set. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [29 CFR 1910.106 – Flammable liquids](https://www.ecfr.gov/current/title-29/section-1910.106) — Occupational Safety and Health Administration via eCFR ## Primary reference - Name: 29 CFR 1910.106 - Flammable liquids - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-29/section-1910.106 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Reconcile flammable-liquid storage rooms, cabinets, and transfer points,” DSE Security, https://update.dsesecurity.com/updates/reconcile-flammable-liquid-storage-rooms-cabinets-and-transfer-points/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Reconcile PSA, RMM, identity, and billing inventories before managed-service scope drifts > PSA, RMM, identity, security, backup, and billing systems answer different questions. Reconcile them so unmanaged assets, stale agents, unknown identities, licensing gaps, and contract mismatches become owned work. - Canonical URL: https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:22:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know PSA, RMM, identity, security, backup, and billing systems answer different questions. Reconcile them so unmanaged assets, stale agents, unknown identities, licensing gaps, and contract mismatches become owned work. ## Potentially affected PSA configuration items; RMM agents; identity directories; endpoint security; backup; monitoring; network inventories; cloud subscriptions; contracts; invoices; customer ownership; and service reporting. ## DSE recommendation Define authoritative fields, create stable asset and customer keys, compare operational systems on a schedule, route mismatches to owners, confirm lifecycle state with customers, and preserve reconciliation evidence. ## Article ## Source facts: knowing assets and services is a continuing governance outcome NIST’s [Cybersecurity Framework 2.0 Implementation Examples](https://www.nist.gov/document/csf-20-implementations-pdf) provides example actions for CSF outcomes rather than prescribing one platform. For Asset Management, the examples include maintaining inventories of hardware, software, systems, and services; identifying owners; using discovery and inventory tools; and updating records as the environment changes. The CSF also connects asset knowledge with risk, protection, monitoring, response, and recovery. CISA’s Cross-Sector Cybersecurity Performance Goals similarly recommend maintaining regularly updated inventories of assets with IP addresses where relevant, hostnames, owners, and other information needed to identify unauthorized or unmanaged systems. CISA’s MSP advisory calls for providers and customers to understand responsibilities, secure remote-management tools, restrict access, and monitor provider activity. These sources do not declare that PSA, RMM, billing, or identity data is universally authoritative. Each system observes a different part of service delivery. An RMM agent can prove that software recently checked in, but not that the device is contractually covered. An invoice can show that a service is billed, but not that protection is deployed. A directory can contain a legitimate dormant account or a stale one. Reconciliation is the controlled process of resolving those differences. ## DSE recommendation: operate an inventory reconciliation queue Do not promise a magical single source of truth. Define which system is authoritative for each field, join the records with stable identifiers, and make every unresolved mismatch visible to an owner. - Define the questions. Decide what the inventory must prove: customer ownership, physical or cloud location, lifecycle state, support tier, contract inclusion, responsible party, identity owner, security coverage, backup coverage, network reachability, and retirement approval. - Name field authorities. The contract may own service entitlement, finance may own invoice status, the customer may own business disposition, identity may own account state, and technical platforms may own last-seen evidence. Record precedence and the process for disputing incorrect source data. - Create stable keys. Prefer immutable customer, tenant, subscription, device, user, and contract identifiers over names. Preserve serial number, cloud resource ID, directory object ID, agent ID, and source-system record ID. Maintain approved aliases after mergers, replacements, and renames. - Compare the critical sets. Identify devices billed but not managed, agents active without a contract item, protected endpoints missing RMM, users licensed but not employed, backups configured without successful recovery evidence, customer networks absent from documentation, and retired assets still reporting. - Route rather than hide conflicts. Give each mismatch a severity, customer, owner, due date, evidence, and allowed resolution. Do not automatically delete an agent, add billing, or grant a license solely because another system contains a record. Those actions can affect service, cost, or access. - Confirm with the customer. Review unresolved ownership, shadow services, exceptions, newly discovered assets, and retirement candidates with authorized customer contacts. Record the decision and effective date, especially when an asset remains reachable but is removed from managed scope. - Measure coverage and ageing. Report reconciliation date, record counts, match rate, unknown owners, stale check-ins, unprotected assets, contract gaps, aged exceptions, and time to resolution. Preserve snapshots so trends and audit questions can be answered. Factual boundary: NIST and CISA describe asset-management outcomes; they do not endorse a specific MSP data model or make billing data a security authority. Discovery tools can miss offline assets, duplicate virtual systems, or observe devices outside contractual scope. Customer validation and change control remain necessary. The best reconciliation program does more than improve reporting. It reveals where responsibility is ambiguous before an incident, renewal, or recovery attempt exposes the gap. Success means the provider and customer can explain which assets and identities are managed, what controls are expected, which record supports that claim, and who owns every exception. ## Official references - NIST, [Cybersecurity Framework 2.0 Implementation Examples](https://www.nist.gov/document/csf-20-implementations-pdf). - CISA, [Cross-Sector Cybersecurity Performance Goals](https://www.cisa.gov/cybersecurity-performance-goals). - CISA, [Protecting Against Cyber Threats to Managed Service Providers and their Customers](https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-131a). ## Primary reference - Name: NIST Cybersecurity Framework 2.0 Implementation Examples - Authority: National Institute of Standards and Technology - URL: https://www.nist.gov/document/csf-20-implementations-pdf - Source publication date: 2024-02-26 ## Citation and use Preferred citation: “Reconcile PSA, RMM, identity, and billing inventories before managed-service scope drifts,” DSE Security, https://update.dsesecurity.com/updates/reconcile-psa-rmm-identity-billing-inventories/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Reconcile volume letters when moving disks between Windows computers > What must be checked about volume health and drive letters during a disk move? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-098-reconcile-volume-letters-when-moving-disks-between-windows-computers/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:15:33+00:00 - Modified: 2026-09-08T18:20:23+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What must be checked about volume health and drive letters during a disk move? ## Potentially affected Administrators relocating existing Windows disks to another computer. ## DSE recommendation Prepare a before-and-after mapping by disk identity, volume, and access path. ## Article ## Source facts Microsoft directs administrators to verify Healthy volume status before moving disks and to repair unhealthy volumes first. Basic volumes receive the next available drive letter on the destination computer. Dynamic volumes normally keep their former letter, but a collision causes another available letter to be assigned. A dynamic volume without a letter remains without one. The destination procedure includes rescanning disks and importing a disk reported as Foreign. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/storage/disk-management/move-disks-to-another-computer). ## Applicability Identify every disk and volume involved, its disk type, current letter, destination interfaces, and application dependencies. Review the full movement procedure for the equipment and operating systems in scope. ## DSE recommendation Prepare a before-and-after mapping by disk identity, volume, and access path. Ask application owners to identify references that rely on a specific letter. Arrange the maintenance window, verified recovery material, and physical handling responsibilities before removing or attaching any disk. ## Verification Compare the destination inventory with the original mapping before allowing applications to write. Check volume health, assigned letters, file access, and the application’s configured paths. Preserve any Foreign status or unexpected letter as an explicit finding, and obtain owner acceptance before retiring the original computer. ## Official references [Microsoft Learn: Move disks to another computer](https://learn.microsoft.com/en-us/windows-server/storage/disk-management/move-disks-to-another-computer). Source reviewed September 8, 2026. ## Primary reference - Name: Move disks to another computer - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/storage/disk-management/move-disks-to-another-computer - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Reconcile volume letters when moving disks between Windows computers,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-098-reconcile-volume-letters-when-moving-disks-between-windows-computers/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Reconstruct identity alerts from chronology and entity relationships > Use Investigate alerts in Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/reconstruct-identity-alerts-from-chronology-and-entity-relationships/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:55+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Investigate alerts in Microsoft Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Investigate alerts in Microsoft Defender for Identity ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Reconstruct identity alerts from chronology and entity relationships. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Investigate alerts in Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/investigate-security-alerts) from Microsoft supports the following bounded statements: - The alert story presents a chronological view of what happened, when it happened, and which entities appeared before and after the triggering event. The research record locates this support at Alert story section. - The alert graph maps users, devices, and domain controllers and shows their interactions for relationship and pattern analysis. The research record locates this support at Alert graph section. Keep the evidence boundary at these traced claims. They support a review of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish Story and graph views organize available evidence; they do not prove causation, completeness, or final incident classification. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Alert story section, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Alert graph section, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of identity detections, contributing events, entities, alert logic, tuning, exclusions, investigation, and response decisions, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include Active Directory, Windows DNS, sensor health, time, network visibility, cloud analytics, endpoint evidence, and security operations, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Tie each conclusion back to Alert story section; Alert graph section and to observable material such as sanitized alerts, source events, entity timelines, tuning conditions, exclusion scope, analyst findings, and response outcomes. Preserve provenance and stable identifiers without copying secrets into the evidence set. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Investigate alerts in Microsoft Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/investigate-security-alerts) — Microsoft ## Primary reference - Name: Investigate alerts in Microsoft Defender for Identity - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/investigate-security-alerts - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Reconstruct identity alerts from chronology and entity relationships,” DSE Security, https://update.dsesecurity.com/updates/reconstruct-identity-alerts-from-chronology-and-entity-relationships/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Record authentication evaluations at the receiving trust boundary > Use RFC 8601 — Message Header Field for Indicating Message Authentication Status to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/record-authentication-evaluations-at-the-receiving-trust-boundary/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:16:53+00:00 - Modified: 2026-08-27T12:36:16+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 8601 — Message Header Field for Indicating Message Authentication Status to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 8601 — Message Header Field for Indicating Message Authentication Status ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Record authentication evaluations at the receiving trust boundary. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 8601 — Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - Authentication-Results assertions are trustworthy only when producer and consumer are connected through the receiving administrative domain’s configured trust boundary. The research record locates this support at Section 1.2 (Trust Boundary). - The authentication service identifier is unique within its administrative domain and lets downstream consumers decide whether to use or ignore the recorded result. The research record locates this support at Section 2.5 (Authentication Service Identifier Field). - At ingress, an MTA removes a forged Authentication-Results field that claims an internal identifier but did not arrive directly from a trusted MTA. The research record locates this support at Section 5 (Removing Existing Header Fields). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling and the conditions the source actually describes. ## What the source does not establish This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Section 1.2 (Trust Boundary), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 2.5 (Authentication Service Identifier Field), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 5 (Removing Existing Header Fields), which observable configuration, record, or test can confirm applicability here? - Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population? - Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Tie each conclusion back to Section 1.2 (Trust Boundary); Section 2.5 (Authentication Service Identifier Field); Section 5 (Removing Existing Header Fields) and to observable material such as sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs. Preserve provenance and stable identifiers without copying secrets into the evidence set. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 8601 — Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 8601 — Message Header Field for Indicating Message Authentication Status - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc8601.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Record authentication evaluations at the receiving trust boundary,” DSE Security, https://update.dsesecurity.com/updates/record-authentication-evaluations-at-the-receiving-trust-boundary/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Record Azure Bastion sessions only with a governed evidence lifecycle > Azure Bastion Premium can record graphical RDP and SSH sessions to Blob storage, but it records all sessions through an enabled host and has storage, identity, client, and immutability constraints. - Canonical URL: https://update.dsesecurity.com/updates/azure-bastion-session-recording-evidence-lifecycle/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:55+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT - Reading time: 3 minutes ## What you need to know Azure Bastion Premium can record graphical RDP and SSH sessions to Blob storage, but it records all sessions through an enabled host and has storage, identity, client, and immutability constraints. ## Potentially affected Organizations considering Azure Bastion session recording for privileged graphical access to Azure virtual machines. ## DSE recommendation Define purpose and notice, isolate the recording container, use managed identity where supported, restrict readers, set retention, and test recording retrieval and outage behavior. ## Article Bottom line: Azure Bastion session recording can capture graphical RDP and SSH sessions and store recordings in an Azure Blob container. Microsoft documents that enabling recording on a Bastion host records all sessions through that host. The recording is sensitive administrative evidence and needs a defined purpose, notice, access model, retention, and incident process before enablement. ## Source fact: what Microsoft documents Microsoft’s [Bastion session-recording guide](https://learn.microsoft.com/en-us/azure/bastion/session-recording) says the feature requires the Premium SKU and records graphical sessions made through the recording-enabled bastion host. After a session closes or disconnects, the recording is stored in a configured Blob container and can be viewed from the Azure portal. The page lists operational constraints. Session recording is not available through the native client, cannot currently be used concurrently with the documented Entra ID portal RDP scenario, supports one storage account and container at a time, and records all sessions when enabled. The storage container must not have blob versioning or immutable storage policies according to the source. Microsoft labels managed-identity storage authentication as the recommended Preview path and also documents SAS URL configuration; the page specifies the storage roles required for writing and viewing. ## What the source does not establish A recording does not capture activity outside the graphical session, prove the operator’s intent, prevent misuse, or replace command, guest, Azure Activity, and application logs. It does not guarantee a recording is complete if storage, identity, Bastion, browser, or session connectivity fails. Because the documented storage design excludes immutability and versioning for the recording container, separate controls are needed for protected preservation when evidence must be retained. ## Applicability questions - What security, support, legal, or quality purpose justifies recording, and what notice or consent is required? - Which Bastion hosts, VMs, RDP and SSH sessions, native clients, and Entra sign-in modes are in scope? - Who can write, list, view, copy, delete, or administer the storage container? - What retention and deletion schedule applies, and how is a relevant recording placed under incident hold? - What happens if storage access, managed identity, SAS, or the container fails during a privileged session? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Obtain security, privacy, HR, legal, and operations approval for purpose, scope, notice, access, retention, and use. - Use a dedicated recording container and managed identity where supported. Restrict storage contributor, reader, and administrator roles separately. - Enable on a pilot Bastion host and test RDP, SSH, disconnect, storage interruption, container change, playback, export, deletion, and incident preservation. - Alert on recording configuration changes, storage failures, identity changes, and unauthorized reads or deletes. - Pair recordings with sign-in, Bastion, VM, command, and application logs; document known blind spots. ## Verification and evidence - Preserve Bastion SKU and configuration, container URI, identity, role assignments, retention standard, notice, and approval. - Record test session start and end, object creation, playback, authorized access, and denied access. - Demonstrate an incident-preservation process that does not violate the feature’s current storage constraints. - Reconcile privileged session records with expected recordings and investigate gaps. ## Official references - [Configure Bastion session recording](https://learn.microsoft.com/en-us/azure/bastion/session-recording) — Microsoft ## Primary reference - Name: Configure Bastion session recording - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/azure/bastion/session-recording - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Record Azure Bastion sessions only with a governed evidence lifecycle,” DSE Security, https://update.dsesecurity.com/updates/azure-bastion-session-recording-evidence-lifecycle/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Record Conditional Access session-lifetime exceptions as explicit risk decisions > Conditional Access session controls influence reauthentication, browser persistence, app restrictions, resilience, and token protection; shorter sign-in frequency is not a universal session-revocation control. - Canonical URL: https://update.dsesecurity.com/updates/entra-conditional-access-session-lifetime-exceptions/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:35:14+00:00 - Modified: 2026-08-25T21:43:55+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Conditional Access session controls influence reauthentication, browser persistence, app restrictions, resilience, and token protection; shorter sign-in frequency is not a universal session-revocation control. ## Potentially affected Microsoft Entra tenants configuring sign-in frequency, persistent browser sessions, application-enforced restrictions, or other Conditional Access session controls. ## DSE recommendation Set session controls by resource and user risk, test client behavior and continuity, and give every deviation from the approved baseline an owner and review date. ## Article Bottom line: Conditional Access session controls are a family of controls, not one universal timeout. Microsoft documents sign-in frequency, persistent browser sessions, application-enforced restrictions, app control, Continuous Access Evaluation customization, resilience defaults, token protection, and network security-profile integration. Select and test the control that matches the actual risk. ## Source fact: what Microsoft documents Microsoft’s [Conditional Access session documentation](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-session) describes session controls that affect supported cloud applications after the grant decision. Sign-in frequency determines when a user must reauthenticate to access a resource; persistent browser session settings influence whether browser authentication persists after closure and reopening. Microsoft also documents application-enforced restrictions, which pass device information to supported cloud applications so they can provide limited experiences, and Conditional Access App Control through supported proxy-based enforcement. Separate controls customize CAE behavior, resilience defaults during an outage, token protection, and Global Secure Access security profiles. The exact availability, resource support, license, and client behavior differ among controls. ## What the source does not establish A short sign-in frequency does not guarantee immediate revocation, erase application caches, or close every active session. A persistent browser setting does not control every native client. Application-enforced restrictions depend on resource support, and app control depends on additional service configuration. Disabling resilience defaults may trade continued access during an identity outage for stricter denial; the correct choice is an availability and risk decision, not a universal best practice. ## Applicability questions - Which resource and user population needs a session control, and what event should end or limit access? - Is access through browser, native Office client, mobile app, virtual desktop, unmanaged device, or automation? - What reauthentication burden is acceptable for frontline, privileged, emergency, and accessibility scenarios? - Which applications support the selected control and what limited experience do they provide? - What should happen during an Entra outage or when a user cannot reauthenticate? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. - Define the risk scenario first: stolen device, unmanaged download, long-lived browser, privileged action, token replay, or identity-service outage. - Choose the narrowest documented session control that addresses that scenario. Avoid layering settings without understanding precedence and client behavior. - Pilot with representative resources, devices, browsers, native clients, user roles, and network states. Include outage and recovery procedures where feasible. - Record every exclusion or longer session as a risk exception with owner, rationale, compensating controls, and review date. - Monitor sign-in prompts, failures, helpdesk impact, unexpected persistent access, and application-specific limited-mode behavior. ## Verification and evidence - Preserve Conditional Access policy configuration, mode, scope, exclusions, session controls, and approval. - Capture sign-in logs and timed client tests showing reauthentication and persistence behavior. - Test both intended restrictions and continued business function on supported applications. - Recheck exception populations and resource support after client or service changes. ## Official references - [Conditional Access: Session](https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-session) — Microsoft ## Primary reference - Name: Conditional Access: Session - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-session - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Record Conditional Access session-lifetime exceptions as explicit risk decisions,” DSE Security, https://update.dsesecurity.com/updates/entra-conditional-access-session-lifetime-exceptions/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Record covered accidental releases and their onsite and offsite consequences > Use 40 CFR 68.42 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/record-covered-accidental-releases-and-their-onsite-and-offsite-consequences/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:10:11+00:00 - Modified: 2026-08-27T13:12:22+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, Cybersecurity - Reading time: 3 minutes ## What you need to know Use 40 CFR 68.42 -- Chemical Accident Prevention Provisions to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of 40 CFR 68.42 -- Chemical Accident Prevention Provisions ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Record covered accidental releases and their onsite and offsite consequences. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [40 CFR 68.42 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.42) from Environmental Protection Agency via eCFR supports the following bounded statements: - Under 40 CFR 68, the rule requires that the owner or operator include in the five-year accident history all accidental releases from covered processes that resulted in deaths, injuries, or significant property damage on site, or known offsite deaths, injuries, evacuations, sheltering in place, property damage, or environmental damage. The research record locates this support at 40 CFR 68.42(a) (eCFR anchor p-68.42(a)). - Under 40 CFR 68, the rule requires that for each accidental release included, the owner or operator report the following information: known offsite impacts. The research record locates this support at 40 CFR 68.42(b)(8), read with 40 CFR 68.42(b) (eCFR anchor p-68.42(b)(8)). Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives and the conditions the source actually describes. ## What the source does not establish Applies only to stationary sources and processes subject to 40 CFR part 68 and the applicable program level. Confirm coverage, regulated substances, process conditions, and current EPA requirements; this is not legal advice or a universal emergency-management standard. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at 40 CFR 68.42(a) (eCFR anchor p-68.42(a)), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at 40 CFR 68.42(b)(8), read with 40 CFR 68.42(b) (eCFR anchor p-68.42(b)(8)), which observable configuration, record, or test can confirm applicability here? - Which owner can attest to the recorded state of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, including exceptions? - What baseline for identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery must accompany the source-specific observation? - Which success, stop, and escalation criteria are written before testing begins? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of essential functions, upstream providers, recovery sequences, alternate work paths, and tested recovery objectives, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include identity, DNS, communications, facilities, suppliers, and the people authorized to invoke recovery, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence Keep the source locations 40 CFR 68.42(a) (eCFR anchor p-68.42(a)); 40 CFR 68.42(b)(8), read with 40 CFR 68.42(b) (eCFR anchor p-68.42(b)(8)) adjacent to the sanitized artifacts used for comparison. Prefer business-impact records, dependency maps, exercise results, recovery timings, and open corrective actions, with enough identity and timing data for an independent recheck. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [40 CFR 68.42 — Chemical Accident Prevention Provisions](https://www.ecfr.gov/current/title-40/section-68.42) — Environmental Protection Agency via eCFR ## Primary reference - Name: 40 CFR 68.42 -- Chemical Accident Prevention Provisions - Authority: www.ecfr.gov - URL: https://www.ecfr.gov/current/title-40/section-68.42 - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Record covered accidental releases and their onsite and offsite consequences,” DSE Security, https://update.dsesecurity.com/updates/record-covered-accidental-releases-and-their-onsite-and-offsite-consequences/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Record panoramic video investigators can dewarp later > Panoramic cameras can deliver different views and dewarping options. Confirm that the archive preserves the view investigators need, not only a convenient live layout. - Canonical URL: https://update.dsesecurity.com/updates/record-panoramic-video-investigators-can-dewarp-later/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:36:08+00:00 - Modified: 2026-08-25T21:36:16+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Advisory - Topics: Video Surveillance - Reading time: 3 minutes ## What you need to know Panoramic cameras can deliver different views and dewarping options. Confirm that the archive preserves the view investigators need, not only a convenient live layout. ## Potentially affected Organizations using fisheye, multisensor, or multidirectional panoramic cameras for broad coverage and post-event investigation. ## DSE recommendation Choose the recorded projection deliberately and prove that authorized investigators can navigate, dewarp, export, and explain the resulting evidence. ## Article Bottom line: a panoramic camera’s live display does not necessarily reveal what is stored. If an investigator will need to look in a different direction after an event, the recorded stream must preserve the projection and detail required for that post-event navigation. ## Source fact: panoramic designs and recorded views differ The Axis paper [Panoramic cameras](https://whitepapers.axis.com/en-us/panoramic-cameras) distinguishes fisheye cameras from multisensor and multidirectional designs. It explains that a fisheye circular view can be dewarped and that, when the circular view is recorded, a compatible VMS can allow digital pan, tilt, and zoom during review. It also frames selection around purpose, scene, and required detail. That does not mean every displayed tile is independently recorded or every exported player can reproduce server-side dewarping. A wall display may show several corrected views while the archive stores one source stream, or the system may record only selected views and lose the ability to look elsewhere later. ## Source boundary and applicability The paper is a vendor overview, not proof of compatibility with a chosen VMS or evidence player. Available projections, resolution allocation, mounting modes, dewarping locations, metadata, and export behavior vary by model and software. The source also does not establish that one panoramic camera supplies the same evidentiary detail as several targeted cameras. ## Applicability questions - Is the requirement situational awareness, identification at a point, or retrospective search anywhere in the scene? - Is a circular source view, dewarped view, or multiple sensor streams actually archived? - Where does dewarping occur: camera, VMS server, client, or export player? - Can another authorized workstation reproduce the investigator’s view? - How are pixel density, seams, blind areas, and lighting verified across the full panorama? ## DSE recommendation: accept the archive and export workflow The following steps are DSE recommendations based on the cited source. Document the chosen camera type, mounting mode, recorded projection, stream resolution, dewarping component, and required investigative task. Walk targets through the full coverage area at relevant distances. After recording, ask a tester who did not watch live video to locate the target, navigate the archived image, create a still and clip, and reproduce the result on a separate authorized workstation. Preserve the native export when evidentiary context depends on the original projection. If a dewarped derivative is shared, record the selected viewpoint and keep a linkage to the source. Confirm licensing, client compatibility, and retention for every stream used. ## Verification and evidence Keep the coverage drawing, camera and mount details, stream configuration, native and dewarped sample exports, player requirements, pixel-density checks, blind-area observations, investigator test results, and hashes for retained evidence samples. Re-test after moving the camera, changing projection, or upgrading camera or VMS software. ## Official references - [Panoramic cameras](https://whitepapers.axis.com/en-us/panoramic-cameras) – Axis Communications ## Primary reference - Name: Panoramic cameras - Authority: Axis Communications - URL: https://whitepapers.axis.com/en-us/panoramic-cameras - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Record panoramic video investigators can dewarp later,” DSE Security, https://update.dsesecurity.com/updates/record-panoramic-video-investigators-can-dewarp-later/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Record the Defender for Identity workspace ID and name for support and proxy changes > Use View information on the Defender for Identity About page to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/record-defender-identity-workspace-id-name-support-proxy-changes/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:47+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use View information on the Defender for Identity About page to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of View information on the Defender for Identity About page ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Record the Defender for Identity workspace ID and name for support and proxy changes. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [View information on the Defender for Identity About page](https://learn.microsoft.com/en-us/defender-for-identity/settings-about) from Microsoft supports the following bounded statements: - The Defender for Identity About page reports the workspace ID and name, latest available sensor version, assigned license count, and identities active during the preceding 28 days. The research record locates this support at Information shown on the Defender for Identity About page > details list. - Microsoft directs administrators to use the About-page identifiers for troubleshooting or support and to supply the workspace name when setting proxy or firewall connectivity. The research record locates this support at Information shown on the Defender for Identity About page > paragraph following the details list. The source support ends with the statements listed above. Use them to examine Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Workspace identifiers support inventory and escalation; they do not prove sensor connectivity, health, license entitlement, data ingestion, or support-case resolution. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Information shown on the Defender for Identity About page > details list, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Information shown on the Defender for Identity About page > paragraph following the details list, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Information shown on the Defender for Identity About page > details list; Information shown on the Defender for Identity About page > paragraph following the details list. Favor sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests, linked to stable identifiers, time, and operator. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [View information on the Defender for Identity About page](https://learn.microsoft.com/en-us/defender-for-identity/settings-about) — Microsoft ## Primary reference - Name: View information on the Defender for Identity About page - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/settings-about - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Record the Defender for Identity workspace ID and name for support and proxy changes,” DSE Security, https://update.dsesecurity.com/updates/record-defender-identity-workspace-id-name-support-proxy-changes/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Recover Active Directory as an identity service, not just a server > Forest recovery is a controlled rebuild of the organization’s identity service. It requires trusted backups, an isolated recovery sequence, privileged credential resets, dependency validation, and rehearsed business acceptance—not simply a restored domain controller. - Canonical URL: https://update.dsesecurity.com/updates/recover-active-directory-as-an-identity-service-not-just-a-server/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-04T22:53:02+00:00 - Modified: 2026-08-04T22:53:02+00:00 - Last reviewed by DSE: 2026-08-04 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 4 minutes ## What you need to know Forest recovery is a controlled rebuild of the organization’s identity service. It requires trusted backups, an isolated recovery sequence, privileged credential resets, dependency validation, and rehearsed business acceptance—not simply a restored domain controller. ## Potentially affected Organizations that depend on on-premises Active Directory Domain Services for authentication, authorization, DNS-integrated directory functions, Group Policy, trusts, service identities, or hybrid identity. ## DSE recommendation Create and rehearse a forest-specific recovery plan that identifies a trusted backup and restore DC for every domain, protects recovery credentials, maps identity-dependent services, and defines technical and business acceptance gates. ## Article ## Source fact: forest recovery restores an earlier identity state Microsoft’s [Active Directory forest recovery guide](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-guide) addresses a forest-wide failure in which all domain controllers can no longer function normally. Full forest recovery means restoring at least one domain controller in every domain from available backup. Each domain returns to the state of the last trusted backup; objects created later, later updates, and later configuration or schema changes are lost. This is not ordinary server replacement. It is a deliberate rollback of the directory that supplies identities and policy to other systems. ## Source fact: Microsoft places diagnosis before restoration Microsoft’s [recommended recovery path](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-steps-for-restoring-the-forest) begins by identifying the problem with IT, Microsoft Support, and business stakeholders; total forest recovery is often the last option. The high-level sequence is to determine the recovery method, perform initial recovery in isolation, redeploy the remaining domain controllers, and then complete cleanup and application restoration. Isolation matters because the procedure is designed to reduce the chance of bringing dangerous data back into the recovered forest. The [initial recovery guidance](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-perform-initial-recovery) starts with one writable domain controller in the forest-root domain, then repeats for the other domains. A parent domain is recovered before its child. The first writable controller for each domain comes from a trusted, tested backup and is restored while isolated from production. When malicious compromise is suspected, Microsoft directs administrators to reset privileged-account passwords and complete the krbtgt reset procedure before adding more domain controllers. ## DSE recommendation: define the identity service you must recover DSE recommends treating “Active Directory available” as a set of measurable service outcomes, not a green server icon. Before an incident, list the applications, sites, network devices, administrative tools, and hybrid services that depend on domain authentication, LDAP, Kerberos, directory-integrated DNS, Group Policy, trusts, groups, or service identities. Assign a technical owner and a business validator to every critical dependency. This is a DSE operational inference: restoring directory data is necessary, but Microsoft’s cleanup phase also calls for restoring name resolution and line-of-business applications. Write acceptance checks for administrator sign-in, representative user sign-in, DNS location of domain services, replication among newly deployed controllers, expected group-based authorization, trust paths, service startup, and hybrid synchronization. Identify which checks are safe in isolation and which require controlled reconnection. Record what evidence proves each gate passed. ## Source fact: the recovery kit must exist beforehand Microsoft says the plan should include a detailed forest topology map with domain-controller names, roles, backup status, and trust relationships. Its [backup-selection guidance](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-determine-how-to-recover) requires access to a Domain Admin credential for each domain and the Directory Services Restore Mode password. The selected backup must represent a known-safe point. Microsoft recommends maintaining daily health records to help determine when failure began and practicing the customized recovery plan at least annually. ## DSE recommendation: operate a gated forest-recovery playbook - Declare. Establish who may authorize forest recovery, what evidence shows lesser remedies are inadequate, and how Microsoft Support and business leadership are engaged. - Contain. Prepare a recovery network, trusted tools, clean administrative workstations, offline plan copies, current topology, recovery credentials, and a communications path that does not depend on Active Directory. - Select. Correlate health history and incident evidence to choose the last trusted backup for every domain. Record the expected directory rollback and the business changes that will need reconciliation. - Recover. Follow the Microsoft sequence exactly for the deployed Windows Server versions: forest root first, parent before child, one isolated writable controller per domain, security remediation, controlled reconnection, and redeployment of remaining controllers. - Validate. Run the documented identity and dependent-service checks. Reconcile users, computers, groups, permissions, schema, and configuration changes made after the trusted backup through approved change processes; do not blindly replay possibly malicious changes. - Learn. Preserve timestamps and evidence, update the topology and runbook, remediate drill failures, and schedule the next exercise. DSE recommends measuring recovery from the decision to invoke the plan through validated business authentication—not merely until the first domain controller boots. That makes identity-service recovery visible, testable, and accountable without confusing it with generic backup restoration. ## Official sources - [Microsoft: Active Directory forest recovery guide](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-guide) - [Microsoft: Steps to restore the forest](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-steps-for-restoring-the-forest) - [Microsoft: Determine how to recover the forest](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-determine-how-to-recover) - [Microsoft: Perform the initial recovery](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-perform-initial-recovery) - [Microsoft: Devise an AD forest recovery plan](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-devise-a-plan) ## Primary reference - Name: Microsoft Active Directory forest recovery guide - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-guide - Source publication date: 2025-07-11 ## Citation and use Preferred citation: “Recover Active Directory as an identity service, not just a server,” DSE Security, https://update.dsesecurity.com/updates/recover-active-directory-as-an-identity-service-not-just-a-server/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Reduce unnecessary internet exposure before it becomes an incident path > Find public-facing assets, confirm why each exposure exists, remove what is unnecessary, protect what must remain, and repeat the assessment as the environment changes. - Canonical URL: https://update.dsesecurity.com/updates/reduce-unnecessary-internet-exposure/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-07-19T19:04:46+00:00 - Modified: 2026-07-19T19:04:46+00:00 - Last reviewed by DSE: 2026-07-19 - Resource type: Checklist - DSE priority: Advisory - Topics: Access Control, Cybersecurity, Networks & Infrastructure, Video Surveillance - Reading time: 3 minutes ## What you need to know Find public-facing assets, confirm why each exposure exists, remove what is unnecessary, protect what must remain, and repeat the assessment as the environment changes. ## Potentially affected Organizations with public addresses, remote-access services, management interfaces, cloud workloads, appliances, cameras, access systems, or vendor support paths. ## DSE recommendation Create an authorized external-exposure inventory, validate the business need for each entry, and assign remediation and recurring review to named owners. ## Article ## Exposure must be intentional CISA’s Internet Exposure Reduction Guidance recommends identifying internet-accessible assets, deciding whether each exposure is necessary, mitigating the risk of services that must remain reachable, and reassessing routinely. The sequence matters. Teams cannot protect an exposure they do not know exists, and they should not spend years hardening a public interface that has no current business purpose. Internet exposure can include more than websites. Remote administration, virtual private network gateways, file-transfer services, cloud consoles, test systems, management interfaces, and vendor support paths may all be externally reachable. A physical-security device or management server should not be assumed private simply because it is installed inside a facility. ## Build an authorized view of the perimeter Start with records the organization controls: public address ranges, domains, certificates, cloud accounts, firewall and gateway policies, remote-access platforms, vendor connections, and service inventories. Reconcile those records with observations from authorized external scanning or exposure-management services. Do not scan networks you do not own or lack permission to assess. For every discovered service, record an owner, system purpose, location, platform and version, authentication method, data sensitivity, expected users, monitoring source, and business justification. Unknown assets require investigation; they should not be assigned a guessed purpose to make the list look complete. ## Remove or restrict what is not required - Disable obsolete services and close paths left by retired projects or vendors. - Move administrative interfaces behind an approved remote-access or policy-enforcement layer where supported. - Restrict source networks, users, and time periods when the business workflow permits. - Replace default credentials and retire unsupported products through a documented plan. - Coordinate changes with monitoring, cloud, application, and physical-security owners. Removal must still be treated as a production change. Remote monitoring, hosted services, mobile applications, and emergency support may depend on a path that is not obvious from a firewall name. Define tests and recovery steps before changing exposure. ## Protect exposure that remains CISA calls out measures such as current patches, multifactor authentication where possible, monitored access through a jump host, and ingress and egress monitoring. Apply the controls supported by the exact service and its architecture. Also confirm logging, alert ownership, certificate renewal, account review, backups, and an incident response contact. An internet-facing service should have a shorter route from alert to accountable human than an internal low-risk asset. ## Make reassessment routine Public exposure changes when a cloud workload is created, a vendor opens support access, a certificate is issued, or a firewall exception outlives its project. Compare the authorized inventory with current observations on a defined cadence and after material network changes. Track findings to closure, including accepted exceptions with an owner and review date. The goal is not a one-time clean scan; it is a perimeter whose public services are known, justified, supported, and monitored. ## Primary reference - Name: CISA — Internet Exposure Reduction Guidance - Authority: Cybersecurity and Infrastructure Security Agency - URL: https://www.cisa.gov/resources-tools/resources/exposure-reduction - Source publication date: 2025-06-04 ## Citation and use Preferred citation: “Reduce unnecessary internet exposure before it becomes an incident path,” DSE Security, https://update.dsesecurity.com/updates/reduce-unnecessary-internet-exposure/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Reestablish a global catalog after forest-root recovery > Use AD Forest Recovery - Adding the GC to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/reestablish-global-catalog-after-forest-root-recovery/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:27+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use AD Forest Recovery - Adding the GC to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of AD Forest Recovery - Adding the GC ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Reestablish a global catalog after forest-root recovery. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [AD Forest Recovery – Adding the GC](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-add-gc) from Microsoft supports the following bounded statements: - The forest-recovery sequence includes adding the global catalog role to a domain controller. The research record locates this support at Opening overview. - Microsoft documents both the standard add operation and a repadmin-based method. The research record locates this support at Sections: Add the global catalog; Add the global catalog using repadmin. The source support ends with the statements listed above. Use them to examine forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Confirm replication health and role placement before advertising the recovered global catalog. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections: Add the global catalog; Add the global catalog using repadmin, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to Opening overview; Sections: Add the global catalog; Add the global catalog using repadmin and to observable material such as backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings. Preserve provenance and stable identifiers without copying secrets into the evidence set. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [AD Forest Recovery – Adding the GC](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-add-gc) — Microsoft ## Primary reference - Name: AD Forest Recovery - Adding the GC - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-add-gc - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Reestablish a global catalog after forest-root recovery,” DSE Security, https://update.dsesecurity.com/updates/reestablish-global-catalog-after-forest-root-recovery/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Refuse to treat a DNS name as a stable or trustworthy identifier > Use RFC 4367 — What's in a Name: False Assumptions about DNS Names to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/refuse-to-treat-a-dns-name-as-a-stable-or-trustworthy-identifier/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:32+00:00 - Modified: 2026-08-27T12:18:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4367 — What's in a Name: False Assumptions about DNS Names to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4367 — What's in a Name: False Assumptions about DNS Names ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Refuse to treat a DNS name as a stable or trustworthy identifier. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4367 — What’s in a Name: False Assumptions about DNS Names](https://www.rfc-editor.org/rfc/rfc4367.html) from RFC Editor / Internet Architecture Board supports the following bounded statements: - Client and server protocol behavior should not change merely because of the other endpoint’s domain name. The research record locates this support at Section 7 (Recommendations), follow the specifications. - When a protocol offers capability negotiation, endpoints should negotiate supported features instead of inferring them from a domain name. The research record locates this support at Section 7 (Recommendations), use capability negotiation. - Implementations should accept the full range permitted by the protocol rather than narrowing input based on assumptions about a named domain. The research record locates this support at Section 7 (Recommendations), protocol acceptance. Only the traced statements above are asserted as source facts. Apply the review to authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Section 7 (Recommendations), follow the specifications, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 7 (Recommendations), use capability negotiation, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 7 (Recommendations), protocol acceptance, which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from Section 7 (Recommendations), follow the specifications; Section 7 (Recommendations), use capability negotiation; Section 7 (Recommendations), protocol acceptance to the observed environment. Useful domain evidence includes zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [RFC 4367 — What’s in a Name: False Assumptions about DNS Names](https://www.rfc-editor.org/rfc/rfc4367.html) — RFC Editor / Internet Architecture Board ## Primary reference - Name: RFC 4367 — What's in a Name: False Assumptions about DNS Names - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4367.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Refuse to treat a DNS name as a stable or trustworthy identifier,” DSE Security, https://update.dsesecurity.com/updates/refuse-to-treat-a-dns-name-as-a-stable-or-trustworthy-identifier/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Register the RADIUS-speaking access device, not the end-user computer > Which system is the RADIUS client that NPS should be configured to receive requests from? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-194-register-the-radius-speaking-access-device-not-the-end-user-computer/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:13:57+00:00 - Modified: 2026-09-08T18:26:32+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know Which system is the RADIUS client that NPS should be configured to receive requests from? ## Potentially affected Administrators identifying RADIUS clients for Network Policy Server. ## DSE recommendation Create an inventory of the message-sending devices and the NPS servers that should receive from them. ## Article ## Source facts Microsoft defines a network access server using RADIUS as a RADIUS client: it sends connection requests and accounting messages to the server. An NPS configured as a forwarding proxy is also a RADIUS client of the downstream server. Adding a RADIUS client to NPS configures it to receive Access-Request messages from that access server or proxy. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-radius-clients). ## Applicability Trace one connection request from the user’s device through the access infrastructure to NPS. Identify whether a wireless access point, VPN server, switch, or proxy actually sends the RADIUS message. ## DSE recommendation Create an inventory of the message-sending devices and the NPS servers that should receive from them. Have network-access and authentication owners review the source addresses and device identities. Document proxy hops separately and handle any shared authentication material through the approved protected process. ## Verification Generate a controlled connection attempt and correlate the sending device with the NPS request record. Confirm that the configured client represents that device or proxy and test an unapproved sender in an authorized environment. Resolve an identity or address mismatch before accepting the client registration. ## Official references [Microsoft Learn: RADIUS Clients](https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-radius-clients). Source reviewed September 8, 2026. ## Primary reference - Name: RADIUS Clients - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-radius-clients - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Register the RADIUS-speaking access device, not the end-user computer,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-194-register-the-radius-speaking-access-device-not-the-end-user-computer/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Register the Windows Admin Center gateway before enabling Azure integration > What Azure registration object and gateway privilege should be reviewed for Windows Admin Center integration? - Canonical URL: https://update.dsesecurity.com/updates/dse-20260908-167-register-the-windows-admin-center-gateway-before-enabling-azure-integration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-09-08T18:14:24+00:00 - Modified: 2026-09-08T18:26:31+00:00 - Last reviewed by DSE: 2026-09-08 - Resource type: Guide - DSE priority: Information - Topics: IT, Networks & Infrastructure - Reading time: 1 minutes ## What you need to know What Azure registration object and gateway privilege should be reviewed for Windows Admin Center integration? ## Potentially affected Administrators connecting a Windows Admin Center gateway to Azure features. ## DSE recommendation Have the gateway and identity owners agree on the intended tenant and application identity. ## Article ## Source facts Microsoft requires Azure registration of a Windows Admin Center gateway before it can use the documented Azure integrations. The registration is retained when the gateway is updated. Only a gateway administrator can perform the registration. The guided process creates a Microsoft Entra application in the directory, and the gateway’s Azure settings provide a link for inspecting that application in the portal. [Microsoft documentation](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/azure-integration). ## Applicability Identify the gateway, Azure tenant, administrator, intended integration, and existing registration. Review whether the gateway was migrated or previously registered before starting another registration workflow. ## DSE recommendation Have the gateway and identity owners agree on the intended tenant and application identity. Record the registration’s purpose and the owners responsible for maintaining it. Use the approved administrator account and preserve the existing settings before changing the integration configuration. ## Verification Inspect the resulting Entra application and compare its tenant and identifiers with the approved record. Test the intended integration with a representative authorized user and check the gateway’s retained registration after an approved update. Resolve an unexpected application or tenant association before enabling additional Azure features. ## Official references [Microsoft Learn: Configuring Azure Integration](https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/azure-integration). Source reviewed September 8, 2026. ## Primary reference - Name: Configuring Azure Integration - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/azure/azure-integration - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Register the Windows Admin Center gateway before enabling Azure integration,” DSE Security, https://update.dsesecurity.com/updates/dse-20260908-167-register-the-windows-admin-center-gateway-before-enabling-azure-integration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Register-DnsServerDirectoryPartition: register dns server directory partition against recorded identity and DNS state > Use Register-DnsServerDirectoryPartition to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/register-dnsserverdirectorypartition-register-dns-server-directory-partition-against-recorded/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:03:08+00:00 - Modified: 2026-08-27T17:26:01+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Register-DnsServerDirectoryPartition to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Register-DnsServerDirectoryPartition ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Register-DnsServerDirectoryPartition: register dns server directory partition against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Register-DnsServerDirectoryPartition](https://learn.microsoft.com/en-us/powershell/module/dnsserver/register-dnsserverdirectorypartition?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Registers a DNS server in a DNS application directory partition.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Register-DnsServerDirectoryPartition cmdlet registers a Domain Name System (DNS) server in a DNS application directory partition.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence A reviewer should be able to retrace the decision from SYNOPSIS; DESCRIPTION through PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-258 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Register-DnsServerDirectoryPartition](https://learn.microsoft.com/en-us/powershell/module/dnsserver/register-dnsserverdirectorypartition?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Register-DnsServerDirectoryPartition - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/dnsserver/register-dnsserverdirectorypartition?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Register-DnsServerDirectoryPartition: register dns server directory partition against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/register-dnsserverdirectorypartition-register-dns-server-directory-partition-against-recorded/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Rehearse every Hyper-V Replica failover mode before a real outage > Hyper-V Replica provides test, planned, and unplanned failover paths with different prerequisites and consequences. Exercise all three, including network isolation, application validation, reverse replication, failback, and the decision to complete a failover. - Canonical URL: https://update.dsesecurity.com/updates/hyper-v-replica-failover-mode-rehearsal/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-11T10:45:00+00:00 - Modified: 2026-08-11T15:18:11+00:00 - Last reviewed by DSE: 2026-08-11 - Resource type: Playbook - DSE priority: Important - Topics: Business Continuity, IT - Reading time: 3 minutes ## What you need to know Hyper-V Replica provides test, planned, and unplanned failover paths with different prerequisites and consequences. Exercise all three, including network isolation, application validation, reverse replication, failback, and the decision to complete a failover. ## Potentially affected Windows Server Hyper-V primary and replica hosts or clusters; replicated virtual machines; recovery points; virtual networks; DNS, identity, storage, applications, monitoring, backups, orchestration, and disaster-recovery procedures. ## DSE recommendation Classify every replicated VM and dependency, build an isolated test network, run documented test and planned failovers, tabletop the unplanned path, prove reverse replication and failback, and retain workload-level evidence. ## Article ## Source facts: test, planned, and unplanned failover are different operations Microsoft documents [three Hyper-V Replica failover scenarios](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/replication-failover). A test failover creates a separate test virtual machine on the replica host or cluster without interrupting continuing replication. The test VM uses the latest recovery point by default, can use another configured recovery point, and is not connected to a network by default. Stopping the test failover removes that test VM and discards its test data. A planned failover is for a reachable primary VM that can be shut down gracefully. Microsoft’s procedure shuts down the primary, replicates pending changes, starts the failover on the replica side, and reverses replication. Microsoft describes that sequence as zero data loss because pending changes are sent before the switch. It is useful for planned site or datacenter maintenance, but the documentation explicitly says it is not a substitute for high availability. An unplanned failover is for a primary VM that is unavailable. The operator chooses the latest or an available earlier recovery point, starts and validates the replica, and then completes the failover. Data loss is possible depending on the selected recovery point. Completing the failover removes the recovery points and merges the checkpoint, so Microsoft cautions that the operator can no longer revert to an earlier recovery point afterward. After an unplanned event, reverse replication sends changes from the active replica back toward the recovered original host. The primary and replica roles swap, and a later planned failover can return the workload to its original direction. These steps prove why “replicating normally” is only one state in a longer recovery lifecycle. ## DSE recommendation: prove the workload, the decision points, and the return path Give each replicated workload a recovery runbook that names both technical actions and business authority. A virtualization administrator should not have to invent the application validation or decide alone when an irreversible completion step is justified. - Map the recovery unit. Record VM owner, application owner, replication direction and health, recovery points, acceptable data loss and outage, startup order, DNS and IP changes, certificates, identity, storage, licensing, monitoring, backup, external integrations, and recovery-site capacity. - Engineer the test network. Create an isolated network that prevents duplicate addresses, duplicate computer or application identities, outbound transactions, scheduled integrations, email delivery, and production monitoring noise. Provide controlled test clients and representative dependencies. - Exercise test failover. Select the intended recovery point, boot the test copy, verify operating-system and application logs, authenticate through the normal client path, test read and write activity, measure recovery time, and stop the test cleanly. Record any dependency that had to be improvised. - Exercise planned movement. During an approved window, prove graceful shutdown, final replication, activation, user workflow, reversed replication, and the planned return. Confirm which team owns each step and which signal permits progression. - Script the unplanned decisions. Define who declares the primary unavailable, how the recovery point is chosen, what potential data loss is communicated, how the replica network is enabled, and what evidence is required before completing the failover and surrendering earlier recovery points. - Keep independent recovery. Maintain the organization’s approved backups and restoration tests separately. Replication supports availability and disaster recovery, while accidental deletion, corruption, compromise, or an operator error can be copied to the replica. After each exercise, update timings, screenshots or command output, application results, contact details, unresolved findings, and the next review date. Alert on replication warnings, old recovery points, capacity pressure, certificate or network drift, and overdue exercises. The operational objective is a reversible, understood service transition—not a VM that merely exists on a second host. ## Official references - Microsoft Learn, [Fail over a replicated virtual machine with Hyper-V Replica](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/replication-failover), April 28, 2026. - Microsoft Learn, [Hyper-V Replica overview](https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/replication-overview). ## Primary reference - Name: Microsoft Learn: Fail over a replicated virtual machine with Hyper-V Replica - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/replication-failover - Source publication date: 2026-04-28 ## Citation and use Preferred citation: “Rehearse every Hyper-V Replica failover mode before a real outage,” DSE Security, https://update.dsesecurity.com/updates/hyper-v-replica-failover-mode-rehearsal/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Rehearse Windows DNSSEC key-master transfer and offline-role seizure separately > Use Transfer the DNSSEC Key Master Role in Windows DNS Server to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/rehearse-windows-dnssec-key-master-transfer-and-offline-role-seizure-separately/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:26+00:00 - Modified: 2026-08-27T12:56:24+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Transfer the DNSSEC Key Master Role in Windows DNS Server to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Transfer the DNSSEC Key Master Role in Windows DNS Server ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Rehearse Windows DNSSEC key-master transfer and offline-role seizure separately. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Transfer the DNSSEC Key Master Role in Windows DNS Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/transfer-dnssec-key-master) from Microsoft supports the following bounded statements: - Windows DNS Server supports transferring the DNSSEC Key Master role between qualifying authoritative servers. The research record locates this support at Article introduction. - If the current Key Master is offline, Microsoft describes seizing the role as a continuity action; file-backed zones cannot transfer the role. The research record locates this support at Article introduction, prerequisites, and important note. Only the traced statements above are asserted as source facts. Apply the review to Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles after confirming that the source and deployed context match. ## What the source does not establish A role transfer or seizure does not prove that private keys, signatures, validators, and downstream delegations remain correct through the event. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Article introduction, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Article introduction, prerequisites, and important note, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles are in and out of scope? - Which condition in Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Windows DNS servers, AD-integrated zones, policies, forwarders, logging channels, clients, and administrative roles, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, domain-controller health, service accounts, routing, time, certificates, and upstream resolution in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Keep the source locations Article introduction; Article introduction, prerequisites, and important note adjacent to the sanitized artifacts used for comparison. Prefer PowerShell exports, zone and policy inventories, sanitized query tests, event-channel data, replication state, and rollback commands, with enough identity and timing data for an independent recheck. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Transfer the DNSSEC Key Master Role in Windows DNS Server](https://learn.microsoft.com/en-us/windows-server/networking/dns/transfer-dnssec-key-master) — Microsoft ## Primary reference - Name: Transfer the DNSSEC Key Master Role in Windows DNS Server - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/networking/dns/transfer-dnssec-key-master - Source publication date: 2025-08-01 ## Citation and use Preferred citation: “Rehearse Windows DNSSEC key-master transfer and offline-role seizure separately,” DSE Security, https://update.dsesecurity.com/updates/rehearse-windows-dnssec-key-master-transfer-and-offline-role-seizure-separately/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Reinstall DNS on every restored controller that lost the role > Use AD Forest Recovery - Configure DNS Server service to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/reinstall-dns-on-restored-controllers-missing-role/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:14:31+00:00 - Modified: 2026-08-27T12:58:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Business Continuity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use AD Forest Recovery - Configure DNS Server service to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of AD Forest Recovery - Configure DNS Server service ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Reinstall DNS on every restored controller that lost the role. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [AD Forest Recovery – Configure DNS Server service](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-configure-dns) from Microsoft supports the following bounded statements: - A restored domain controller that lacks the DNS Server role must have DNS installed and configured. The research record locates this support at Opening overview. - The step is repeated for each restored controller that is not operating as a DNS server after restore. The research record locates this support at Opening overview. Keep the evidence boundary at these traced claims. They support a review of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This is recovery-specific DNS configuration; validate zones and AD replication before client cutover. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel and the environment’s recorded constraints. ## Applicability questions - For source statement 1 at Opening overview, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Opening overview, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps are in and out of scope? - Which condition in offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of forest recovery plans, trusted backups, isolated recovery networks, controller rebuild order, credential resets, and validation steps, observed and expected states, owner, and reason for deviation. Translate the conclusion into change control only after documenting dependencies, impact, test method, expected signals, failure signals, and restoration steps. Include offline credentials, Windows DNS, time, virtualization, storage, PKI, network isolation, and authorized recovery personnel, while excluding secrets and sensitive personal or topology data from ordinary tickets. ## Verification and evidence A reviewer should be able to retrace the decision from Opening overview; Opening overview through backup manifests, restore logs, isolation proof, recovery timing, role-transfer records, DNS validation, and exercise findings. Record what was collected, where, when, by whom, and which system or role it represents. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [AD Forest Recovery – Configure DNS Server service](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-configure-dns) — Microsoft ## Primary reference - Name: AD Forest Recovery - Configure DNS Server service - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/forest-recovery-guide/ad-forest-recovery-configure-dns - Source publication date: 2025-05-12 ## Citation and use Preferred citation: “Reinstall DNS on every restored controller that lost the role,” DSE Security, https://update.dsesecurity.com/updates/reinstall-dns-on-restored-controllers-missing-role/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Reject ambiguous HTTP/1.1 message framing at every intermediary > Use RFC 9112 — HTTP/1.1 to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/reject-ambiguous-http-1-1-message-framing-at-every-intermediary/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:15:50+00:00 - Modified: 2026-08-27T12:53:58+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 9112 — HTTP/1.1 to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 9112 — HTTP/1.1 ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Reject ambiguous HTTP/1.1 message framing at every intermediary. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 9112 — HTTP/1.1](https://www.rfc-editor.org/rfc/rfc9112.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - An HTTP/1.1 recipient parses the message as octets, not an unconstrained Unicode stream, before interpreting extracted protocol elements. The research record locates this support at Section 2.2 (Message Parsing). - A sender must not combine Content-Length with Transfer-Encoding; if both arrive, Transfer-Encoding wins and a forwarding intermediary first removes Content-Length. The research record locates this support at Sections 6.1 (Transfer-Encoding), 6.2 (Content-Length), and 6.3 (Message Body Length), rule 3. - Invalid or conflicting Content-Length framing is unrecoverable unless every valid list value is identical, with requests rejected and response recipients closing the upstream connection. The research record locates this support at Section 6.3 (Message Body Length), rule 5. Keep the evidence boundary at these traced claims. They support a review of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish This RFC evidence supports only the named web or transport decision; it does not prove browser, intermediary, library, or service compatibility. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that DNS, certificates, identity providers, time, content delivery, network paths, and application ownership are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at Section 2.2 (Message Parsing), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Sections 6.1 (Transfer-Encoding), 6.2 (Content-Length), and 6.3 (Message Body Length), rule 3, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 6.3 (Message Body Length), rule 5, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points are in and out of scope? - Which condition in DNS, certificates, identity providers, time, content delivery, network paths, and application ownership must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of clients, origin services, intermediaries, caches, proxies, gateways, protocol versions, and security-policy enforcement points, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check DNS, certificates, identity providers, time, content delivery, network paths, and application ownership in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from Section 2.2 (Message Parsing); Sections 6.1 (Transfer-Encoding), 6.2 (Content-Length), and 6.3 (Message Body Length), rule 3; Section 6.3 (Message Body Length), rule 5 through request and response captures, negotiated protocol details, headers, cache behavior, certificate state, and server or proxy logs. Record what was collected, where, when, by whom, and which system or role it represents. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [RFC 9112 — HTTP/1.1](https://www.rfc-editor.org/rfc/rfc9112.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 9112 — HTTP/1.1 - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9112.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Reject ambiguous HTTP/1.1 message framing at every intermediary,” DSE Security, https://update.dsesecurity.com/updates/reject-ambiguous-http-1-1-message-framing-at-every-intermediary/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Reject authoritative implementations that mishandle AAAA query responses > Use RFC 4074 — Common Misbehavior Against DNS Queries for IPv6 Addresses to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/reject-authoritative-implementations-that-mishandle-aaaa-query-responses/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:17:31+00:00 - Modified: 2026-08-27T12:18:10+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use RFC 4074 — Common Misbehavior Against DNS Queries for IPv6 Addresses to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of RFC 4074 — Common Misbehavior Against DNS Queries for IPv6 Addresses ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Reject authoritative implementations that mishandle AAAA query responses. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [RFC 4074 — Common Misbehavior Against DNS Queries for IPv6 Addresses](https://www.rfc-editor.org/rfc/rfc4074.html) from RFC Editor / Internet Engineering Task Force supports the following bounded statements: - For an existing name that has no AAAA record, an authoritative server should return NOERROR with an empty answer rather than NXDOMAIN. The research record locates this support at Section 3 (Expected Behavior). - Returning NXDOMAIN to an AAAA query incorrectly asserts that the queried name does not exist, not merely that its AAAA record is absent. The research record locates this support at Section 4.2 (Return Name Error). - An authoritative server that omits the AA bit from an empty AAAA response can be treated as lame and cause unnecessary fallback behavior. The research record locates this support at Section 4.5 (Do Not Return an Authoritative Answer). Only the traced statements above are asserted as source facts. Apply the review to authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers after confirming that the source and deployed context match. ## What the source does not establish This RFC evidence supports only the named DNS protocol decision; it does not prove Windows implementation support or a safe production configuration. No current deployment state or change approval follows from the source alone. Validate Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Section 3 (Expected Behavior), which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Section 4.2 (Return Name Error), which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Section 4.5 (Do Not Return an Authoritative Answer), which observable configuration, record, or test can confirm applicability here? - Within authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, which versions, roles, and configuration states define the review population? - Could Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of authoritative zones, delegations, resolvers, caches, record owners, and the clients that consume the resulting answers, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Windows DNS roles, Active Directory-integrated data, forwarding paths, time, routing, firewalls, and registrar or registry state in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence Build a reproducible chain from Section 3 (Expected Behavior); Section 4.2 (Return Name Error); Section 4.5 (Do Not Return an Authoritative Answer) to the observed environment. Useful domain evidence includes zone data, packet captures, query transcripts, delegation checks, resolver configuration, and negative-answer behavior; label every item with scope, timestamp, collector, and stable identifier. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [RFC 4074 — Common Misbehavior Against DNS Queries for IPv6 Addresses](https://www.rfc-editor.org/rfc/rfc4074.html) — RFC Editor / Internet Engineering Task Force ## Primary reference - Name: RFC 4074 — Common Misbehavior Against DNS Queries for IPv6 Addresses - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc4074.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Reject authoritative implementations that mishandle AAAA query responses,” DSE Security, https://update.dsesecurity.com/updates/reject-authoritative-implementations-that-mishandle-aaaa-query-responses/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove an identity sensor deliberately when decommissioning its domain controller > Use Remove the Microsoft Defender for Identity sensor to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-identity-sensor-deliberately-when-decommissioning-domain-controller/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:12:46+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Remove the Microsoft Defender for Identity sensor to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remove the Microsoft Defender for Identity sensor ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Remove an identity sensor deliberately when decommissioning its domain controller. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remove the Microsoft Defender for Identity sensor](https://learn.microsoft.com/en-us/defender-for-identity/uninstall-sensor) from Microsoft supports the following bounded statements: - Microsoft documents sensor removal for domain-controller decommissioning, orphaned or duplicate sensor cleanup, and intentionally stopping monitoring on a server. The research record locates this support at Opening applicability statement. - Deleting a v3.x sensor removes its software and stops Defender for Identity monitoring on that domain controller. The research record locates this support at V3 deletion effect. The source support ends with the statements listed above. Use them to examine Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health in the applicable environment, not to imply a wider guarantee. ## What the source does not establish Coordinate server, monitoring, retention, and incident owners before removal; deletion creates an intentional coverage gap. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations before translating the source into an operational decision. ## Applicability questions - For source statement 1 at Opening applicability statement, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at V3 deletion effect, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Defender for Identity workspaces, sensors, directory-service accounts, action accounts, network paths, roles, and deployment health, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory, Windows DNS, time, certificates, domain-controller resources, network capture, cloud connectivity, and security operations and sanitize protected material before retention. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations Opening applicability statement; V3 deletion effect. Favor sensor inventory, service and action-account permissions, health alerts, connectivity tests, portal state, and controlled detection tests, linked to stable identifiers, time, and operator. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Remove the Microsoft Defender for Identity sensor](https://learn.microsoft.com/en-us/defender-for-identity/uninstall-sensor) — Microsoft ## Primary reference - Name: Remove the Microsoft Defender for Identity sensor - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/uninstall-sensor - Source publication date: 2026-07-02 ## Citation and use Preferred citation: “Remove an identity sensor deliberately when decommissioning its domain controller,” DSE Security, https://update.dsesecurity.com/updates/remove-identity-sensor-deliberately-when-decommissioning-domain-controller/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove Entra Connect replication rights only when Password Hash Sync does not need them > Use Remediate hybrid security posture assessments in Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-entra-connect-replication-rights-only-without-password-hash-sync/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:07+00:00 - Modified: 2026-08-27T13:01:32+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 4 minutes ## What you need to know Use Remediate hybrid security posture assessments in Defender for Identity to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remediate hybrid security posture assessments in Defender for Identity ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Remove Entra Connect replication rights only when Password Hash Sync does not need them. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remediate hybrid security posture assessments in Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/hybrid-security) from Microsoft supports the following bounded statements: - The Microsoft Entra Connect express installation grants replication permissions to the AD DS Connector account, and Microsoft recommends removing unnecessary permissions when Password Hash Sync is not configured. The research record locates this support at Remove unnecessary replication permissions for Microsoft Entra Connect AD DS Connector account > description. - When Password Hash Sync is configured, connector accounts with replication permissions are not flagged because those permissions are necessary. The research record locates this support at Remove unnecessary replication permissions for Microsoft Entra Connect AD DS Connector account > Note. - This assessment is available only when a Defender for Identity sensor is installed on the Microsoft Entra Connect server; multiple-server environments need a sensor on each server for full monitoring. The research record locates this support at Remove unnecessary replication permissions for Microsoft Entra Connect AD DS Connector account > Note. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking and the conditions the source actually describes. ## What the source does not establish Before removal, verify that no other application requires the connector account’s replication permissions and that every relevant active or staging Entra Connect server is in assessment scope. No current deployment state or change approval follows from the source alone. Validate Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at Remove unnecessary replication permissions for Microsoft Entra Connect AD DS Connector account > description, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Remove unnecessary replication permissions for Microsoft Entra Connect AD DS Connector account > Note, which observable configuration, record, or test can confirm applicability here? - For source statement 3 at Remove unnecessary replication permissions for Microsoft Entra Connect AD DS Connector account > Note, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking, observed and expected states, owner, and reason for deviation. Do not move from citation to production in one step. Pilot the decision where practical, observe agreed signals, retain a reversal point, and verify Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners. Handle credentials, keys, recovery data, and personal information through approved secure channels. ## Verification and evidence Build a reproducible chain from Remove unnecessary replication permissions for Microsoft Entra Connect AD DS Connector account > description; Remove unnecessary replication permissions for Microsoft Entra Connect AD DS Connector account > Note; Remove unnecessary replication permissions for Microsoft Entra Connect AD DS Connector account > Note to the observed environment. Useful domain evidence includes affected-entity lists, directory attributes, relationship paths, assessment timestamps, remediation tests, and accepted exceptions; label every item with scope, timestamp, collector, and stable identifier. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Remediate hybrid security posture assessments in Defender for Identity](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/hybrid-security) — Microsoft ## Primary reference - Name: Remediate hybrid security posture assessments in Defender for Identity - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/hybrid-security - Source publication date: 2026-08-18 ## Citation and use Preferred citation: “Remove Entra Connect replication rights only when Password Hash Sync does not need them,” DSE Security, https://update.dsesecurity.com/updates/remove-entra-connect-replication-rights-only-without-password-hash-sync/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove standard-user modification rights from Group Policy objects > Use Group policy security assessments to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-standard-user-modification-rights-from-group-policy-objects/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T12:13:04+00:00 - Modified: 2026-08-27T13:04:09+00:00 - Last reviewed by DSE: 2026-08-26 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know Use Group policy security assessments to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Group policy security assessments ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Remove standard-user modification rights from Group Policy objects. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Group policy security assessments](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/group-policy) from Microsoft supports the following bounded statements: - The assessment lists Group Policy objects that standard users can modify and states that this condition can lead to domain compromise. The research record locates this support at GPO modification recommendation description. - Microsoft notes that attackers can inspect Group Policy settings to identify weaknesses, security controls, and potential exploit paths. The research record locates this support at Threat explanation. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking only where the source and recorded environment align. ## What the source does not establish Review delegated administration and application dependencies before changing an ACL; assessment presence alone does not prove exploitation. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners before translating the source into an operational decision. ## Applicability questions - For source statement 1 at GPO modification recommendation description, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Threat explanation, which observable configuration, record, or test can confirm applicability here? - Which deployed instance of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking will be compared with the source, and why that instance? - How will the review distinguish a source mismatch from a failure in Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners? - Who approves the conclusion, exception, test window, and rollback threshold? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of directory identities, posture assessments, exposed relationships, recommendations, ownership, remediation, and exception tracking, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory data quality, Windows DNS, sensor coverage, time, synchronization, cloud processing, and accountable identity owners before and after the test, and store only sanitized operational evidence. ## Verification and evidence Keep the source locations GPO modification recommendation description; Threat explanation adjacent to the sanitized artifacts used for comparison. Prefer affected-entity lists, directory attributes, relationship paths, assessment timestamps, remediation tests, and accepted exceptions, with enough identity and timing data for an independent recheck. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Group policy security assessments](https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/group-policy) — Microsoft ## Primary reference - Name: Group policy security assessments - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/defender-for-identity/security-posture-assessments/group-policy - Source publication date: 2025-09-15 ## Citation and use Preferred citation: “Remove standard-user modification rights from Group Policy objects,” DSE Security, https://update.dsesecurity.com/updates/remove-standard-user-modification-rights-from-group-policy-objects/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove-ADCentralAccessPolicyMember: remove adcentral access policy member with bounded evidence > Use Remove-ADCentralAccessPolicyMember to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-adcentralaccesspolicymember-remove-adcentral-access-policy-member-with-bounded-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:56+00:00 - Modified: 2026-08-27T17:14:55+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Playbook - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Remove-ADCentralAccessPolicyMember to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remove-ADCentralAccessPolicyMember ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Keep this document to one review outcome: Remove-ADCentralAccessPolicyMember: remove adcentral access policy member with bounded evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remove-ADCentralAccessPolicyMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adcentralaccesspolicymember?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Removes central access rules from a central access policy in Active Directory.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Remove-ADCentralAccessPolicyMember cmdlet removes central access rules from a central access policy in Active Directory.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. It does not establish a deployment’s current state, authorize a production change, prove compliance, or show that Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials are healthy. Documented options are review inputs, not universal mandates. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations SYNOPSIS; DESCRIPTION. Favor sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-150 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Remove-ADCentralAccessPolicyMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adcentralaccesspolicymember?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Remove-ADCentralAccessPolicyMember - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adcentralaccesspolicymember?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Remove-ADCentralAccessPolicyMember: remove adcentral access policy member with bounded evidence,” DSE Security, https://update.dsesecurity.com/updates/remove-adcentralaccesspolicymember-remove-adcentral-access-policy-member-with-bounded-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove-ADClaimTransformPolicy: remove adclaim transform policy against recorded identity and DNS state > Use Remove-ADClaimTransformPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-adclaimtransformpolicy-remove-adclaim-transform-policy-against-recorded-identity-and-dns/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:43+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Remove-ADClaimTransformPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remove-ADClaimTransformPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Remove-ADClaimTransformPolicy: remove adclaim transform policy against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remove-ADClaimTransformPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adclaimtransformpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Remove-ADClaimTransformPolicy cmdlet can be used to remove a claim transformation policy object from Active Directory.” The research record locates this support at DESCRIPTION. - At Example 1: Remove a claims transformation policy by name, Microsoft states: “This command removes the claims transformation policy with the name DenyAllPolicy.” The research record locates this support at Example 1: Remove a claims transformation policy by name. Keep the evidence boundary at these traced claims. They support a review of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services; they do not support conclusions outside the source’s stated conditions. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at Example 1: Remove a claims transformation policy by name, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. For an approved change, define prerequisites, a limited test path, success and stop conditions, monitoring, and rollback. Check Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials in design order. Protect credentials, keys, recovery material, personal data, and sensitive topology in evidence. ## Verification and evidence A reviewer should be able to retrace the decision from DESCRIPTION; Example 1: Remove a claims transformation policy by name through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-163 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Remove-ADClaimTransformPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adclaimtransformpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Remove-ADClaimTransformPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adclaimtransformpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Remove-ADClaimTransformPolicy: remove adclaim transform policy against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/remove-adclaimtransformpolicy-remove-adclaim-transform-policy-against-recorded-identity-and-dns/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove-ADComputer: remove adcomputer against recorded identity and DNS state > Use Remove-ADComputer to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-adcomputer-remove-adcomputer-against-recorded-identity-and-dns-state/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:23+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Remove-ADComputer to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remove-ADComputer ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Remove-ADComputer: remove adcomputer against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remove-ADComputer](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adcomputer?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory computer to remove.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “You can identify a computer by its distinguished name, GUID, security identifier (SID), or Security Accounts Manager (SAM) account name.” The research record locates this support at DESCRIPTION. Only the traced statements above are asserted as source facts. Apply the review to Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services after confirming that the source and deployed context match. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence Keep the source locations DESCRIPTION; DESCRIPTION adjacent to the sanitized artifacts used for comparison. Prefer sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, with enough identity and timing data for an independent recheck. Label this evidence set DSE-20260827-183 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Remove-ADComputer](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adcomputer?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Remove-ADComputer - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adcomputer?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Remove-ADComputer: remove adcomputer against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/remove-adcomputer-remove-adcomputer-against-recorded-identity-and-dns-state/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove-ADComputerServiceAccount: remove adcomputer service account with before-and-after evidence > Use Remove-ADComputerServiceAccount to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-adcomputerserviceaccount-remove-adcomputer-service-account-with-before-and-after-evidence/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:27+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Remove-ADComputerServiceAccount to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remove-ADComputerServiceAccount ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to connect an official requirement or behavior to observable evidence: Remove-ADComputerServiceAccount: remove adcomputer service account with before-and-after evidence. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remove-ADComputerServiceAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adcomputerserviceaccount?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “The Remove-ADComputerServiceAccount cmdlet removes service accounts from an Active Directory computer.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory computer that contains the service accounts to remove.” The research record locates this support at DESCRIPTION. These statements are the factual basis for this document. Do not extend them into a broader assurance. Review Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services only where the source and recorded environment align. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before translating the source into an operational decision. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Start with applicability, then compare the observed state with the cited source. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Build a reproducible chain from DESCRIPTION; DESCRIPTION to the observed environment. Useful domain evidence includes sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state; label every item with scope, timestamp, collector, and stable identifier. Label this evidence set DSE-20260827-179 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Retain the starting state, authorization, execution record, outcome, deviation, and final state as one review package. Move disruptive checks to an approved test path. Reopen the decision when versions, design, dependencies, ownership, or official guidance changes. ## Official references - [Remove-ADComputerServiceAccount](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adcomputerserviceaccount?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Remove-ADComputerServiceAccount - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adcomputerserviceaccount?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Remove-ADComputerServiceAccount: remove adcomputer service account with before-and-after evidence,” DSE Security, https://update.dsesecurity.com/updates/remove-adcomputerserviceaccount-remove-adcomputer-service-account-with-before-and-after-evidence/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove-ADDomainControllerPasswordReplicationPolicy: remove addomain controller password replication policy with rollback checks > Use Remove-ADDomainControllerPasswordReplicationPolicy to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-addomaincontrollerpasswordreplicationpolicy-remove-addomain-controller-password-replication/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:29+00:00 - Modified: 2026-08-27T17:14:53+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Remove-ADDomainControllerPasswordReplicationPolicy to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remove-ADDomainControllerPasswordReplicationPolicy ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Remove-ADDomainControllerPasswordReplicationPolicy: remove addomain controller password replication policy with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remove-ADDomainControllerPasswordReplicationPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-addomaincontrollerpasswordreplicationpolicy?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Removes users, computers, and groups from the allowed or denied list of a read-only domain controller password replication policy.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Remove-ADDomainControllerPasswordReplicationPolicy cmdlet removes one or more users, computers, and groups from the allowed or denied list of a read-only domain controller (RODC) password replication policy.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Within Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, which versions, roles, and configuration states define the review population? - Could Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence A reviewer should be able to retrace the decision from SYNOPSIS; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-117 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee. ## Official references - [Remove-ADDomainControllerPasswordReplicationPolicy](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-addomaincontrollerpasswordreplicationpolicy?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Remove-ADDomainControllerPasswordReplicationPolicy - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-addomaincontrollerpasswordreplicationpolicy?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Remove-ADDomainControllerPasswordReplicationPolicy: remove addomain controller password replication policy with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/remove-addomaincontrollerpasswordreplicationpolicy-remove-addomain-controller-password-replication/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove-ADFineGrainedPasswordPolicySubject: remove adfine grained password policy subject against recorded identity and DNS state > Use Remove-ADFineGrainedPasswordPolicySubject to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-adfinegrainedpasswordpolicysubject-remove-adfine-grained-password-policy-subject-against/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:05:28+00:00 - Modified: 2026-08-27T17:14:54+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Remove-ADFineGrainedPasswordPolicySubject to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remove-ADFineGrainedPasswordPolicySubject ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Frame this document as a source-led configuration and assurance check: Remove-ADFineGrainedPasswordPolicySubject: remove adfine grained password policy subject against recorded identity and DNS state. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remove-ADFineGrainedPasswordPolicySubject](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adfinegrainedpasswordpolicysubject?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Removes one or more users from a fine-grained password policy.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Remove-ADFineGrainedPasswordPolicySubject cmdlet removes one or more global security groups and users from a fine-grained password policy.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. A correct source interpretation can still be inapplicable to a particular design. Confirm Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, ownership, and change authority instead of treating documented behavior as a deployment guarantee. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - Within Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, which versions, roles, and configuration states define the review population? - Could Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials invalidate the test, hide a failure, or change applicability? - Who owns the decision, and which observation requires stopping, escalation, or rollback? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence A reviewer should be able to retrace the decision from SYNOPSIS; DESCRIPTION through sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Record what was collected, where, when, by whom, and which system or role it represents. Label this evidence set DSE-20260827-118 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes. ## Official references - [Remove-ADFineGrainedPasswordPolicySubject](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adfinegrainedpasswordpolicysubject?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Remove-ADFineGrainedPasswordPolicySubject - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adfinegrainedpasswordpolicysubject?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Remove-ADFineGrainedPasswordPolicySubject: remove adfine grained password policy subject against recorded identity and DNS state,” DSE Security, https://update.dsesecurity.com/updates/remove-adfinegrainedpasswordpolicysubject-remove-adfine-grained-password-policy-subject-against/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove-ADGroupMember: remove adgroup member under AD/DNS change control > Use Remove-ADGroupMember to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-adgroupmember-remove-adgroup-member-under-ad-dns-change-control/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:40+00:00 - Modified: 2026-08-27T17:18:33+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Briefing - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Remove-ADGroupMember to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remove-ADGroupMember ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Use this document to resolve one bounded operational decision: Remove-ADGroupMember: remove adgroup member under AD/DNS change control. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remove-ADGroupMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adgroupmember?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At SYNOPSIS, Microsoft states: “Removes one or more members from an Active Directory group.” The research record locates this support at SYNOPSIS. - At DESCRIPTION, Microsoft states: “The Remove-ADGroupMember cmdlet removes one or more users, groups, service accounts, or computers from an Active Directory group.” The research record locates this support at DESCRIPTION. The source support ends with the statements listed above. Use them to examine Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services in the applicable environment, not to imply a wider guarantee. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at SYNOPSIS, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Make the source, asset scope, owner, and expected outcome explicit in the review record. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials and sanitize protected material before retention. ## Verification and evidence Tie each conclusion back to SYNOPSIS; DESCRIPTION and to observable material such as sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state. Preserve provenance and stable identifiers without copying secrets into the evidence set. Label this evidence set DSE-20260827-166 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Keep before-state evidence, approval, test or change result, exceptions, and after-state evidence together. Use an approved lab, window, or nonproduction path for risky tests. Set a recheck trigger for version, architecture, dependency, vendor, incident, or ownership change. A check proves only what was observed. ## Official references - [Remove-ADGroupMember](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adgroupmember?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Remove-ADGroupMember - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adgroupmember?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Remove-ADGroupMember: remove adgroup member under AD/DNS change control,” DSE Security, https://update.dsesecurity.com/updates/remove-adgroupmember-remove-adgroup-member-under-ad-dns-change-control/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove-ADObject: remove adobject with rollback checks > Use Remove-ADObject to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-adobject-remove-adobject-with-rollback-checks/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:34+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Checklist - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Remove-ADObject to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remove-ADObject ## DSE recommendation Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards. ## Article Treat this document as a focused evidence review: Remove-ADObject: remove adobject with rollback checks. Only the official source and traced locations below supply facts. Confirm applicability before acting. ## Source fact: The official [Remove-ADObject](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adobject?view=windowsserver2025-ps) from Microsoft supports the following bounded statements: - At DESCRIPTION, Microsoft states: “You can use this cmdlet to remove any type of Active Directory object.” The research record locates this support at DESCRIPTION. - At DESCRIPTION, Microsoft states: “The Identity parameter specifies the Active Directory object to remove.” The research record locates this support at DESCRIPTION. Do not import neighboring assumptions into the source record. The supported task is a scoped comparison involving Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services and the conditions the source actually describes. ## What the source does not establish The cited page and retained statements do not establish the current state of any DSE or customer environment, prove that the documented configuration is applicable, or authorize a production change. Confirm supported versions, dependencies, and the current live source before use. No current deployment state or change approval follows from the source alone. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials, and treat examples or options as conditional inputs rather than defaults. ## Applicability questions - For source statement 1 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - For source statement 2 at DESCRIPTION, which observable configuration, record, or test can confirm applicability here? - What inventory proves which parts of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services are in and out of scope? - Which condition in Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials must be healthy before evidence is trustworthy? - What result would disprove the working assumption and return the issue to the owner? ## DSE recommendation: DSE recommends using the cited source as the evidence anchor for this decision. Use a two-person review for the source interpretation and the resulting operational decision. Record the source location, examined part of Active Directory objects, search bases, domain controllers, delegated roles, cmdlet parameters, and the DNS paths used to locate directory services, observed and expected states, owner, and reason for deviation. An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate Active Directory replication, Windows DNS, domain-controller location, time, network reachability, privileges, and protected credentials before and after the test, and store only sanitized operational evidence. ## Verification and evidence Evidence should let another reviewer reproduce this decision. Retain observations beside the traced locations DESCRIPTION; DESCRIPTION. Favor sanitized command transcripts, parameter records, directory exports, authorization records, DNS locator tests, and before-and-after state, linked to stable identifiers, time, and operator. Label this evidence set DSE-20260827-172 so observations, approvals, exceptions, and later rechecks cannot be substituted from another source review. Preserve both successful and failed observations, along with approval and rollback evidence. Avoid uncontrolled production experiments. Assign an expiry or event-driven recheck so the conclusion is not treated as permanent. ## Official references - [Remove-ADObject](https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adobject?view=windowsserver2025-ps) — Microsoft ## Primary reference - Name: Remove-ADObject - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/powershell/module/activedirectory/remove-adobject?view=windowsserver2025-ps - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Remove-ADObject: remove adobject with rollback checks,” DSE Security, https://update.dsesecurity.com/updates/remove-adobject-remove-adobject-with-rollback-checks/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved. --- # Remove-ADPrincipalGroupMembership: remove adprincipal group membership against recorded identity and DNS state > Use Remove-ADPrincipalGroupMembership to review this narrow operational decision without extending the source beyond its stated scope. - Canonical URL: https://update.dsesecurity.com/updates/remove-adprincipalgroupmembership-remove-adprincipal-group-membership-against-recorded-identity-and/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-27T17:04:33+00:00 - Modified: 2026-08-27T17:18:34+00:00 - Last reviewed by DSE: 2026-08-27 - Resource type: Explainer - DSE priority: Advisory - Topics: Cybersecurity, Microsoft 365 & Identity, Networks & Infrastructure - Reading time: 3 minutes ## What you need to know Use Remove-ADPrincipalGroupMembership to review this narrow operational decision without extending the source beyond its stated scope. ## Potentially affected Teams, systems, services, or facilities within the stated scope of Remove-ADPrincipalGroupMembership ## DSE recommendation Compare the observed state with the cited offi