Security and technology teams receive a constant stream of release notes, vulnerability disclosures, product notices, and urgent-sounding headlines. DSE Updates is a public editorial library designed to make selected information easier to use. Authorized DSE staff periodically review official vendor and government sources and publish source-backed guidance when an item is selected for coverage. It is not a continuous monitoring service, a customer-specific alert feed, or a substitute for opening a support ticket.
\nEvery time-sensitive briefing links to an official source and separates confirmed facts from DSE recommendations. Priority labels reflect likely operational urgency, but they do not replace an environment-specific assessment. Product versions, configurations, exposure, and business impact all matter.
\nOnly authorized DSE staff can publish or change articles. Customers can read, search, filter, and share updates without public posting, comments, or voting. This keeps the publication focused, professional, and accountable.
", "content_text": "What this publication is for\nSecurity and technology teams receive a constant stream of release notes, vulnerability disclosures, product notices, and urgent-sounding headlines. DSE Updates is a public editorial library designed to make selected information easier to use. Authorized DSE staff periodically review official vendor and government sources and publish source-backed guidance when an item is selected for coverage. It is not a continuous monitoring service, a customer-specific alert feed, or a substitute for opening a support ticket.\nWhat we cover\n\nVideo surveillance: device firmware, video-management platforms, recording infrastructure, and secure deployment practices.\nAccess control: controllers, readers, credentials, management software, and connected door hardware.\nIT: operating systems, networks, cloud platforms, endpoints, servers, and business applications.\nCybersecurity: exploited vulnerabilities, defensive guidance, identity, hardening, and recovery readiness.\nDSE World: service announcements, new capabilities, and guidance from Detection Systems & Engineering.\n\nOur editorial standard\nEvery time-sensitive briefing links to an official source and separates confirmed facts from DSE recommendations. Priority labels reflect likely operational urgency, but they do not replace an environment-specific assessment. Product versions, configurations, exposure, and business impact all matter.\nA focused, read-only customer experience\nOnly authorized DSE staff can publish or change articles. Customers can read, search, filter, and share updates without public posting, comments, or voting. This keeps the publication focused, professional, and accountable.", "content_markdown": "## What this publication is for\n\nSecurity and technology teams receive a constant stream of release notes, vulnerability disclosures, product notices, and urgent-sounding headlines. DSE Updates is a public editorial library designed to make selected information easier to use. Authorized DSE staff periodically review official vendor and government sources and publish source-backed guidance when an item is selected for coverage. It is not a continuous monitoring service, a customer-specific alert feed, or a substitute for opening a support ticket.\n\n## What we cover\n\n- Video surveillance: device firmware, video-management platforms, recording infrastructure, and secure deployment practices.\n\n- Access control: controllers, readers, credentials, management software, and connected door hardware.\n\n- IT: operating systems, networks, cloud platforms, endpoints, servers, and business applications.\n\n- Cybersecurity: exploited vulnerabilities, defensive guidance, identity, hardening, and recovery readiness.\n\n- DSE World: service announcements, new capabilities, and guidance from Detection Systems & Engineering.\n\n## Our editorial standard\n\nEvery time-sensitive briefing links to an official source and separates confirmed facts from DSE recommendations. Priority labels reflect likely operational urgency, but they do not replace an environment-specific assessment. Product versions, configurations, exposure, and business impact all matter.\n\n## A focused, read-only customer experience\n\nOnly authorized DSE staff can publish or change articles. Customers can read, search, filter, and share updates without public posting, comments, or voting. This keeps the publication focused, professional, and accountable." }, { "id": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/", "slug": "physical-access-control-ot-segmentation-remote-access", "url": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/physical-access-control-ot-segmentation-remote-access.md", "json": "https://update.dsesecurity.com/api/v1/posts/physical-access-control-ot-segmentation-remote-access/" }, "title": "Treat physical access control as OT: segment it, constrain remote access, preserve availability", "summary": "NIST explicitly includes physical access-control systems in OT and frames their security around mapped data flows, segmentation, controlled remote access, and availability.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" }, { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:29:04+00:00", "modified_at": "2026-07-19T21:29:04+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 438, "potentially_affected": "Networked physical access-control servers, controllers, readers, management workstations, building-system integrations, cloud connections, and temporary or persistent vendor access.", "dse_recommendation": "Map access-system dependencies and required flows, build risk-based zones, limit remote access, and test security changes against door availability and emergency operations.", "primary_source": { "name": "NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security", "url": "https://csrc.nist.gov/pubs/sp/800/82/r3/final", "published_on": "2023-09-28", "authority": "National Institute of Standards and Technology" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Source fact: NIST SP 800-82 Rev. 3 defines operational technology broadly and explicitly lists physical access-control systems as an example. Its PACS description includes credentials, readers or keypads, door controllers, an access-control server, rules and privileges, and audit logs. The server can be on premises or managed in the cloud.
\nThe OT framing changes how controls are introduced. NIST explains that rebooting may be unacceptable where availability is required, outages may need to be planned well in advance, redundancy can be necessary, and high-availability designs need extensive predeployment testing. A security improvement that unexpectedly prevents authorized entry or emergency work is not a successful deployment.
\n\nNIST recommends segmentation or zoning by factors such as function, criticality, trust, location, management authority, or data flow. Segmentation can use physically separate infrastructure or logical VLANs. Mapped data flows should identify required communications, while firewalls, gateways, switches, routers, or other enforcement devices allow only explicitly authorized traffic between segments. A DMZ can serve as a boundary where appropriate.
\nRemote access should be provided only when justified and limited to the business need. It should not bypass safety or security controls. NIST says multi-factor authentication should be considered and that temporary vendor-maintenance access still needs secure procedures. Remote-access disablement is important, but its operation must not disrupt the OT process.
\n\nRev. 3, finalized September 28, 2023, remains NIST’s current final SP 800-82 publication as of this review. NIST has begun a Rev. 4 pre-draft process, but a pre-draft is not final guidance. SP 800-82 is also architecture-level material, not a configuration manual for a particular access-control platform.
\n\nDSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.
\nSource fact: The Security Center Hardening Guide 5.14, last updated March 19, 2026, describes hardening as an incremental process. Genetec separates Basic measures for systems requiring a minimum level of security from Advanced measures that are more complex or take longer to implement. Advanced includes the Basic level.
\nGenetec also states that default settings balance security, usability, and performance. Additional hardening can improve security at the expense of usability or performance, so the selected level should reflect the threat model and sensitivity of the information. The guide’s Security score widget rates adherence and can provide a repeatable baseline, but a score is not a substitute for testing or risk acceptance.
\n\nThe 5.14 guide covers default and server credentials, password policy, desktop session controls, identity providers, minimum privileges, trusted certificates, unused roles, updates, secure media communication, camera passwords and HTTPS, video encryption and signatures, access-control-unit hardening, secure reader connections, activity trails, web and mobile roles, databases, Windows updates, time synchronization, safe TLS, and disk encryption.
\nPrivilege behavior deserves specific validation. Genetec recommends giving users only the minimum required rights and provides templates and a Privilege troubleshooter. Users have basic privileges and distinct partition privileges; partition-level grants or denials can override the basic set. When privileges change while a user is signed in, the change takes effect only after sign-out and sign-in. Applying templates adds privileges and does not remove existing ones automatically.
\nGenetec identifies logging security-related events to the database for reporting through Activity Trails as a Basic practice. That evidence should be included when validating administrative and operator changes.
\n\nThis guidance is specific to Security Center 5.14. Navigation, features, defaults, dependencies, and recommendations can differ in another release. A checklist item is not blanket authorization to enable a control across production; camera, door, federation, failover, client, export, and emergency workflows need representative testing.
\n\nDSE recommendation: This is DSE operational synthesis organized from Genetec’s version-specific guide.
\nSource 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.
\nThe 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.
\n\nBackup 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.
\nTesting 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.
\nEngineering 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.
\n\nSP 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.
\n\nDSE recommendation: This checklist is DSE operational synthesis from SP 1339; apply it only where the physical-security system’s operational characteristics fit.
\nSource 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.
\nThe 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.
\nA 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.
\n\nProfile 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.
\nTwo 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.
\n\nDSE recommendation: The following is DSE operational synthesis, not an ONVIF accuracy or privacy standard.
\nSource 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.
\nONVIF’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.
\nProfile 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.
\n\nFirst 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.
\nConformance 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.
\n\nDSE recommendation: This checklist is DSE operational synthesis; ONVIF does not prescribe this site-test sequence.
\nSource fact: The AXIS OS Forensics Guide applies to AXIS OS products on active and long-term-support tracks. It organizes response into detection, evidence collection, and cleanup. That order is material: Axis warns that modifying or powering off a suspected device can destroy evidence.
\nAxis lists indicators such as access from an unknown address, unauthorized network traffic or video streaming, unexpected file transfers, configuration changes, new accounts, lost video or audio, and unknown applications. An indicator requires investigation; it is not proof by itself that a device was compromised.
\nThe device server report contains health information, system details, configuration information, and logs. Axis identifies its downloadable archive as the primary resource for device forensic investigation. Audit logging was introduced in AXIS OS 12.7. The guide warns that a factory default clears logs held locally and recommends remote syslog to prevent that specific loss.
\n\nAxis describes factory default as the most efficient cleanup step for its devices after evidence is collected. For devices without signed OS and secure boot, Axis directs users to install the latest supported AXIS OS after factory default and monitor the device before reintroduction. For devices with signed OS and secure boot, Axis states that factory default returns the device to a guaranteed non-compromised state.
\nThose are product-specific statements, not a complete enterprise incident-response plan. The guide does not replace legal preservation, organizational escalation, network forensics, credential response, or continuity planning. Containment and cleanup must also account for security coverage and any operational dependency.
\n\nDSE recommendation: This is DSE operational synthesis. Preserve evidence and follow the organization’s incident authority before changing the device.
\nSource 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.
\nSupport 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.
\nONVIF’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.
\n\nAdd-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.
\nA 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.
\n\nDSE recommendation: This is DSE operational synthesis. It does not predict the content or release date of version 2.0.
\nSource fact: NIST SP 800-88 Rev. 2 defines media sanitization as making access to target data infeasible for a given level of effort. The revision shifts emphasis from media-specific command tables toward an enterprise program that protects sensitive information during reuse or disposal.
\nNIST organizes the program around three methods: clear, purge, and destroy. Its July 2026 FAQ says policy should connect information classification to acceptable methods and define documentation, evidence, roles, training, tool configuration, maintenance, verification, and validation. Rev. 2 does not recommend a specific command for each product; it points organizations toward current standards and approved policy.
\nThe FAQ also rejects a common shortcut: a seven-pass overwrite is not required. NIST says legacy multi-pass practices provide little additional confidentiality for modern storage and can shorten flash-media life. Sanitizing the entire information-storage-media device is preferred because selected data can spill into overprovisioned areas, remapped bad blocks, or other locations outside a logical boundary.
\n\nVerification checks whether the sanitization technique completed without technical errors or anomalies. Validation is the organizational decision that reviews that evidence against data sensitivity and accepts any residual confidentiality risk. Both are needed for sanitization assurance.
\nCryptographic erase is not automatically valid because a product used encryption. NIST lists prerequisites including adequate cryptographic strength, no prior sensitive plaintext outside the protected boundary, and permanent zeroization of the relevant keys. Cloud or virtual storage introduces additional service and key-management dependencies.
\n\nDSE recommendation: This is DSE operational synthesis. Confirm preservation obligations and approved techniques before changing media.
\nSource fact: Axis developer documentation explains that signed video adds cryptographic signatures to captured H.264 or H.265 video as Supplemental Enhancement Information, or SEI, within the codec stream. Information derived from frames is signed with a private key, and verification uses the corresponding public information carried with the signed data.
\nAxis ties signing to the camera’s unique identity through Axis Edge Vault. Its documentation describes the result as a way to determine whether footage has been altered after leaving the camera and to trace the footage to its originating device. Support is currently associated with devices that include Axis Edge Vault, and Axis provides product and API methods for checking whether the function exists.
\nThe recording path matters. Axis states that the SEI frames must be preserved during both recording and export. If a VMS, transcoder, exporter, or container conversion discards them, later verification cannot use the signed-video data. Axis File Player supports H.264 and H.265 in ASF and MKV and H.264 in MP4 for the documented verification workflow.
\n\nAxis product documentation distinguishes integrity verification from chain of custody. Signed video does not by itself prove who controlled the exported file, who viewed or copied it, whether collection was lawful, whether the camera clock and location were correct, or whether the scene outside the field of view contradicts the recording. Those questions require separate governance and evidence records.
\nSupport and default enablement can vary by device, AXIS OS release, content destination, VMS, export format, and configuration. Current product documentation must be used for the deployed model rather than assuming one behavior across the estate.
\n\nDSE recommendation: This is DSE operational synthesis, not a legal conclusion about admissibility or authenticity.
\nSource 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.
\nThe 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.
\nFor 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.
\n\nAxis 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.
\nAn 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.
\n\nDSE recommendation: This is DSE operational synthesis for Axis environments, not a universal PKI design.
\nSource 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.
\nFor 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.
\n\nThe 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.
\nStorage 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.
\n\nSIA 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.
\n\nDSE recommendation: This is DSE operational synthesis and should be completed with qualified counsel for applicable law.
\nSource 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.
\nThe 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.
\n\nSIA 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.
\nFor 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.
\n\nDSE 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.
\nSource 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.
\nThe 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.
\nA 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.
\n\nProfile 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.
\nConditional 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.
\n\nDSE recommendation: This is DSE operational synthesis, not an ONVIF door-hardware or code-compliance procedure.
\nSource 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.
\nThe 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.
\nThe 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.
\n\nProfile 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.
\n\nDSE recommendation: The following is DSE operational synthesis based on the ONVIF material, not an ONVIF-mandated migration sequence.
\nThe Microsoft 365 admin center Service health page shows the state of cloud services and active issues. Microsoft distinguishes advisories, where a service remains available but has limited or intermittent impact, from incidents, where a service or major function is unavailable. The page can also show issues detected for the organization that require customer action.
\nMicrosoft directs administrators to the public service-status page and the Microsoft 365 status account when the tenant admin center cannot be reached. Planned maintenance is not shown in Service health; Microsoft documents Message center as the location for planned maintenance, upcoming changes, feature updates, retirements, privacy notices, and actions required to avoid disruption.
\nMessage center offers service, tag, state, timing, act-by, platform, impact, and relevance fields. Microsoft documents that major updates requiring action are communicated at least 30 days ahead and that Plan for change posts are intended to provide advance action guidance, while acknowledging that availability and relevance features vary. Messages can be shared, linked, synchronized to Planner, or retrieved through the service communications API.
\nMicrosoft 365 administrative roles determine who can view Service health and Message center. Some roles do not have Message center access; a Message center reader can be used without broader administration. Release status is available only for supported announcements and currently has limited service coverage. Government, sovereign, service-specific, mobile, API, Planner, and privacy-message behavior can differ. Relevance is a prioritization aid, not proof that a message has no impact.
\nDSE recommends separating Microsoft service incidents from local changes in the incident record. Correlation does not prove causation. If no service issue is posted, continue local investigation and use the admin-center report-an-issue path where appropriate.
\nMicrosoft Secure Score is a measurement of an organization’s security posture based on completed recommended actions across supported Microsoft and integrated products. Microsoft describes uses that include reporting current posture, discovering improvement actions, tracking trends, comparing with similar organizations, and establishing key performance indicators.
\nPoints can be awarded for configuring a recommended feature, performing a security task, or recording that a non-Microsoft product or alternate mitigation addresses the action. Some recommendations receive partial credit based on the percentage of users or devices covered; others are binary. Administrators can accept the remaining risk where a recommendation is not appropriate.
\nMicrosoft shows the full set of possible recommendations for a supported licensed product regardless of the particular license edition, subscription, or plan. That visibility does not mean every recommended capability is included in the tenant’s license. Secure Score synchronizes service data on different schedules; some product states update in real time, daily, weekly, or monthly.
\nMicrosoft explicitly states that Secure Score is not an absolute measurement of breach likelihood and is not a guarantee against a breach. Recommendations do not cover every attack surface. Usability, operational continuity, compensating controls, risk tolerance, current product licensing, device coverage, data latency, and implementation quality affect the real outcome. Defender XDR unified RBAC or documented Microsoft Entra roles control access to Secure Score data.
\nDSE recommends reporting score movement with context: which risk changed, how much of the estate is covered, whether validation passed, and what residual risk remains. A score can rise while critical unmanaged systems remain outside its view, or fall after Microsoft adds a new recommendation without any local regression.
\nMicrosoft Secure Score — scoring, partial points, alternate mitigations, product coverage, permissions, update timing, and risk limitations.
", "content_text": "Source fact: what Microsoft documents\nMicrosoft Secure Score is a measurement of an organization’s security posture based on completed recommended actions across supported Microsoft and integrated products. Microsoft describes uses that include reporting current posture, discovering improvement actions, tracking trends, comparing with similar organizations, and establishing key performance indicators.\nPoints can be awarded for configuring a recommended feature, performing a security task, or recording that a non-Microsoft product or alternate mitigation addresses the action. Some recommendations receive partial credit based on the percentage of users or devices covered; others are binary. Administrators can accept the remaining risk where a recommendation is not appropriate.\nMicrosoft shows the full set of possible recommendations for a supported licensed product regardless of the particular license edition, subscription, or plan. That visibility does not mean every recommended capability is included in the tenant’s license. Secure Score synchronizes service data on different schedules; some product states update in real time, daily, weekly, or monthly.\nLimits and applicability\nMicrosoft explicitly states that Secure Score is not an absolute measurement of breach likelihood and is not a guarantee against a breach. Recommendations do not cover every attack surface. Usability, operational continuity, compensating controls, risk tolerance, current product licensing, device coverage, data latency, and implementation quality affect the real outcome. Defender XDR unified RBAC or documented Microsoft Entra roles control access to Secure Score data.\nDSE recommendation: production-safe operational steps\n\nExport the current score, recommendations, achieved points, affected products, coverage, and trend as a dated baseline.\nAssign a technical owner and business owner to candidate actions. Confirm that the affected product, users, devices, and license are actually in scope.\nPrioritize by credible exposure reduction, affected population, exploitability, business criticality, implementation effort, and recovery complexity rather than points alone.\nOpen a controlled change for each material recommendation. Document current state, target state, pilot population, test cases, communications, rollback, and evidence required for closure.\nUse representative pilots and validate business workflows. Do not apply a setting directly from the recommendation without reading its current product documentation.\nRecord a supported alternate mitigation or explicit risk acceptance when the recommendation is not suitable. Assign an owner and review date.\nAllow for documented score-update latency, then verify the service state independently. Trend completed, tested controls and unresolved high-risk actions.\n\nDSE recommends reporting score movement with context: which risk changed, how much of the estate is covered, whether validation passed, and what residual risk remains. A score can rise while critical unmanaged systems remain outside its view, or fall after Microsoft adds a new recommendation without any local regression.\nOfficial reference\nMicrosoft Secure Score — scoring, partial points, alternate mitigations, product coverage, permissions, update timing, and risk limitations.", "content_markdown": "## Source fact: what Microsoft documents\n\nMicrosoft Secure Score is a measurement of an organization’s security posture based on completed recommended actions across supported Microsoft and integrated products. Microsoft describes uses that include reporting current posture, discovering improvement actions, tracking trends, comparing with similar organizations, and establishing key performance indicators.\n\nPoints can be awarded for configuring a recommended feature, performing a security task, or recording that a non-Microsoft product or alternate mitigation addresses the action. Some recommendations receive partial credit based on the percentage of users or devices covered; others are binary. Administrators can accept the remaining risk where a recommendation is not appropriate.\n\nMicrosoft shows the full set of possible recommendations for a supported licensed product regardless of the particular license edition, subscription, or plan. That visibility does not mean every recommended capability is included in the tenant’s license. Secure Score synchronizes service data on different schedules; some product states update in real time, daily, weekly, or monthly.\n\n## Limits and applicability\n\nMicrosoft explicitly states that Secure Score is not an absolute measurement of breach likelihood and is not a guarantee against a breach. Recommendations do not cover every attack surface. Usability, operational continuity, compensating controls, risk tolerance, current product licensing, device coverage, data latency, and implementation quality affect the real outcome. Defender XDR unified RBAC or documented Microsoft Entra roles control access to Secure Score data.\n\n## DSE recommendation: production-safe operational steps\n\n- Export the current score, recommendations, achieved points, affected products, coverage, and trend as a dated baseline.\n\n- Assign a technical owner and business owner to candidate actions. Confirm that the affected product, users, devices, and license are actually in scope.\n\n- Prioritize by credible exposure reduction, affected population, exploitability, business criticality, implementation effort, and recovery complexity rather than points alone.\n\n- Open a controlled change for each material recommendation. Document current state, target state, pilot population, test cases, communications, rollback, and evidence required for closure.\n\n- Use representative pilots and validate business workflows. Do not apply a setting directly from the recommendation without reading its current product documentation.\n\n- Record a supported alternate mitigation or explicit risk acceptance when the recommendation is not suitable. Assign an owner and review date.\n\n- Allow for documented score-update latency, then verify the service state independently. Trend completed, tested controls and unresolved high-risk actions.\n\nDSE recommends reporting score movement with context: which risk changed, how much of the estate is covered, whether validation passed, and what residual risk remains. A score can rise while critical unmanaged systems remain outside its view, or fall after Microsoft adds a new recommendation without any local regression.\n\n## Official reference\n\n[Microsoft Secure Score](https://learn.microsoft.com/en-us/defender-xdr/microsoft-secure-score) — scoring, partial points, alternate mitigations, product coverage, permissions, update timing, and risk limitations." }, { "id": "https://update.dsesecurity.com/updates/microsoft-teams-external-versus-guest-access/", "slug": "microsoft-teams-external-versus-guest-access", "url": "https://update.dsesecurity.com/updates/microsoft-teams-external-versus-guest-access/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/microsoft-teams-external-versus-guest-access.md", "json": "https://update.dsesecurity.com/api/v1/posts/microsoft-teams-external-versus-guest-access/" }, "title": "Choose Teams external access, guest access, or neither for each collaboration need", "summary": "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.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:28:15+00:00", "modified_at": "2026-07-19T21:28:15+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 563, "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.", "primary_source": { "name": "Microsoft Learn: Use guest access and external access to collaborate with people outside your organization", "url": "https://learn.microsoft.com/en-us/microsoftteams/communicate-with-users-from-other-organizations", "published_on": "2026-07-01", "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Microsoft 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.
\nGuest 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.
\nPublic 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.
\nShared 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.
\nMicrosoft 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.
\nDSE 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.
\nOneDrive 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.
\nMicrosoft 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.
\nExisting 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.
\nThe 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.
\nDSE 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.
\nRedirect and move Windows known folders to OneDrive — supported folders, policies, rollout rates, prior redirection, bandwidth, and migration behavior.
", "content_text": "Source fact: what Microsoft documents\nOneDrive 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.\nMicrosoft 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.\nExisting 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.\nLicensing and applicability\nThe 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.\nDSE recommendation: production-safe operational steps\n\nInventory 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.\nDefine the supported transition for local folders, network shares, or another OneDrive tenant. Preserve authoritative source data until destination validation is complete.\nUpdate the OneDrive sync app and verify required Microsoft 365 network endpoints, disk capacity, user identity, and Files On-Demand behavior.\nPilot representative users with large data sets, laptops, remote connections, specialized applications, multiple devices, and redirected folders.\nValidate folder contents, timestamps where important, application save paths, desktop appearance, synchronization, conflict handling, web access, new-device recovery, and user support.\nThrottle or schedule upload where required and expand within Microsoft’s current daily and weekly rollout guidance.\nMonitor sync health and storage continuously. Remove the source only after documented acceptance and the applicable retention period.\n\nDSE 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.\nOfficial reference\nRedirect and move Windows known folders to OneDrive — supported folders, policies, rollout rates, prior redirection, bandwidth, and migration behavior.", "content_markdown": "## Source fact: what Microsoft documents\n\nOneDrive 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.\n\nMicrosoft 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.\n\nExisting 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.\n\n## Licensing and applicability\n\nThe 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.\n\n## DSE recommendation: production-safe operational steps\n\n- 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.\n\n- Define the supported transition for local folders, network shares, or another OneDrive tenant. Preserve authoritative source data until destination validation is complete.\n\n- Update the OneDrive sync app and verify required Microsoft 365 network endpoints, disk capacity, user identity, and Files On-Demand behavior.\n\n- Pilot representative users with large data sets, laptops, remote connections, specialized applications, multiple devices, and redirected folders.\n\n- Validate folder contents, timestamps where important, application save paths, desktop appearance, synchronization, conflict handling, web access, new-device recovery, and user support.\n\n- Throttle or schedule upload where required and expand within Microsoft’s current daily and weekly rollout guidance.\n\n- Monitor sync health and storage continuously. Remove the source only after documented acceptance and the applicable retention period.\n\nDSE 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.\n\n## Official reference\n\n[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." }, { "id": "https://update.dsesecurity.com/updates/windows-autopatch-production-prerequisites/", "slug": "windows-autopatch-production-prerequisites", "url": "https://update.dsesecurity.com/updates/windows-autopatch-production-prerequisites/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/windows-autopatch-production-prerequisites.md", "json": "https://update.dsesecurity.com/api/v1/posts/windows-autopatch-production-prerequisites/" }, "title": "Check Windows Autopatch prerequisites before registering production devices", "summary": "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.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:28:15+00:00", "modified_at": "2026-07-19T21:28:15+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 433, "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.", "primary_source": { "name": "Microsoft Learn: Windows Autopatch prerequisites", "url": "https://learn.microsoft.com/en-us/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites", "published_on": "2026-02-27", "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Microsoft documents 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.
\nDevices 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.
\nMicrosoft 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.
\nWindows 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.
\nDSE 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.
\nWindows Autopatch prerequisites — licensing, feature entitlement, Intune and Entra requirements, connectivity, ownership, diagnostic data, editions, channels, and co-management.
", "content_text": "Source fact: what Microsoft documents\nMicrosoft 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.\nDevices 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.\nMicrosoft 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.\nApplicability and cautions\nWindows 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.\nDSE recommendation: production-safe operational steps\n\nConfirm tenant subscriptions, Entra and Intune entitlements, Autopatch feature coverage, and support rights with current Microsoft product terms.\nExport device edition, version, architecture, channel, ownership, join state, Intune enrollment, last check-in, management authority, co-management workloads, and existing update policies.\nIdentify unsupported BYOD, Configuration Manager-only, stale, LTSC, end-of-support, virtual, kiosk, or specialized devices and define a separate servicing plan.\nValidate required Microsoft endpoints through the real proxy, firewall, VPN, DNS, TLS inspection, and branch paths. Record the test and exception owner.\nObtain the required privacy and security approval for diagnostic data and document what features change if the required level is unavailable.\nReconcile WSUS, scan-source, update-ring, feature, quality, driver, firmware, and Configuration Manager settings before registration.\nRegister a representative pilot, review readiness and update reports, validate business applications and recovery, and expand only after defined exit criteria pass.\n\nDSE 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.\nOfficial reference\nWindows Autopatch prerequisites — licensing, feature entitlement, Intune and Entra requirements, connectivity, ownership, diagnostic data, editions, channels, and co-management.", "content_markdown": "## Source fact: what Microsoft documents\n\nMicrosoft 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.\n\nDevices 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.\n\nMicrosoft 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.\n\n## Applicability and cautions\n\nWindows 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.\n\n## DSE recommendation: production-safe operational steps\n\n- Confirm tenant subscriptions, Entra and Intune entitlements, Autopatch feature coverage, and support rights with current Microsoft product terms.\n\n- Export device edition, version, architecture, channel, ownership, join state, Intune enrollment, last check-in, management authority, co-management workloads, and existing update policies.\n\n- Identify unsupported BYOD, Configuration Manager-only, stale, LTSC, end-of-support, virtual, kiosk, or specialized devices and define a separate servicing plan.\n\n- Validate required Microsoft endpoints through the real proxy, firewall, VPN, DNS, TLS inspection, and branch paths. Record the test and exception owner.\n\n- Obtain the required privacy and security approval for diagnostic data and document what features change if the required level is unavailable.\n\n- Reconcile WSUS, scan-source, update-ring, feature, quality, driver, firmware, and Configuration Manager settings before registration.\n\n- Register a representative pilot, review readiness and update reports, validate business applications and recovery, and expand only after defined exit criteria pass.\n\nDSE 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.\n\n## Official reference\n\n[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." } ] }