{ "api_version": "1", "kind": "dse_post_collection", "self": "https://update.dsesecurity.com/api/v1/posts/?topic=networks-infrastructure", "home_page_url": "https://update.dsesecurity.com/", "total_items": 30, "total_pages": 2, "page": 1, "per_page": 20, "filters": { "q": null, "topic": "networks-infrastructure", "format": null, "priority": null, "sort": "stream", "effective_sort": "stream" }, "links": { "self": "https://update.dsesecurity.com/api/v1/posts/?topic=networks-infrastructure", "next": "https://update.dsesecurity.com/api/v1/posts/?topic=networks-infrastructure&page=2" }, "items": [ { "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": "

Physical access control is within NIST’s OT scope

\n

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.

\n

The 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\n

Segment from documented flows

\n

NIST 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.

\n

Remote 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\n

Current-publication boundary

\n

Rev. 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\n

DSE architecture checklist

\n

DSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.

\n
    \n
  1. Inventory readers, controllers, servers, workstations, directories, databases, switches, cloud services, and vendor paths.
    2. \n
  2. Assign owners and criticality, including the consequence of each component or dependency being unavailable.
    3. \n
  3. Document normal, emergency, offline, update, backup, monitoring, and support data flows.
    4. \n
  4. Create zones and enforcement rules from those flows; do not rely on a VLAN name as proof of isolation.
    5. \n
  5. Remove unjustified remote paths and make required sessions named, approved, limited, monitored, and time-bound.
    6. \n
  6. Use strong authentication and encryption where supported, with compensating controls documented for legacy limitations.
    7. \n
  7. Test controller autonomy, door operation, alarms, audit, emergency workflows, remote-access disablement, and recovery.
    8. \n
  8. Review the architecture after integration, cloud, identity, site, or vendor-support changes.
    9. \n
\n\n

Official references

\n", "content_text": "Physical access control is within NIST’s OT scope\nSource 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\nSegment from documented flows\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\nCurrent-publication boundary\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 architecture checklist\nDSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.\n\nInventory readers, controllers, servers, workstations, directories, databases, switches, cloud services, and vendor paths.\nAssign owners and criticality, including the consequence of each component or dependency being unavailable.\nDocument normal, emergency, offline, update, backup, monitoring, and support data flows.\nCreate zones and enforcement rules from those flows; do not rely on a VLAN name as proof of isolation.\nRemove unjustified remote paths and make required sessions named, approved, limited, monitored, and time-bound.\nUse strong authentication and encryption where supported, with compensating controls documented for legacy limitations.\nTest controller autonomy, door operation, alarms, audit, emergency workflows, remote-access disablement, and recovery.\nReview the architecture after integration, cloud, identity, site, or vendor-support changes.\n\nOfficial references\n\nNIST SP 800-82 Rev. 3 — the current final OT scope and security guidance.\nGuide to Operational Technology Security — PACS architecture, availability, segmentation, and remote-access details.\nNIST Operational Technology Security publications — current final and draft status tracking.", "content_markdown": "## Physical access control is within NIST’s OT scope\n\nSource 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.\n\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\n## Segment from documented flows\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.\n\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\n## Current-publication boundary\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\n## DSE architecture checklist\n\nDSE recommendation: This is DSE operational synthesis and must be reconciled with product, facility, egress, and emergency requirements.\n\n- Inventory readers, controllers, servers, workstations, directories, databases, switches, cloud services, and vendor paths.\n\n- Assign owners and criticality, including the consequence of each component or dependency being unavailable.\n\n- Document normal, emergency, offline, update, backup, monitoring, and support data flows.\n\n- Create zones and enforcement rules from those flows; do not rely on a VLAN name as proof of isolation.\n\n- Remove unjustified remote paths and make required sessions named, approved, limited, monitored, and time-bound.\n\n- Use strong authentication and encryption where supported, with compensating controls documented for legacy limitations.\n\n- Test controller autonomy, door operation, alarms, audit, emergency workflows, remote-access disablement, and recovery.\n\n- Review the architecture after integration, cloud, identity, site, or vendor-support changes.\n\n## Official references\n\n- [NIST SP 800-82 Rev. 3](https://csrc.nist.gov/pubs/sp/800/82/r3/final) — the current final OT scope and security guidance.\n\n- [Guide to Operational Technology Security](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf) — PACS architecture, availability, segmentation, and remote-access details.\n\n- [NIST Operational Technology Security publications](https://csrc.nist.gov/projects/operational-technology-security/publications) — current final and draft status tracking." }, { "id": "https://update.dsesecurity.com/updates/physical-security-ot-backup-restore-testing/", "slug": "physical-security-ot-backup-restore-testing", "url": "https://update.dsesecurity.com/updates/physical-security-ot-backup-restore-testing/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/physical-security-ot-backup-restore-testing.md", "json": "https://update.dsesecurity.com/api/v1/posts/physical-security-ot-backup-restore-testing/" }, "title": "Back up physical-security controllers like OT: configurations, tools, licenses, spares, and restore tests", "summary": "NIST SP 1339 treats OT recovery as more than copying configuration files: tools, licenses, compatible spares, documentation, integrity, and restore tests all matter.", "format": { "slug": "checklist", "name": "Checklist" }, "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": 3, "word_count": 468, "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.", "primary_source": { "name": "NIST SP 1339 — OT Backup Quick Start Guide", "url": "https://csrc.nist.gov/pubs/sp/1339/final", "published_on": "2026-06-17", "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": "

Recovery starts with inventory

\n

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.

\n

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.

\n\n

Protect useful, restorable copies

\n

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.

\n

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.

\n

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.

\n\n

Applicability boundary

\n

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.

\n\n

DSE recovery checklist

\n

DSE recommendation: This checklist is DSE operational synthesis from SP 1339; apply it only where the physical-security system’s operational characteristics fit.

\n
    \n
  1. Identify every component that holds configuration or is required to rebuild the service.
    2. \n
  2. Set recovery order, frequency, retention, and copy locations from criticality and change rate.
    3. \n
  3. Export after approved changes and retain exact firmware, installers, licenses, utilities, cables, keys, and manuals.
    4. \n
  4. Maintain protected onsite and offsite copies with inventory labels and integrity records.
    5. \n
  5. Keep compatible, tested spares for components whose replacement lead time exceeds the recovery objective.
    6. \n
  6. Restore onto nonproduction or spare equipment and test communications, doors, events, time, users, and monitoring.
    7. \n
  7. Verify hashes and compare restored configuration using supported native tools.
    8. \n
  8. Update runbooks, diagrams, inventories, and backup scope after each exercise or material change.
    9. \n
\n\n

Official references

\n", "content_text": "Recovery starts with inventory\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\nProtect useful, restorable copies\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\nApplicability boundary\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 recovery checklist\nDSE recommendation: This checklist is DSE operational synthesis from SP 1339; apply it only where the physical-security system’s operational characteristics fit.\n\nIdentify every component that holds configuration or is required to rebuild the service.\nSet recovery order, frequency, retention, and copy locations from criticality and change rate.\nExport after approved changes and retain exact firmware, installers, licenses, utilities, cables, keys, and manuals.\nMaintain protected onsite and offsite copies with inventory labels and integrity records.\nKeep compatible, tested spares for components whose replacement lead time exceeds the recovery objective.\nRestore onto nonproduction or spare equipment and test communications, doors, events, time, users, and monitoring.\nVerify hashes and compare restored configuration using supported native tools.\nUpdate runbooks, diagrams, inventories, and backup scope after each exercise or material change.\n\nOfficial references\n\nNIST SP 1339 publication record — the official CSRC status, publication details, and download page.\nNIST SP 1339: OT Backup Quick Start Guide — the June 17, 2026 inventory, backup, dependency, integrity, restoration, and documentation guidance.", "content_markdown": "## Recovery starts with inventory\n\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.\n\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\n## Protect useful, restorable copies\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.\n\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.\n\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\n## Applicability boundary\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\n## DSE recovery checklist\n\nDSE recommendation: This checklist is DSE operational synthesis from SP 1339; apply it only where the physical-security system’s operational characteristics fit.\n\n- Identify every component that holds configuration or is required to rebuild the service.\n\n- Set recovery order, frequency, retention, and copy locations from criticality and change rate.\n\n- Export after approved changes and retain exact firmware, installers, licenses, utilities, cables, keys, and manuals.\n\n- Maintain protected onsite and offsite copies with inventory labels and integrity records.\n\n- Keep compatible, tested spares for components whose replacement lead time exceeds the recovery objective.\n\n- Restore onto nonproduction or spare equipment and test communications, doors, events, time, users, and monitoring.\n\n- Verify hashes and compare restored configuration using supported native tools.\n\n- Update runbooks, diagrams, inventories, and backup scope after each exercise or material change.\n\n## Official references\n\n- [NIST SP 1339 publication record](https://csrc.nist.gov/pubs/sp/1339/final) — the official CSRC status, publication details, and download page.\n\n- [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." }, { "id": "https://update.dsesecurity.com/updates/onvif-profile-g-edge-recording-acceptance-testing/", "slug": "onvif-profile-g-edge-recording-acceptance-testing", "url": "https://update.dsesecurity.com/updates/onvif-profile-g-edge-recording-acceptance-testing/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/onvif-profile-g-edge-recording-acceptance-testing.md", "json": "https://update.dsesecurity.com/api/v1/posts/onvif-profile-g-edge-recording-acceptance-testing/" }, "title": "ONVIF Profile G acceptance testing for edge recording and retrieval", "summary": "Profile G standardizes important recording and retrieval interfaces, but a resilient edge-recording design still needs capacity, outage, recovery, and evidence tests.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "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:39+00:00", "modified_at": "2026-07-19T21:28:39+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 435, "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.", "primary_source": { "name": "ONVIF — Profile G", "url": "https://www.onvif.org/profiles/profile-g/", "published_on": null, "authority": "ONVIF" }, "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": "

What Profile G covers

\n

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.

\n

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.

\n

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.

\n\n

Define the recovery use case

\n

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.

\n

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.

\n\n

DSE acceptance checklist

\n

DSE recommendation: This checklist is DSE operational synthesis; ONVIF does not prescribe this site-test sequence.

\n
    \n
  1. Verify the exact device and client versions in ONVIF’s registry and retain their feature documents.
    2. \n
  2. Confirm supported media, health monitoring, usable capacity, overwrite behavior, and time synchronization from current manufacturer guidance.
    3. \n
  3. Create known recordings and prove search, retrieval, playback, timestamps, and export from the client.
    4. \n
  4. Where required, confirm that audio and metadata survive the complete recording and retrieval path.
    5. \n
  5. Simulate an approved network interruption, keep it within the designed duration, and document device behavior.
    6. \n
  6. Restore connectivity and verify discovery, backlog availability, chronology, duplicates, gaps, and VMS reconciliation.
    7. \n
  7. Test full, removed, failed, or replaced media using safe procedures supported by the manufacturer.
    8. \n
  8. Record the tested limits and schedule periodic health and retrieval checks.
    9. \n
\n\n

Official references

\n", "content_text": "What Profile G covers\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\nDefine the recovery use case\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 acceptance checklist\nDSE recommendation: This checklist is DSE operational synthesis; ONVIF does not prescribe this site-test sequence.\n\nVerify the exact device and client versions in ONVIF’s registry and retain their feature documents.\nConfirm supported media, health monitoring, usable capacity, overwrite behavior, and time synchronization from current manufacturer guidance.\nCreate known recordings and prove search, retrieval, playback, timestamps, and export from the client.\nWhere required, confirm that audio and metadata survive the complete recording and retrieval path.\nSimulate an approved network interruption, keep it within the designed duration, and document device behavior.\nRestore connectivity and verify discovery, backlog availability, chronology, duplicates, gaps, and VMS reconciliation.\nTest full, removed, failed, or replaced media using safe procedures supported by the manufacturer.\nRecord the tested limits and schedule periodic health and retrieval checks.\n\nOfficial references\n\nProfile G — current device, client, recording, audio, and metadata scope.\nONVIF Releases Profile G for Video Storage and Recording — the July 2, 2014 storage, search, retrieval, and playback release scope.\nConformant Products — exact product and version verification.", "content_markdown": "## What Profile G covers\n\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.\n\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.\n\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\n## Define the recovery use case\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.\n\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\n## DSE acceptance checklist\n\nDSE recommendation: This checklist is DSE operational synthesis; ONVIF does not prescribe this site-test sequence.\n\n- Verify the exact device and client versions in ONVIF’s registry and retain their feature documents.\n\n- Confirm supported media, health monitoring, usable capacity, overwrite behavior, and time synchronization from current manufacturer guidance.\n\n- Create known recordings and prove search, retrieval, playback, timestamps, and export from the client.\n\n- Where required, confirm that audio and metadata survive the complete recording and retrieval path.\n\n- Simulate an approved network interruption, keep it within the designed duration, and document device behavior.\n\n- Restore connectivity and verify discovery, backlog availability, chronology, duplicates, gaps, and VMS reconciliation.\n\n- Test full, removed, failed, or replaced media using safe procedures supported by the manufacturer.\n\n- Record the tested limits and schedule periodic health and retrieval checks.\n\n## Official references\n\n- [Profile G](https://www.onvif.org/profiles/profile-g/) — current device, client, recording, audio, and metadata scope.\n\n- [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.\n\n- [Conformant Products](https://www.onvif.org/conformant-products/) — exact product and version verification." }, { "id": "https://update.dsesecurity.com/updates/onvif-profile-m-analytics-metadata-boundaries/", "slug": "onvif-profile-m-analytics-metadata-boundaries", "url": "https://update.dsesecurity.com/updates/onvif-profile-m-analytics-metadata-boundaries/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/onvif-profile-m-analytics-metadata-boundaries.md", "json": "https://update.dsesecurity.com/api/v1/posts/onvif-profile-m-analytics-metadata-boundaries/" }, "title": "ONVIF Profile M: what analytics metadata interoperability does—and does not—prove", "summary": "Profile M standardizes analytics metadata and events between products. It does not certify analytic accuracy, lawful use, model quality, or every conditional feature.", "format": { "slug": "explainer", "name": "Explainer" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "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:39+00:00", "modified_at": "2026-07-19T21:28:39+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 425, "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.", "primary_source": { "name": "ONVIF — Profile M", "url": "https://www.onvif.org/profiles/profile-m/", "published_on": null, "authority": "ONVIF" }, "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": "

What Profile M standardizes

\n

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.

\n

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.

\n

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.

\n\n

What conformance does not measure

\n

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.

\n

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.

\n\n

DSE evaluation checklist

\n

DSE recommendation: The following is DSE operational synthesis, not an ONVIF accuracy or privacy standard.

\n
    \n
  1. Write the security or operational use case before selecting object classes or events.
    2. \n
  2. List required fields, event transports, images, rules, timestamps, identifiers, and downstream actions.
    3. \n
  3. Verify the exact Profile M record and feature documents for every producer and consumer.
    4. \n
  4. Bench-test configuration, filtering, event delivery, metadata preservation, time alignment, reconnect behavior, and search.
    5. \n
  5. Measure false positives and false negatives with representative site conditions; do not infer accuracy from conformance.
    6. \n
  6. Complete a privacy assessment covering purpose, notice, access, retention, sharing, and any biometric or identifying data.
    7. \n
  7. Require human review and a safe failure path before metadata triggers a consequential physical or business action.
    8. \n
  8. Retest after model, camera, VMS, rule, or firmware changes.
    9. \n
\n\n

Official references

\n", "content_text": "What Profile M standardizes\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\nWhat conformance does not measure\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 evaluation checklist\nDSE recommendation: The following is DSE operational synthesis, not an ONVIF accuracy or privacy standard.\n\nWrite the security or operational use case before selecting object classes or events.\nList required fields, event transports, images, rules, timestamps, identifiers, and downstream actions.\nVerify the exact Profile M record and feature documents for every producer and consumer.\nBench-test configuration, filtering, event delivery, metadata preservation, time alignment, reconnect behavior, and search.\nMeasure false positives and false negatives with representative site conditions; do not infer accuracy from conformance.\nComplete a privacy assessment covering purpose, notice, access, retention, sharing, and any biometric or identifying data.\nRequire human review and a safe failure path before metadata triggers a consequential physical or business action.\nRetest after model, camera, VMS, rule, or firmware changes.\n\nOfficial references\n\nProfile M — current feature, producer, client, event, and conditional-capability scope.\nONVIF announces the release of Profile M — the June 30, 2021 release and interoperability use cases.\nConformant Products — authoritative model and version verification.", "content_markdown": "## What Profile M standardizes\n\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.\n\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.\n\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\n## What conformance does not measure\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.\n\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\n## DSE evaluation checklist\n\nDSE recommendation: The following is DSE operational synthesis, not an ONVIF accuracy or privacy standard.\n\n- Write the security or operational use case before selecting object classes or events.\n\n- List required fields, event transports, images, rules, timestamps, identifiers, and downstream actions.\n\n- Verify the exact Profile M record and feature documents for every producer and consumer.\n\n- Bench-test configuration, filtering, event delivery, metadata preservation, time alignment, reconnect behavior, and search.\n\n- Measure false positives and false negatives with representative site conditions; do not infer accuracy from conformance.\n\n- Complete a privacy assessment covering purpose, notice, access, retention, sharing, and any biometric or identifying data.\n\n- Require human review and a safe failure path before metadata triggers a consequential physical or business action.\n\n- Retest after model, camera, VMS, rule, or firmware changes.\n\n## Official references\n\n- [Profile M](https://www.onvif.org/profiles/profile-m/) — current feature, producer, client, event, and conditional-capability scope.\n\n- [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.\n\n- [Conformant Products](https://www.onvif.org/conformant-products/) — authoritative model and version verification." }, { "id": "https://update.dsesecurity.com/updates/onvif-tls-configuration-addon-v1-transition/", "slug": "onvif-tls-configuration-addon-v1-transition", "url": "https://update.dsesecurity.com/updates/onvif-tls-configuration-addon-v1-transition/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/onvif-tls-configuration-addon-v1-transition.md", "json": "https://update.dsesecurity.com/api/v1/posts/onvif-tls-configuration-addon-v1-transition/" }, "title": "ONVIF TLS Configuration Add-on v1.0: manage the transition without guessing", "summary": "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.", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "topics": [ { "slug": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" }, { "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/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "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:39+00:00", "modified_at": "2026-07-19T21:28:39+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 394, "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.", "primary_source": { "name": "ONVIF — TLS Configuration Add-on", "url": "https://www.onvif.org/add-on/tls-configuration-add-on/", "published_on": null, "authority": "ONVIF" }, "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": "

What version 1.0 establishes

\n

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.

\n

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.

\n

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.

\n\n

What the add-on does not prove

\n

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.

\n

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.

\n\n

DSE transition checklist

\n

DSE recommendation: This is DSE operational synthesis. It does not predict the content or release date of version 2.0.

\n
    \n
  1. Inventory each client and device, exact firmware or software, claimed add-on version, and official database record.
    2. \n
  2. Map which control, event, configuration, and media paths actually use TLS and which do not.
    3. \n
  3. Record certificate issuer, subject names, trust stores, expiry, renewal owner, and recovery access.
    4. \n
  4. Ask manufacturers for documented support and transition plans; separate commitments from roadmaps.
    5. \n
  5. Test initial configuration, renewal, expired or untrusted certificates, reconnect behavior, and client compatibility in a lab.
    6. \n
  6. Avoid specifying version 2.0 details until ONVIF publishes a final specification and conformant products are listed.
    7. \n
  7. Review ONVIF and manufacturer notices on a defined cadence and update the plan when evidence changes.
    8. \n
\n\n

Official references

\n", "content_text": "What version 1.0 establishes\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\nWhat the add-on does not prove\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 transition checklist\nDSE recommendation: This is DSE operational synthesis. It does not predict the content or release date of version 2.0.\n\nInventory each client and device, exact firmware or software, claimed add-on version, and official database record.\nMap which control, event, configuration, and media paths actually use TLS and which do not.\nRecord certificate issuer, subject names, trust stores, expiry, renewal owner, and recovery access.\nAsk manufacturers for documented support and transition plans; separate commitments from roadmaps.\nTest initial configuration, renewal, expired or untrusted certificates, reconnect behavior, and client compatibility in a lab.\nAvoid specifying version 2.0 details until ONVIF publishes a final specification and conformant products are listed.\nReview ONVIF and manufacturer notices on a defined cadence and update the plan when evidence changes.\n\nOfficial references\n\nTLS Configuration Add-on — current purpose and lifecycle notice.\nTLS Configuration Add-on Specification v1.0 — December 2023 requirements.\nConformant Products — authoritative product, version, profile, and add-on claims.", "content_markdown": "## What version 1.0 establishes\n\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.\n\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.\n\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\n## What the add-on does not prove\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.\n\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\n## DSE transition checklist\n\nDSE recommendation: This is DSE operational synthesis. It does not predict the content or release date of version 2.0.\n\n- Inventory each client and device, exact firmware or software, claimed add-on version, and official database record.\n\n- Map which control, event, configuration, and media paths actually use TLS and which do not.\n\n- Record certificate issuer, subject names, trust stores, expiry, renewal owner, and recovery access.\n\n- Ask manufacturers for documented support and transition plans; separate commitments from roadmaps.\n\n- Test initial configuration, renewal, expired or untrusted certificates, reconnect behavior, and client compatibility in a lab.\n\n- Avoid specifying version 2.0 details until ONVIF publishes a final specification and conformant products are listed.\n\n- Review ONVIF and manufacturer notices on a defined cadence and update the plan when evidence changes.\n\n## Official references\n\n- [TLS Configuration Add-on](https://www.onvif.org/add-on/tls-configuration-add-on/) — current purpose and lifecycle notice.\n\n- [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.\n\n- [Conformant Products](https://www.onvif.org/conformant-products/) — authoritative product, version, profile, and add-on claims." }, { "id": "https://update.dsesecurity.com/updates/onvif-profile-d-access-peripheral-decision-boundaries/", "slug": "onvif-profile-d-access-peripheral-decision-boundaries", "url": "https://update.dsesecurity.com/updates/onvif-profile-d-access-peripheral-decision-boundaries/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/onvif-profile-d-access-peripheral-decision-boundaries.md", "json": "https://update.dsesecurity.com/api/v1/posts/onvif-profile-d-access-peripheral-decision-boundaries/" }, "title": "ONVIF Profile D: keep access decisions in the right place when integrating peripherals", "summary": "Profile D standardizes communication between access peripherals and a securely located client. It does not certify the complete door, credential, or life-safety design.", "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": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "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:39+00:00", "modified_at": "2026-07-19T21:28:39+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 432, "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.", "primary_source": { "name": "ONVIF — Profile D", "url": "https://www.onvif.org/profiles/profile-d/", "published_on": null, "authority": "ONVIF" }, "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": "

What Profile D connects

\n

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.

\n

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.

\n

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.

\n\n

Where the profile stops

\n

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.

\n

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.

\n\n

DSE integration checklist

\n

DSE recommendation: This is DSE operational synthesis, not an ONVIF door-hardware or code-compliance procedure.

\n
    \n
  1. Diagram each peripheral, securely located client, controller, server, door, network path, and stored-data location.
    2. \n
  2. Identify which component captures an identifier, stores rules, makes the decision, and operates the output.
    3. \n
  3. Verify exact Profile D records and feature documents for both client and device.
    4. \n
  4. Test valid, invalid, expired, blocked, and unknown credentials plus any PIN or second-input workflow.
    5. \n
  5. Test loss and restoration of the client or network, including documented offline behavior.
    6. \n
  6. Verify lock, sensor, message, audit, and video association functions required by the design.
    7. \n
  7. Validate power, wiring, egress, fire alarm, accessibility, and life-safety behavior through the appropriate qualified process.
    8. \n
  8. Retain the tested versions, results, exceptions, and recovery steps with commissioning records.
    9. \n
\n\n

Official references

\n", "content_text": "What Profile D connects\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\nWhere the profile stops\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 integration checklist\nDSE recommendation: This is DSE operational synthesis, not an ONVIF door-hardware or code-compliance procedure.\n\nDiagram each peripheral, securely located client, controller, server, door, network path, and stored-data location.\nIdentify which component captures an identifier, stores rules, makes the decision, and operates the output.\nVerify exact Profile D records and feature documents for both client and device.\nTest valid, invalid, expired, blocked, and unknown credentials plus any PIN or second-input workflow.\nTest loss and restoration of the client or network, including documented offline behavior.\nVerify lock, sensor, message, audit, and video association functions required by the design.\nValidate power, wiring, egress, fire alarm, accessibility, and life-safety behavior through the appropriate qualified process.\nRetain the tested versions, results, exceptions, and recovery steps with commissioning records.\n\nOfficial references\n\nProfile D — current peripheral, client, decision, and configuration scope.\nONVIF Releases Profile D for Access Control Peripherals — the July 14, 2021 release and architecture examples.\nConformant Products — exact model, version, and profile verification.", "content_markdown": "## What Profile D connects\n\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.\n\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.\n\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\n## Where the profile stops\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.\n\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\n## DSE integration checklist\n\nDSE recommendation: This is DSE operational synthesis, not an ONVIF door-hardware or code-compliance procedure.\n\n- Diagram each peripheral, securely located client, controller, server, door, network path, and stored-data location.\n\n- Identify which component captures an identifier, stores rules, makes the decision, and operates the output.\n\n- Verify exact Profile D records and feature documents for both client and device.\n\n- Test valid, invalid, expired, blocked, and unknown credentials plus any PIN or second-input workflow.\n\n- Test loss and restoration of the client or network, including documented offline behavior.\n\n- Verify lock, sensor, message, audit, and video association functions required by the design.\n\n- Validate power, wiring, egress, fire alarm, accessibility, and life-safety behavior through the appropriate qualified process.\n\n- Retain the tested versions, results, exceptions, and recovery steps with commissioning records.\n\n## Official references\n\n- [Profile D](https://www.onvif.org/profiles/profile-d/) — current peripheral, client, decision, and configuration scope.\n\n- [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.\n\n- [Conformant Products](https://www.onvif.org/conformant-products/) — exact model, version, and profile verification." }, { "id": "https://update.dsesecurity.com/updates/axis-camera-certificate-lifecycle-https-8021x/", "slug": "axis-camera-certificate-lifecycle-https-8021x", "url": "https://update.dsesecurity.com/updates/axis-camera-certificate-lifecycle-https-8021x/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/axis-camera-certificate-lifecycle-https-8021x.md", "json": "https://update.dsesecurity.com/api/v1/posts/axis-camera-certificate-lifecycle-https-8021x/" }, "title": "Camera certificate lifecycle management: HTTPS and 802.1X are different jobs", "summary": "Axis documents distinct certificate roles for HTTPS server identity and 802.1X network authentication. Each needs ownership, expiry monitoring, renewal, and recovery testing.", "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": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "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:39+00:00", "modified_at": "2026-07-19T21:28:39+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 417, "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.", "primary_source": { "name": "Axis Communications — AXIS Device Manager Security Guide", "url": "https://help.axis.com/en-us/adm-security-guide", "published_on": null, "authority": "Axis Communications" }, "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": "

Two certificate purposes

\n

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.

\n

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.

\n

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.

\n\n

Architecture determines the CA choice

\n

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.

\n

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.

\n\n

DSE lifecycle checklist

\n

DSE recommendation: This is DSE operational synthesis for Axis environments, not a universal PKI design.

\n
    \n
  1. Inventory every certificate by device, purpose, issuer, subject, serial number, expiry, key location, and renewal owner.
    2. \n
  2. Separate HTTPS server identity from 802.1X client authentication and any MQTT or syslog certificates.
    3. \n
  3. Map which VMS, browser, management client, RADIUS server, and switch trusts which CA.
    4. \n
  4. Protect CA private keys and backups according to the organization’s approved key-management process.
    5. \n
  5. Set warnings early enough to investigate and stage renewal before expiration.
    6. \n
  6. Test representative certificate issuance, installation, trust, 802.1X admission, VMS recording, and direct maintenance access.
    7. \n
  7. Test expired, revoked, untrusted, or failed-renewal behavior and document an authorized recovery path.
    8. \n
  8. Review the inventory after device replacement, CA change, network redesign, or VMS migration.
    9. \n
\n\n

Official references

\n", "content_text": "Two certificate purposes\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\nArchitecture determines the CA choice\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 lifecycle checklist\nDSE recommendation: This is DSE operational synthesis for Axis environments, not a universal PKI design.\n\nInventory every certificate by device, purpose, issuer, subject, serial number, expiry, key location, and renewal owner.\nSeparate HTTPS server identity from 802.1X client authentication and any MQTT or syslog certificates.\nMap which VMS, browser, management client, RADIUS server, and switch trusts which CA.\nProtect CA private keys and backups according to the organization’s approved key-management process.\nSet warnings early enough to investigate and stage renewal before expiration.\nTest representative certificate issuance, installation, trust, 802.1X admission, VMS recording, and direct maintenance access.\nTest expired, revoked, untrusted, or failed-renewal behavior and document an authorized recovery path.\nReview the inventory after device replacement, CA change, network redesign, or VMS migration.\n\nOfficial references\n\nAXIS Device Manager Security Guide — certificate lifecycle, HTTPS, 802.1X, CA, RADIUS, and trust guidance.\nAXIS OS Knowledge Base — current device certificate behavior and version-specific administration context.", "content_markdown": "## Two certificate purposes\n\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.\n\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.\n\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\n## Architecture determines the CA choice\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.\n\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\n## DSE lifecycle checklist\n\nDSE recommendation: This is DSE operational synthesis for Axis environments, not a universal PKI design.\n\n- Inventory every certificate by device, purpose, issuer, subject, serial number, expiry, key location, and renewal owner.\n\n- Separate HTTPS server identity from 802.1X client authentication and any MQTT or syslog certificates.\n\n- Map which VMS, browser, management client, RADIUS server, and switch trusts which CA.\n\n- Protect CA private keys and backups according to the organization’s approved key-management process.\n\n- Set warnings early enough to investigate and stage renewal before expiration.\n\n- Test representative certificate issuance, installation, trust, 802.1X admission, VMS recording, and direct maintenance access.\n\n- Test expired, revoked, untrusted, or failed-renewal behavior and document an authorized recovery path.\n\n- Review the inventory after device replacement, CA change, network redesign, or VMS migration.\n\n## Official references\n\n- [AXIS Device Manager Security Guide](https://help.axis.com/en-us/adm-security-guide) — certificate lifecycle, HTTPS, 802.1X, CA, RADIUS, and trust guidance.\n\n- [AXIS OS Knowledge Base](https://help.axis.com/en-US/axis-os-knowledge-base) — current device certificate behavior and version-specific administration context." }, { "id": "https://update.dsesecurity.com/updates/onvif-profile-s-support-end-profile-t-migration/", "slug": "onvif-profile-s-support-end-profile-t-migration", "url": "https://update.dsesecurity.com/updates/onvif-profile-s-support-end-profile-t-migration/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/onvif-profile-s-support-end-profile-t-migration.md", "json": "https://update.dsesecurity.com/api/v1/posts/onvif-profile-s-support-end-profile-t-migration/" }, "title": "ONVIF Profile S support ends March 31, 2027: plan a tested move to Profile T", "summary": "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.", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" }, { "slug": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "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": 436, "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.", "primary_source": { "name": "ONVIF — Profile S Deprecation Q&A", "url": "https://www.onvif.org/profiles/profile-s/profile-s-deprecation-qna/", "published_on": null, "authority": "ONVIF" }, "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": "

What ONVIF has announced

\n

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.

\n

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.

\n

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.

\n\n

Compatibility boundaries

\n

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.

\n\n

DSE operational checklist

\n

DSE recommendation: The following is DSE operational synthesis based on the ONVIF material, not an ONVIF-mandated migration sequence.

\n
    \n
  1. Inventory devices and clients that are Profile S only, dual Profile S/Profile T, or not found in the official database.
    2. \n
  2. Record exact firmware, software, authentication method, codecs, and any IP-filter or legacy-stream dependency.
    3. \n
  3. Verify each exact version in the ONVIF Conformant Products database and retain its feature list.
    4. \n
  4. Ask manufacturers which supported release and authentication path they recommend after Profile S support ends.
    5. \n
  5. Bench-test digest authentication, HTTPS, live and recorded video, PTZ, audio, metadata, events, analytics, and export.
    6. \n
  6. Stage production changes in coverage-aware groups with a documented recovery path.
    7. \n
  7. Assign an owner and replacement date to any dependency that cannot move safely.
    8. \n
\n\n

Official references

\n", "content_text": "What ONVIF has announced\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\nCompatibility boundaries\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 operational checklist\nDSE recommendation: The following is DSE operational synthesis based on the ONVIF material, not an ONVIF-mandated migration sequence.\n\nInventory devices and clients that are Profile S only, dual Profile S/Profile T, or not found in the official database.\nRecord exact firmware, software, authentication method, codecs, and any IP-filter or legacy-stream dependency.\nVerify each exact version in the ONVIF Conformant Products database and retain its feature list.\nAsk manufacturers which supported release and authentication path they recommend after Profile S support ends.\nBench-test digest authentication, HTTPS, live and recorded video, PTZ, audio, metadata, events, analytics, and export.\nStage production changes in coverage-aware groups with a documented recovery path.\nAssign an owner and replacement date to any dependency that cannot move safely.\n\nOfficial references\n\nProfile S Deprecation Q&A — the March 31, 2027 date, continuing-use boundary, authentication guidance, and feature comparison.\nONVIF to End Support for Profile S; Recommends Profile T as Replacement — the October 9, 2025 announcement and conformance-tool timeline.\nProfile T — the current official Profile T capability summary.", "content_markdown": "## What ONVIF has announced\n\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.\n\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.\n\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\n## Compatibility boundaries\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\n## DSE operational checklist\n\nDSE recommendation: The following is DSE operational synthesis based on the ONVIF material, not an ONVIF-mandated migration sequence.\n\n- Inventory devices and clients that are Profile S only, dual Profile S/Profile T, or not found in the official database.\n\n- Record exact firmware, software, authentication method, codecs, and any IP-filter or legacy-stream dependency.\n\n- Verify each exact version in the ONVIF Conformant Products database and retain its feature list.\n\n- Ask manufacturers which supported release and authentication path they recommend after Profile S support ends.\n\n- Bench-test digest authentication, HTTPS, live and recorded video, PTZ, audio, metadata, events, analytics, and export.\n\n- Stage production changes in coverage-aware groups with a documented recovery path.\n\n- Assign an owner and replacement date to any dependency that cannot move safely.\n\n## Official references\n\n- [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.\n\n- [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.\n\n- [Profile T](https://www.onvif.org/profiles/profile-t/) — the current official Profile T capability summary." }, { "id": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/", "slug": "secure-rmm-remote-access-software", "url": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/secure-rmm-remote-access-software.md", "json": "https://update.dsesecurity.com/api/v1/posts/secure-rmm-remote-access-software/" }, "title": "Secure RMM and remote-access software before attackers use it", "summary": "Remote monitoring and access tools need explicit authorization, strong identity controls, restricted paths, independent logging, provider accountability, and tested containment.", "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": "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:27:10+00:00", "modified_at": "2026-07-19T21:27:10+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 446, "potentially_affected": "Organizations, MSP customers, SaaS customers, IT administrators, service providers, and software teams that deploy or permit remote administration and support tools.", "dse_recommendation": "Inventory and allowlist tools, remove unauthorized access, harden approved paths, keep logs outside RMM control, define provider obligations, and exercise revocation and containment.", "primary_source": { "name": "CISA and partners: Guide to Securing Remote Access Software", "url": "https://www.cisa.gov/resources-tools/resources/guide-securing-remote-access-software", "published_on": "2023-06-06", "authority": "Cybersecurity and Infrastructure Security Agency" }, "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": "
\n

Remote monitoring and access software is valuable because it can reach many systems with administrative capability. The same reach makes an unmanaged tool, stolen operator identity, unsafe configuration, or compromised provider path consequential.

\n\n

What the joint guide establishes

\n

Source fact: CISA, NSA, FBI, MS-ISAC, and Israel’s National Cyber Directorate explain that remote-access software supports legitimate administration of IT, operational-technology, and industrial-control environments, while malicious actors increasingly co-opt the same tools to access victim systems.

\n

Source fact: The guide provides detection and mitigation recommendations for all organizations, MSP and SaaS customers, MSPs and IT administrators, and developers. It recommends effective monitoring and logging, clear contractual responsibilities, and visibility into provider presence, activities, and connections to customer networks.

\n

The agencies specifically advise keeping direct access to log servers—and the ability to alter or delete logs—out of reach of remote-management tools. They also caution that controls such as a web application firewall can disrupt legitimate remote access and should be tested before production deployment.

\n\n

Establish an authorized remote-access inventory

\n

DSE recommendation: identify approved and discovered tools, browser extensions, built-in services, agents, gateways, cloud consoles, and unattended-access configurations. For each, record the owner, purpose, version, privileges, identity source, reachable assets, exposed interfaces, update method, logging, provider, and emergency use.

\n
    \n
  1. Remove or block unapproved tools through a controlled change, after confirming they are not supporting an undocumented essential workflow.
    2. \n
  2. Restrict approved tools to managed identities, supported versions, hardened configuration, least privilege, and approved network paths.
    3. \n
  3. Require strong authentication and protect administrator workstations, enrollment, recovery, API keys, service identities, and unattended credentials.
    4. \n
  4. Centralize remote-session, identity, configuration, and administrative events in a system the remote tool cannot modify.
    5. \n
  5. Alert on new tools, unexpected installation, unusual execution, disabled controls, new operators, changed policies, and connections outside approved patterns.
    6. \n
\n\n

Make the provider boundary explicit

\n

DSE recommendation: document which security functions a provider performs, which remain with the customer, what telemetry the customer can access, how provider accounts are reviewed, and how quickly suspected or confirmed incidents are communicated. Include revocation, evidence preservation, cooperation, data return, and exit expectations where appropriate.

\n

Exercise disabling an operator, revoking the tool, isolating affected systems, preserving independent logs, contacting the provider, and restoring approved support. Validate any firewall, WAF, segmentation, or application-control change against legitimate support before enforcement.

\n\n

Applicability and limits

\n

The guide does not say all remote-access software is malicious or name one safe product. Support, safety, privacy, emergency access, architecture, and contractual needs differ. Strong controls reduce risk but cannot prove a provider, operator, or endpoint is uncompromised. Use current vendor hardening and update guidance for the selected tool.

\n\n

Official reference

\n

Guide to Securing Remote Access Software — role-specific recommendations for organizations, customers, administrators, providers, and developers.

\n
", "content_text": "Remote monitoring and access software is valuable because it can reach many systems with administrative capability. The same reach makes an unmanaged tool, stolen operator identity, unsafe configuration, or compromised provider path consequential.\n\n What the joint guide establishes\n Source fact: CISA, NSA, FBI, MS-ISAC, and Israel’s National Cyber Directorate explain that remote-access software supports legitimate administration of IT, operational-technology, and industrial-control environments, while malicious actors increasingly co-opt the same tools to access victim systems.\n Source fact: The guide provides detection and mitigation recommendations for all organizations, MSP and SaaS customers, MSPs and IT administrators, and developers. It recommends effective monitoring and logging, clear contractual responsibilities, and visibility into provider presence, activities, and connections to customer networks.\n The agencies specifically advise keeping direct access to log servers—and the ability to alter or delete logs—out of reach of remote-management tools. They also caution that controls such as a web application firewall can disrupt legitimate remote access and should be tested before production deployment.\n\n Establish an authorized remote-access inventory\n DSE recommendation: identify approved and discovered tools, browser extensions, built-in services, agents, gateways, cloud consoles, and unattended-access configurations. For each, record the owner, purpose, version, privileges, identity source, reachable assets, exposed interfaces, update method, logging, provider, and emergency use.\n \n Remove or block unapproved tools through a controlled change, after confirming they are not supporting an undocumented essential workflow.\n Restrict approved tools to managed identities, supported versions, hardened configuration, least privilege, and approved network paths.\n Require strong authentication and protect administrator workstations, enrollment, recovery, API keys, service identities, and unattended credentials.\n Centralize remote-session, identity, configuration, and administrative events in a system the remote tool cannot modify.\n Alert on new tools, unexpected installation, unusual execution, disabled controls, new operators, changed policies, and connections outside approved patterns.\n \n\n Make the provider boundary explicit\n DSE recommendation: document which security functions a provider performs, which remain with the customer, what telemetry the customer can access, how provider accounts are reviewed, and how quickly suspected or confirmed incidents are communicated. Include revocation, evidence preservation, cooperation, data return, and exit expectations where appropriate.\n Exercise disabling an operator, revoking the tool, isolating affected systems, preserving independent logs, contacting the provider, and restoring approved support. Validate any firewall, WAF, segmentation, or application-control change against legitimate support before enforcement.\n\n Applicability and limits\n The guide does not say all remote-access software is malicious or name one safe product. Support, safety, privacy, emergency access, architecture, and contractual needs differ. Strong controls reduce risk but cannot prove a provider, operator, or endpoint is uncompromised. Use current vendor hardening and update guidance for the selected tool.\n\n Official reference\n Guide to Securing Remote Access Software — role-specific recommendations for organizations, customers, administrators, providers, and developers.", "content_markdown": "Remote monitoring and access software is valuable because it can reach many systems with administrative capability. The same reach makes an unmanaged tool, stolen operator identity, unsafe configuration, or compromised provider path consequential.\n\n## What the joint guide establishes\n\nSource fact: CISA, NSA, FBI, MS-ISAC, and Israel’s National Cyber Directorate explain that remote-access software supports legitimate administration of IT, operational-technology, and industrial-control environments, while malicious actors increasingly co-opt the same tools to access victim systems.\n\nSource fact: The guide provides detection and mitigation recommendations for all organizations, MSP and SaaS customers, MSPs and IT administrators, and developers. It recommends effective monitoring and logging, clear contractual responsibilities, and visibility into provider presence, activities, and connections to customer networks.\n\nThe agencies specifically advise keeping direct access to log servers—and the ability to alter or delete logs—out of reach of remote-management tools. They also caution that controls such as a web application firewall can disrupt legitimate remote access and should be tested before production deployment.\n\n## Establish an authorized remote-access inventory\n\nDSE recommendation: identify approved and discovered tools, browser extensions, built-in services, agents, gateways, cloud consoles, and unattended-access configurations. For each, record the owner, purpose, version, privileges, identity source, reachable assets, exposed interfaces, update method, logging, provider, and emergency use.\n\n- Remove or block unapproved tools through a controlled change, after confirming they are not supporting an undocumented essential workflow.\n\n- Restrict approved tools to managed identities, supported versions, hardened configuration, least privilege, and approved network paths.\n\n- Require strong authentication and protect administrator workstations, enrollment, recovery, API keys, service identities, and unattended credentials.\n\n- Centralize remote-session, identity, configuration, and administrative events in a system the remote tool cannot modify.\n\n- Alert on new tools, unexpected installation, unusual execution, disabled controls, new operators, changed policies, and connections outside approved patterns.\n\n## Make the provider boundary explicit\n\nDSE recommendation: document which security functions a provider performs, which remain with the customer, what telemetry the customer can access, how provider accounts are reviewed, and how quickly suspected or confirmed incidents are communicated. Include revocation, evidence preservation, cooperation, data return, and exit expectations where appropriate.\n\nExercise disabling an operator, revoking the tool, isolating affected systems, preserving independent logs, contacting the provider, and restoring approved support. Validate any firewall, WAF, segmentation, or application-control change against legitimate support before enforcement.\n\n## Applicability and limits\n\nThe guide does not say all remote-access software is malicious or name one safe product. Support, safety, privacy, emergency access, architecture, and contractual needs differ. Strong controls reduce risk but cannot prove a provider, operator, or endpoint is uncompromised. Use current vendor hardening and update guidance for the selected tool.\n\n## Official reference\n\n[Guide to Securing Remote Access Software](https://www.cisa.gov/resources-tools/resources/guide-securing-remote-access-software) — role-specific recommendations for organizations, customers, administrators, providers, and developers." }, { "id": "https://update.dsesecurity.com/updates/hybrid-network-access-vpn-least-privilege/", "slug": "hybrid-network-access-vpn-least-privilege", "url": "https://update.dsesecurity.com/updates/hybrid-network-access-vpn-least-privilege/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/hybrid-network-access-vpn-least-privilege.md", "json": "https://update.dsesecurity.com/api/v1/posts/hybrid-network-access-vpn-least-privilege/" }, "title": "Reassess broad VPN access for a hybrid, least-privilege environment", "summary": "Modern network-access guidance asks organizations to examine broad remote connectivity and compare risk-based, resource-level approaches without assuming every VPN requires replacement.", "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": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:27:10+00:00", "modified_at": "2026-07-19T21:27:10+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 437, "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.", "primary_source": { "name": "CISA and partners: Modern Approaches to Network Access Security", "url": "https://www.cisa.gov/news-events/alerts/2024/06/18/cisa-and-partners-release-guidance-modern-approaches-network-access-security", "published_on": "2024-06-18", "authority": "Cybersecurity and Infrastructure Security Agency" }, "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": "
\n

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.

\n\n

What the joint guidance says

\n

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.

\n

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.

\n

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.

\n\n

Map access at the resource level

\n

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.

\n
    \n
  1. Map users, devices, partners, administrators, and services to the specific applications and transactions they require.
    2. \n
  2. Document security, privacy, data-location, latency, availability, offline, safety, support, inspection, and logging requirements.
    3. \n
  3. Compare a hardened retained VPN, resource-level zero-trust access, SSE, SASE, and hybrid combinations against those requirements.
    4. \n
  4. Define least-privilege and context-aware policy, strong authentication, device expectations, session controls, and independent telemetry.
    5. \n
  5. Preserve a tested emergency and rollback path that does not silently restore unnecessary broad access.
    6. \n
\n\n

Pilot the operating failure modes

\n

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.

\n

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.

\n\n

Applicability and limits

\n

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.

\n\n

Official reference

\n

Modern Approaches to Network Access Security — joint guidance on VPN risk and resource-focused alternatives.

\n
", "content_text": "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.\n\n What the joint guidance says\n 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.\n 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.\n 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.\n\n Map access at the resource level\n 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.\n \n Map users, devices, partners, administrators, and services to the specific applications and transactions they require.\n Document security, privacy, data-location, latency, availability, offline, safety, support, inspection, and logging requirements.\n Compare a hardened retained VPN, resource-level zero-trust access, SSE, SASE, and hybrid combinations against those requirements.\n Define least-privilege and context-aware policy, strong authentication, device expectations, session controls, and independent telemetry.\n Preserve a tested emergency and rollback path that does not silently restore unnecessary broad access.\n \n\n Pilot the operating failure modes\n 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.\n 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.\n\n Applicability and limits\n 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.\n\n Official reference\n Modern Approaches to Network Access Security — joint guidance on VPN risk and resource-focused alternatives.", "content_markdown": "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.\n\n## What the joint guidance says\n\nSource 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.\n\nSource 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.\n\nThe 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.\n\n## Map access at the resource level\n\nDSE 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.\n\n- Map users, devices, partners, administrators, and services to the specific applications and transactions they require.\n\n- Document security, privacy, data-location, latency, availability, offline, safety, support, inspection, and logging requirements.\n\n- Compare a hardened retained VPN, resource-level zero-trust access, SSE, SASE, and hybrid combinations against those requirements.\n\n- Define least-privilege and context-aware policy, strong authentication, device expectations, session controls, and independent telemetry.\n\n- Preserve a tested emergency and rollback path that does not silently restore unnecessary broad access.\n\n## Pilot the operating failure modes\n\nDSE 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.\n\nAfter 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.\n\n## Applicability and limits\n\nSSE 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.\n\n## Official reference\n\n[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." }, { "id": "https://update.dsesecurity.com/updates/network-infrastructure-isolated-management-hardening/", "slug": "network-infrastructure-isolated-management-hardening", "url": "https://update.dsesecurity.com/updates/network-infrastructure-isolated-management-hardening/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/network-infrastructure-isolated-management-hardening.md", "json": "https://update.dsesecurity.com/api/v1/posts/network-infrastructure-isolated-management-hardening/" }, "title": "Harden network infrastructure with isolated management and verifiable configuration", "summary": "Current joint guidance prioritizes centralized intended configuration, isolated management, least privilege, secure protocols, protected telemetry, integrity checks, and lifecycle maintenance.", "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": "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:27:10+00:00", "modified_at": "2026-07-19T21:27:10+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 426, "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.", "primary_source": { "name": "CISA and partners: Enhanced Visibility and Hardening Guidance for Communications Infrastructure", "url": "https://www.cisa.gov/resources-tools/resources/enhanced-visibility-and-hardening-guidance-communications-infrastructure", "published_on": "2024-12-04", "authority": "Cybersecurity and Infrastructure Security Agency" }, "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": "
\n

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.

\n\n

Visibility and hardening priorities

\n

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.

\n

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.

\n

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.

\n\n

Establish an intended and observable state

\n

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.

\n
    \n
  1. Store intended configurations in a controlled central location and compare devices against them on a defined schedule.
    2. \n
  2. Isolate management from user and production traffic and prevent unnecessary lateral device-to-device administration.
    3. \n
  3. Use centralized named administration, least privilege, strong authentication, protected AAA records, and controlled emergency accounts.
    4. \n
  4. Disable unneeded discovery, web, file-transfer, remote-shell, and management services; use secure versions supported by the vendor.
    5. \n
  5. Centralize device, authentication, configuration, and flow telemetry and alert on out-of-process changes or stopped logging.
    6. \n
  6. Verify software images using authenticated vendor information and manage routine and emergency changes with tested rollback.
    7. \n
\n\n

Validate from the outside

\n

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.

\n\n

Applicability and limits

\n

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.

\n\n

Official reference

\n

Enhanced Visibility and Hardening Guidance for Communications Infrastructure — joint network-device monitoring and hardening practices.

\n
", "content_text": "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.\n\n Visibility and hardening priorities\n 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.\n 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.\n 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.\n\n Establish an intended and observable state\n 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.\n \n Store intended configurations in a controlled central location and compare devices against them on a defined schedule.\n Isolate management from user and production traffic and prevent unnecessary lateral device-to-device administration.\n Use centralized named administration, least privilege, strong authentication, protected AAA records, and controlled emergency accounts.\n Disable unneeded discovery, web, file-transfer, remote-shell, and management services; use secure versions supported by the vendor.\n Centralize device, authentication, configuration, and flow telemetry and alert on out-of-process changes or stopped logging.\n Verify software images using authenticated vendor information and manage routine and emergency changes with tested rollback.\n \n\n Validate from the outside\n 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.\n\n Applicability and limits\n 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.\n\n Official reference\n Enhanced Visibility and Hardening Guidance for Communications Infrastructure — joint network-device monitoring and hardening practices.", "content_markdown": "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.\n\n## Visibility and hardening priorities\n\nSource 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.\n\nSource 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.\n\nSource 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.\n\n## Establish an intended and observable state\n\nDSE 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.\n\n- Store intended configurations in a controlled central location and compare devices against them on a defined schedule.\n\n- Isolate management from user and production traffic and prevent unnecessary lateral device-to-device administration.\n\n- Use centralized named administration, least privilege, strong authentication, protected AAA records, and controlled emergency accounts.\n\n- Disable unneeded discovery, web, file-transfer, remote-shell, and management services; use secure versions supported by the vendor.\n\n- Centralize device, authentication, configuration, and flow telemetry and alert on out-of-process changes or stopped logging.\n\n- Verify software images using authenticated vendor information and manage routine and emergency changes with tested rollback.\n\n## Validate from the outside\n\nDSE 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.\n\n## Applicability and limits\n\nThe 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.\n\n## Official reference\n\n[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." }, { "id": "https://update.dsesecurity.com/updates/ddos-readiness-response-playbook/", "slug": "ddos-readiness-response-playbook", "url": "https://update.dsesecurity.com/updates/ddos-readiness-response-playbook/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/ddos-readiness-response-playbook.md", "json": "https://update.dsesecurity.com/api/v1/posts/ddos-readiness-response-playbook/" }, "title": "Prepare for DDoS before availability becomes an incident", "summary": "DDoS readiness requires prioritized public services, provider coverage and emergency contacts, observable baselines, upstream mitigation, exercised decisions, and validated recovery.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "advisory", "name": "Advisory" }, "featured": false, "topics": [ { "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:27:10+00:00", "modified_at": "2026-07-19T21:27:10+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 423, "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.", "primary_source": { "name": "CISA, FBI, and MS-ISAC: Understanding and Responding to Distributed Denial-of-Service Attacks", "url": "https://www.cisa.gov/sites/default/files/2024-03/understanding-and-responding-to-distributed-denial-of-service-attacks_508c.pdf", "published_on": "2024-03-21", "authority": "Cybersecurity and Infrastructure Security Agency" }, "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": "
\n

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.

\n\n

Prepare with providers before the event

\n

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.

\n

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.

\n

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.

\n\n

Build a service-specific playbook

\n

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.

\n
    \n
  1. Record ISP, cloud, hosting, CDN, DNS, application, security-provider, leadership, communications, and law-enforcement contacts appropriate to the organization.
    2. \n
  2. Document contracted protections, exclusions, protected addresses and protocols, activation method, authorization, expected telemetry, evidence needs, and support escalation.
    3. \n
  3. Baseline normal traffic, latency, error, resource, and availability patterns and define criteria for confirmation and incident declaration.
    4. \n
  4. Preapprove bounded filtering, rate limits, traffic diversion, scaling, alternate communication, and business-continuity options where technically appropriate.
    5. \n
  5. Define evidence collection, status updates, recovery validation, and after-action review.
    6. \n
\n\n

Exercise the real coordination path

\n

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.

\n\n

Applicability and limits

\n

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.

\n\n

Official reference

\n

Understanding and Responding to Distributed Denial-of-Service Attacks — joint preparedness and response guidance.

\n
", "content_text": "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.\n\n Prepare with providers before the event\n 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.\n 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.\n 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.\n\n Build a service-specific playbook\n 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.\n \n Record ISP, cloud, hosting, CDN, DNS, application, security-provider, leadership, communications, and law-enforcement contacts appropriate to the organization.\n Document contracted protections, exclusions, protected addresses and protocols, activation method, authorization, expected telemetry, evidence needs, and support escalation.\n Baseline normal traffic, latency, error, resource, and availability patterns and define criteria for confirmation and incident declaration.\n Preapprove bounded filtering, rate limits, traffic diversion, scaling, alternate communication, and business-continuity options where technically appropriate.\n Define evidence collection, status updates, recovery validation, and after-action review.\n \n\n Exercise the real coordination path\n 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.\n\n Applicability and limits\n 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.\n\n Official reference\n Understanding and Responding to Distributed Denial-of-Service Attacks — joint preparedness and response guidance.", "content_markdown": "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.\n\n## Prepare with providers before the event\n\nSource 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.\n\nSource 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.\n\nSource 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.\n\n## Build a service-specific playbook\n\nDSE 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.\n\n- Record ISP, cloud, hosting, CDN, DNS, application, security-provider, leadership, communications, and law-enforcement contacts appropriate to the organization.\n\n- Document contracted protections, exclusions, protected addresses and protocols, activation method, authorization, expected telemetry, evidence needs, and support escalation.\n\n- Baseline normal traffic, latency, error, resource, and availability patterns and define criteria for confirmation and incident declaration.\n\n- Preapprove bounded filtering, rate limits, traffic diversion, scaling, alternate communication, and business-continuity options where technically appropriate.\n\n- Define evidence collection, status updates, recovery validation, and after-action review.\n\n## Exercise the real coordination path\n\nDSE 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.\n\n## Applicability and limits\n\nDDoS 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.\n\n## Official reference\n\n[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." }, { "id": "https://update.dsesecurity.com/updates/encrypted-dns-enterprise-visibility/", "slug": "encrypted-dns-enterprise-visibility", "url": "https://update.dsesecurity.com/updates/encrypted-dns-enterprise-visibility/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/encrypted-dns-enterprise-visibility.md", "json": "https://update.dsesecurity.com/api/v1/posts/encrypted-dns-enterprise-visibility/" }, "title": "Encrypted DNS in enterprise networks: preserve privacy without losing visibility", "summary": "DNS over HTTPS protects client-to-resolver traffic, but unmanaged external resolvers can bypass enterprise filtering, logging, caching, internal naming, and split-DNS behavior.", "format": { "slug": "explainer", "name": "Explainer" }, "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": "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:27:09+00:00", "modified_at": "2026-07-19T21:27:09+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 443, "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.", "primary_source": { "name": "NIST SP 800-81 Rev. 3: Secure Domain Name System (DNS) Deployment Guide", "url": "https://csrc.nist.gov/pubs/sp/800/81/r3/final", "published_on": "2026-03-19", "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": "
\n

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.

\n\n

The benefit and the tradeoff

\n

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.

\n

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.

\n

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.

\n

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.

\n\n

Choose a deliberate enterprise path

\n

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.

\n

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.

\n
    \n
  1. Select approved resolver paths and configure managed clients through supported enterprise policy.
    2. \n
  2. Where operationally appropriate, constrain unauthorized port 53 DNS, port 853 DoT, and known unapproved DoH paths.
    3. \n
  3. Enable resolver and host or device DNS telemetry so encryption does not remove all investigation context.
    4. \n
  4. Validate DNSSEC and any protective-DNS functions independently of transport encryption.
    5. \n
  5. Test internal and external names, VPN, home, branch, guest, mobile, failover, resolver outage, and recovery scenarios.
    6. \n
\n\n

Applicability and limits

\n

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.

\n\n

Official reference

\n

NIST SP 800-81 Rev. 3 — current NIST guidance for encrypted DNS, resolver control, public-provider restrictions, DNS logging, and protective DNS.

\n
", "content_text": "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.\n\n The benefit and the tradeoff\n 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.\n 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.\n 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.\n 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.\n\n Choose a deliberate enterprise path\n 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.\n 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.\n \n Select approved resolver paths and configure managed clients through supported enterprise policy.\n Where operationally appropriate, constrain unauthorized port 53 DNS, port 853 DoT, and known unapproved DoH paths.\n Enable resolver and host or device DNS telemetry so encryption does not remove all investigation context.\n Validate DNSSEC and any protective-DNS functions independently of transport encryption.\n Test internal and external names, VPN, home, branch, guest, mobile, failover, resolver outage, and recovery scenarios.\n \n\n Applicability and limits\n 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.\n\n Official reference\n NIST SP 800-81 Rev. 3 — current NIST guidance for encrypted DNS, resolver control, public-provider restrictions, DNS logging, and protective DNS.", "content_markdown": "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.\n\n## The benefit and the tradeoff\n\nSource 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.\n\nSource 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.\n\nDSE 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.\n\nEncrypted 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.\n\n## Choose a deliberate enterprise path\n\nSource 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.\n\nDSE 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.\n\n- Select approved resolver paths and configure managed clients through supported enterprise policy.\n\n- Where operationally appropriate, constrain unauthorized port 53 DNS, port 853 DoT, and known unapproved DoH paths.\n\n- Enable resolver and host or device DNS telemetry so encryption does not remove all investigation context.\n\n- Validate DNSSEC and any protective-DNS functions independently of transport encryption.\n\n- Test internal and external names, VPN, home, branch, guest, mobile, failover, resolver outage, and recovery scenarios.\n\n## Applicability and limits\n\nSP 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.\n\n## Official reference\n\n[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." }, { "id": "https://update.dsesecurity.com/updates/enterprise-patch-management-preventive-maintenance/", "slug": "enterprise-patch-management-preventive-maintenance", "url": "https://update.dsesecurity.com/updates/enterprise-patch-management-preventive-maintenance/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/enterprise-patch-management-preventive-maintenance.md", "json": "https://update.dsesecurity.com/api/v1/posts/enterprise-patch-management-preventive-maintenance/" }, "title": "Treat enterprise patching as preventive maintenance, not an emergency ritual", "summary": "NIST frames enterprise patching as planned preventive maintenance: identify, prioritize, acquire, install, verify, and govern updates across their full operating lifecycle.", "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": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 420, "potentially_affected": "Organizations responsible for operating supported software, firmware, endpoints, servers, network appliances, cloud-managed devices, and business applications.", "dse_recommendation": "Create an enterprise patch strategy with accountable owners, risk-based deployment lanes, verification evidence, bounded exceptions, and recurring performance review.", "primary_source": { "name": "NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning", "url": "https://csrc.nist.gov/pubs/sp/800/40/r4/final", "published_on": "2022-04-06", "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": "
\n

A patch process becomes unreliable when every update is handled as a new emergency. A durable program establishes ownership, priorities, testing, deployment, verification, exceptions, and improvement before the next urgent vulnerability appears.

\n\n

What NIST establishes

\n

Source fact: NIST SP 800-40 Rev. 4 defines enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. NIST frames that work as preventive maintenance for technology and a necessary cost of operating systems that support the organization’s mission or business.

\n

Source fact: NIST recognizes that business owners and security or technology teams can view the value and operational cost of patching differently. It recommends an enterprise strategy that makes patching simpler and more operational while reducing risk. The publication explains that effective patching can help prevent compromise, data breach, disruption, and other adverse events; it does not claim that patching eliminates those outcomes.

\n\n

Build one governed operating model

\n

DSE recommendation: maintain one strategy that covers supported software and firmware without forcing every asset through an identical schedule. Use business criticality, exposure, exploitation evidence, vendor guidance, safety, dependency, and recovery readiness to place work into routine, accelerated, or emergency lanes.

\n
    \n
  1. Inventory patchable technology, its accountable business and technical owners, support state, deployment method, and critical dependencies.
    2. \n
  2. Define who can prioritize, approve, defer, deploy, stop, and verify an update in each lane.
    3. \n
  3. Require acquisition from an authenticated source and preserve the version, release information, scope, and integrity evidence available from the vendor.
    4. \n
  4. Test against representative systems and workflows, including startup, authentication, networking, monitoring, backup, and the service’s essential business transaction.
    5. \n
  5. Deploy in bounded waves, record failures and exceptions, and verify the installed state independently of the deployment command reporting success.
    6. \n
  6. Give every deferral an owner, rationale, compensating controls, review date, and expiration condition.
    7. \n
\n\n

Measure outcomes, not activity

\n

DSE recommendation: report supported-asset coverage, time from approval to verified installation, deployment failures, expired exceptions, and assets that cannot be updated. A count of updates sent is not proof that systems installed them or that services still work. Review the strategy after significant incidents, platform changes, repeated failures, or evidence that the prioritization model missed important risk.

\n\n

Applicability and limits

\n

NIST provides planning guidance, not a universal remediation deadline or a vendor-specific deployment procedure. Safety, availability, regulation, contract, insurance, product support, and validated rollback capability can change the correct sequence. Use current vendor instructions and current vulnerability evidence for each change. This guide complements—not replaces—asset-specific maintenance procedures and emergency response.

\n\n

Official reference

\n

NIST SP 800-40 Rev. 4 — enterprise patch-management strategy and preventive-maintenance guidance.

\n
", "content_text": "A patch process becomes unreliable when every update is handled as a new emergency. A durable program establishes ownership, priorities, testing, deployment, verification, exceptions, and improvement before the next urgent vulnerability appears.\n\n What NIST establishes\n Source fact: NIST SP 800-40 Rev. 4 defines enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. NIST frames that work as preventive maintenance for technology and a necessary cost of operating systems that support the organization’s mission or business.\n Source fact: NIST recognizes that business owners and security or technology teams can view the value and operational cost of patching differently. It recommends an enterprise strategy that makes patching simpler and more operational while reducing risk. The publication explains that effective patching can help prevent compromise, data breach, disruption, and other adverse events; it does not claim that patching eliminates those outcomes.\n\n Build one governed operating model\n DSE recommendation: maintain one strategy that covers supported software and firmware without forcing every asset through an identical schedule. Use business criticality, exposure, exploitation evidence, vendor guidance, safety, dependency, and recovery readiness to place work into routine, accelerated, or emergency lanes.\n \n Inventory patchable technology, its accountable business and technical owners, support state, deployment method, and critical dependencies.\n Define who can prioritize, approve, defer, deploy, stop, and verify an update in each lane.\n Require acquisition from an authenticated source and preserve the version, release information, scope, and integrity evidence available from the vendor.\n Test against representative systems and workflows, including startup, authentication, networking, monitoring, backup, and the service’s essential business transaction.\n Deploy in bounded waves, record failures and exceptions, and verify the installed state independently of the deployment command reporting success.\n Give every deferral an owner, rationale, compensating controls, review date, and expiration condition.\n \n\n Measure outcomes, not activity\n DSE recommendation: report supported-asset coverage, time from approval to verified installation, deployment failures, expired exceptions, and assets that cannot be updated. A count of updates sent is not proof that systems installed them or that services still work. Review the strategy after significant incidents, platform changes, repeated failures, or evidence that the prioritization model missed important risk.\n\n Applicability and limits\n NIST provides planning guidance, not a universal remediation deadline or a vendor-specific deployment procedure. Safety, availability, regulation, contract, insurance, product support, and validated rollback capability can change the correct sequence. Use current vendor instructions and current vulnerability evidence for each change. This guide complements—not replaces—asset-specific maintenance procedures and emergency response.\n\n Official reference\n NIST SP 800-40 Rev. 4 — enterprise patch-management strategy and preventive-maintenance guidance.", "content_markdown": "A patch process becomes unreliable when every update is handled as a new emergency. A durable program establishes ownership, priorities, testing, deployment, verification, exceptions, and improvement before the next urgent vulnerability appears.\n\n## What NIST establishes\n\nSource fact: NIST SP 800-40 Rev. 4 defines enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades. NIST frames that work as preventive maintenance for technology and a necessary cost of operating systems that support the organization’s mission or business.\n\nSource fact: NIST recognizes that business owners and security or technology teams can view the value and operational cost of patching differently. It recommends an enterprise strategy that makes patching simpler and more operational while reducing risk. The publication explains that effective patching can help prevent compromise, data breach, disruption, and other adverse events; it does not claim that patching eliminates those outcomes.\n\n## Build one governed operating model\n\nDSE recommendation: maintain one strategy that covers supported software and firmware without forcing every asset through an identical schedule. Use business criticality, exposure, exploitation evidence, vendor guidance, safety, dependency, and recovery readiness to place work into routine, accelerated, or emergency lanes.\n\n- Inventory patchable technology, its accountable business and technical owners, support state, deployment method, and critical dependencies.\n\n- Define who can prioritize, approve, defer, deploy, stop, and verify an update in each lane.\n\n- Require acquisition from an authenticated source and preserve the version, release information, scope, and integrity evidence available from the vendor.\n\n- Test against representative systems and workflows, including startup, authentication, networking, monitoring, backup, and the service’s essential business transaction.\n\n- Deploy in bounded waves, record failures and exceptions, and verify the installed state independently of the deployment command reporting success.\n\n- Give every deferral an owner, rationale, compensating controls, review date, and expiration condition.\n\n## Measure outcomes, not activity\n\nDSE recommendation: report supported-asset coverage, time from approval to verified installation, deployment failures, expired exceptions, and assets that cannot be updated. A count of updates sent is not proof that systems installed them or that services still work. Review the strategy after significant incidents, platform changes, repeated failures, or evidence that the prioritization model missed important risk.\n\n## Applicability and limits\n\nNIST provides planning guidance, not a universal remediation deadline or a vendor-specific deployment procedure. Safety, availability, regulation, contract, insurance, product support, and validated rollback capability can change the correct sequence. Use current vendor instructions and current vulnerability evidence for each change. This guide complements—not replaces—asset-specific maintenance procedures and emergency response.\n\n## Official reference\n\n[NIST SP 800-40 Rev. 4](https://csrc.nist.gov/pubs/sp/800/40/r4/final) — enterprise patch-management strategy and preventive-maintenance guidance." }, { "id": "https://update.dsesecurity.com/updates/fema-essential-functions-continuity-elements/", "slug": "fema-essential-functions-continuity-elements", "url": "https://update.dsesecurity.com/updates/fema-essential-functions-continuity-elements/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/fema-essential-functions-continuity-elements.md", "json": "https://update.dsesecurity.com/api/v1/posts/fema-essential-functions-continuity-elements/" }, "title": "Keep essential functions running with FEMA continuity elements", "summary": "FEMA continuity guidance connects essential functions to authority, people, facilities, communications, vital records, technology, devolution, reconstitution, and recurring exercises.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "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:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 412, "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.", "primary_source": { "name": "FEMA Preparedness Toolkit: E.6 Continuity Guidance Circular", "url": "https://preptoolkit.fema.gov/web/cip-citap/ncig/-/knowledge_base/ncig/e-6-continuity-guidance-circular", "published_on": null, "authority": "Federal Emergency Management Agency" }, "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": "
\n

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.

\n\n

What FEMA’s circular covers

\n

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.

\n

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.

\n\n

A whole-service continuity review

\n

DSE recommendation: select one essential function and review every element against real operating evidence:

\n
    \n
  1. Define the function, its priority, minimum acceptable output, dependencies, and the consequences of interruption.
    2. \n
  2. Name successors and document delegations with activation, scope, limits, and communication requirements.
    3. \n
  3. Identify alternate facilities and remote options, including safety, access, equipment, connectivity, and logistical support.
    4. \n
  4. Maintain redundant communication methods for leadership, staff, partners, suppliers, and customers when normal channels fail.
    5. \n
  5. Identify vital records, where protected copies exist, who can retrieve them, and how their integrity and currency are verified.
    6. \n
  6. Plan critical staffing, cross-training, accessibility, health and safety, and support for extended operations.
    7. \n
  7. Define devolution when normal leadership or operations cannot perform the function and reconstitution when stable operations can resume.
    8. \n
\n\n

Exercise the degraded condition

\n

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.

\n

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.

\n\n

Applicability and limits

\n

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.

\n\n

Official reference

\n

FEMA Preparedness Toolkit: E.6 Continuity Guidance Circular — FEMA’s official overview of continuity capabilities for sustaining essential functions and critical services.

\n
", "content_text": "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.\n\n What FEMA’s circular covers\n 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.\n 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.\n\n A whole-service continuity review\n DSE recommendation: select one essential function and review every element against real operating evidence:\n \n Define the function, its priority, minimum acceptable output, dependencies, and the consequences of interruption.\n Name successors and document delegations with activation, scope, limits, and communication requirements.\n Identify alternate facilities and remote options, including safety, access, equipment, connectivity, and logistical support.\n Maintain redundant communication methods for leadership, staff, partners, suppliers, and customers when normal channels fail.\n Identify vital records, where protected copies exist, who can retrieve them, and how their integrity and currency are verified.\n Plan critical staffing, cross-training, accessibility, health and safety, and support for extended operations.\n Define devolution when normal leadership or operations cannot perform the function and reconstitution when stable operations can resume.\n \n\n Exercise the degraded condition\n 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.\n 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.\n\n Applicability and limits\n 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.\n\n Official reference\n FEMA Preparedness Toolkit: E.6 Continuity Guidance Circular — FEMA’s official overview of continuity capabilities for sustaining essential functions and critical services.", "content_markdown": "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.\n\n## What FEMA’s circular covers\n\nSource 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.\n\nSource 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.\n\n## A whole-service continuity review\n\nDSE recommendation: select one essential function and review every element against real operating evidence:\n\n- Define the function, its priority, minimum acceptable output, dependencies, and the consequences of interruption.\n\n- Name successors and document delegations with activation, scope, limits, and communication requirements.\n\n- Identify alternate facilities and remote options, including safety, access, equipment, connectivity, and logistical support.\n\n- Maintain redundant communication methods for leadership, staff, partners, suppliers, and customers when normal channels fail.\n\n- Identify vital records, where protected copies exist, who can retrieve them, and how their integrity and currency are verified.\n\n- Plan critical staffing, cross-training, accessibility, health and safety, and support for extended operations.\n\n- Define devolution when normal leadership or operations cannot perform the function and reconstitution when stable operations can resume.\n\n## Exercise the degraded condition\n\nDSE 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.\n\nCoordinate 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.\n\n## Applicability and limits\n\nThe 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.\n\n## Official reference\n\n[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." }, { "id": "https://update.dsesecurity.com/updates/zero-trust-protect-resources-not-locations/", "slug": "zero-trust-protect-resources-not-locations", "url": "https://update.dsesecurity.com/updates/zero-trust-protect-resources-not-locations/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/zero-trust-protect-resources-not-locations.md", "json": "https://update.dsesecurity.com/api/v1/posts/zero-trust-protect-resources-not-locations/" }, "title": "Zero trust in plain English: protect resources, not network locations", "summary": "NIST zero trust architecture removes implicit trust based on network location or ownership and makes access to each resource an explicit identity, device, context, and policy decision.", "format": { "slug": "explainer", "name": "Explainer" }, "priority": { "slug": "info", "name": "Information" }, "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": "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:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 419, "potentially_affected": "Organizations supporting remote work, cloud services, personal or managed devices, partner access, multiple locations, or sensitive resources across changing network boundaries.", "dse_recommendation": "Inventory resources and trust assumptions, define explicit access policy, strengthen identity and device signals, limit access, collect telemetry, and pilot one bounded resource path.", "primary_source": { "name": "NIST SP 800-207: Zero Trust Architecture", "url": "https://csrc.nist.gov/pubs/sp/800/207/final", "published_on": "2020-08-11", "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": "
\n

Zero trust is often reduced to a slogan or product category. NIST describes an architecture: do not grant access merely because an account or device is inside a network, and protect the resource through explicit policy decisions.

\n\n

What zero trust means in the NIST model

\n

Source fact: NIST SP 800-207 describes zero trust as a shift from static, network-based perimeters toward users, assets, and resources. It says no implicit trust is granted solely because of physical or network location or because an asset is enterprise-owned.

\n

Source fact: Authentication and authorization of the subject and device are distinct functions performed before a session to an enterprise resource is established. NIST emphasizes protecting resources—including assets, services, workflows, and accounts—rather than treating a network segment as the main component of a resource’s security posture.

\n

Remote users, bring-your-own-device practices, and cloud assets outside an enterprise-owned boundary are among the conditions that motivate this approach. SP 800-207 provides an abstract definition, logical components, deployment models, and use cases. It does not designate one product as a zero-trust architecture.

\n\n

Find the trust that exists today

\n

DSE recommendation: start by documenting where current access depends on location, ownership, a broad VPN route, a shared account, or a one-time sign-in. For one important resource, map:

\n \n\n

DSE recommendation: define the least access needed for that transaction and the conditions under which it is allowed, limited, re-evaluated, or denied. Validate strong authentication, device state, service identity, segmented reachability, session behavior, and logging without assuming that any single signal is sufficient. Preserve an emergency path that is independently protected and tested.

\n\n

Adopt incrementally

\n

Pilot a bounded user group and resource. Test ordinary use, remote use, device replacement, loss of a signal, provider outage, policy error, help-desk recovery, and rollback. Measure unauthorized paths removed, successful and denied transactions, support impact, and gaps in visibility. Expand only when the evidence supports the next step.

\n\n

Applicability and limits

\n

Zero trust does not mean trusting nothing, authenticating continuously without purpose, or eliminating networks and firewalls. It does not guarantee prevention and is not a certification. Legacy, operational-technology, safety, latency, availability, privacy, and support constraints require tailored designs. NIST’s architecture must be combined with current platform guidance and organizational risk decisions.

\n\n

Official reference

\n

NIST SP 800-207 — the foundational federal publication defining zero trust architecture.

\n
", "content_text": "Zero trust is often reduced to a slogan or product category. NIST describes an architecture: do not grant access merely because an account or device is inside a network, and protect the resource through explicit policy decisions.\n\n What zero trust means in the NIST model\n Source fact: NIST SP 800-207 describes zero trust as a shift from static, network-based perimeters toward users, assets, and resources. It says no implicit trust is granted solely because of physical or network location or because an asset is enterprise-owned.\n Source fact: Authentication and authorization of the subject and device are distinct functions performed before a session to an enterprise resource is established. NIST emphasizes protecting resources—including assets, services, workflows, and accounts—rather than treating a network segment as the main component of a resource’s security posture.\n Remote users, bring-your-own-device practices, and cloud assets outside an enterprise-owned boundary are among the conditions that motivate this approach. SP 800-207 provides an abstract definition, logical components, deployment models, and use cases. It does not designate one product as a zero-trust architecture.\n\n Find the trust that exists today\n DSE recommendation: start by documenting where current access depends on location, ownership, a broad VPN route, a shared account, or a one-time sign-in. For one important resource, map:\n \n human and non-human identities that request access;\n managed, unmanaged, service, and specialized devices;\n the data, transaction, and privilege being protected;\n identity, device, resource, behavior, and environmental signals available to policy;\n the enforcement point, telemetry, exception path, and recovery dependency.\n \n\n DSE recommendation: define the least access needed for that transaction and the conditions under which it is allowed, limited, re-evaluated, or denied. Validate strong authentication, device state, service identity, segmented reachability, session behavior, and logging without assuming that any single signal is sufficient. Preserve an emergency path that is independently protected and tested.\n\n Adopt incrementally\n Pilot a bounded user group and resource. Test ordinary use, remote use, device replacement, loss of a signal, provider outage, policy error, help-desk recovery, and rollback. Measure unauthorized paths removed, successful and denied transactions, support impact, and gaps in visibility. Expand only when the evidence supports the next step.\n\n Applicability and limits\n Zero trust does not mean trusting nothing, authenticating continuously without purpose, or eliminating networks and firewalls. It does not guarantee prevention and is not a certification. Legacy, operational-technology, safety, latency, availability, privacy, and support constraints require tailored designs. NIST’s architecture must be combined with current platform guidance and organizational risk decisions.\n\n Official reference\n NIST SP 800-207 — the foundational federal publication defining zero trust architecture.", "content_markdown": "Zero trust is often reduced to a slogan or product category. NIST describes an architecture: do not grant access merely because an account or device is inside a network, and protect the resource through explicit policy decisions.\n\n## What zero trust means in the NIST model\n\nSource fact: NIST SP 800-207 describes zero trust as a shift from static, network-based perimeters toward users, assets, and resources. It says no implicit trust is granted solely because of physical or network location or because an asset is enterprise-owned.\n\nSource fact: Authentication and authorization of the subject and device are distinct functions performed before a session to an enterprise resource is established. NIST emphasizes protecting resources—including assets, services, workflows, and accounts—rather than treating a network segment as the main component of a resource’s security posture.\n\nRemote users, bring-your-own-device practices, and cloud assets outside an enterprise-owned boundary are among the conditions that motivate this approach. SP 800-207 provides an abstract definition, logical components, deployment models, and use cases. It does not designate one product as a zero-trust architecture.\n\n## Find the trust that exists today\n\nDSE recommendation: start by documenting where current access depends on location, ownership, a broad VPN route, a shared account, or a one-time sign-in. For one important resource, map:\n\n- human and non-human identities that request access;\n\n- managed, unmanaged, service, and specialized devices;\n\n- the data, transaction, and privilege being protected;\n\n- identity, device, resource, behavior, and environmental signals available to policy;\n\n- the enforcement point, telemetry, exception path, and recovery dependency.\n\nDSE recommendation: define the least access needed for that transaction and the conditions under which it is allowed, limited, re-evaluated, or denied. Validate strong authentication, device state, service identity, segmented reachability, session behavior, and logging without assuming that any single signal is sufficient. Preserve an emergency path that is independently protected and tested.\n\n## Adopt incrementally\n\nPilot a bounded user group and resource. Test ordinary use, remote use, device replacement, loss of a signal, provider outage, policy error, help-desk recovery, and rollback. Measure unauthorized paths removed, successful and denied transactions, support impact, and gaps in visibility. Expand only when the evidence supports the next step.\n\n## Applicability and limits\n\nZero trust does not mean trusting nothing, authenticating continuously without purpose, or eliminating networks and firewalls. It does not guarantee prevention and is not a certification. Legacy, operational-technology, safety, latency, availability, privacy, and support constraints require tailored designs. NIST’s architecture must be combined with current platform guidance and organizational risk decisions.\n\n## Official reference\n\n[NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final) — the foundational federal publication defining zero trust architecture." }, { "id": "https://update.dsesecurity.com/updates/zero-trust-maturity-five-pillar-assessment/", "slug": "zero-trust-maturity-five-pillar-assessment", "url": "https://update.dsesecurity.com/updates/zero-trust-maturity-five-pillar-assessment/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/zero-trust-maturity-five-pillar-assessment.md", "json": "https://update.dsesecurity.com/api/v1/posts/zero-trust-maturity-five-pillar-assessment/" }, "title": "Measure zero-trust maturity across five pillars before buying more tools", "summary": "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.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "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": "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:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 404, "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.", "primary_source": { "name": "CISA Zero Trust Maturity Model, Version 2.0", "url": "https://www.cisa.gov/sites/default/files/2023-04/CISA_Zero_Trust_Maturity_Model_Version_2_508c.pdf", "published_on": null, "authority": "Cybersecurity and Infrastructure Security Agency" }, "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": "
\n

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.

\n\n

How CISA organizes maturity

\n

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.

\n

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.

\n\n

Rate practices with evidence

\n

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.

\n
    \n
  1. Identity: review identity lifecycle, authentication, privilege, service identities, federation, and session decisions.
    2. \n
  2. Devices: review inventory, ownership, health signals, configuration, isolation, and unsupported devices.
    3. \n
  3. Networks: review discovery, segmentation, encrypted paths, policy enforcement, and traffic visibility.
    4. \n
  4. Applications and workloads: review inventory, access, secure delivery, workload identity, dependencies, and runtime visibility.
    5. \n
  5. Data: review inventory, classification, access, encryption, rights, loss controls, lifecycle, and recovery.
    6. \n
\n\n

Select targets by risk

\n

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.

\n

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.

\n\n

Applicability and limits

\n

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.

\n\n

Official reference

\n

CISA Zero Trust Maturity Model Version 2.0 — five-pillar maturity and cross-cutting capability guidance.

\n
", "content_text": "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.\n\n How CISA organizes maturity\n 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.\n 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.\n\n Rate practices with evidence\n 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.\n \n Identity: review identity lifecycle, authentication, privilege, service identities, federation, and session decisions.\n Devices: review inventory, ownership, health signals, configuration, isolation, and unsupported devices.\n Networks: review discovery, segmentation, encrypted paths, policy enforcement, and traffic visibility.\n Applications and workloads: review inventory, access, secure delivery, workload identity, dependencies, and runtime visibility.\n Data: review inventory, classification, access, encryption, rights, loss controls, lifecycle, and recovery.\n \n\n Select targets by risk\n 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.\n 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.\n\n Applicability and limits\n 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.\n\n Official reference\n CISA Zero Trust Maturity Model Version 2.0 — five-pillar maturity and cross-cutting capability guidance.", "content_markdown": "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.\n\n## How CISA organizes maturity\n\nSource 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.\n\nSource 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.\n\n## Rate practices with evidence\n\nDSE 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.\n\n- Identity: review identity lifecycle, authentication, privilege, service identities, federation, and session decisions.\n\n- Devices: review inventory, ownership, health signals, configuration, isolation, and unsupported devices.\n\n- Networks: review discovery, segmentation, encrypted paths, policy enforcement, and traffic visibility.\n\n- Applications and workloads: review inventory, access, secure delivery, workload identity, dependencies, and runtime visibility.\n\n- Data: review inventory, classification, access, encryption, rights, loss controls, lifecycle, and recovery.\n\n## Select targets by risk\n\nDSE 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.\n\nGive 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.\n\n## Applicability and limits\n\nCISA 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.\n\n## Official reference\n\n[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." }, { "id": "https://update.dsesecurity.com/updates/event-logging-detection-integrity-baseline/", "slug": "event-logging-detection-integrity-baseline", "url": "https://update.dsesecurity.com/updates/event-logging-detection-integrity-baseline/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/event-logging-detection-integrity-baseline.md", "json": "https://update.dsesecurity.com/api/v1/posts/event-logging-detection-integrity-baseline/" }, "title": "Build event logging that supports detection, investigation, and resilience", "summary": "Current joint guidance centers effective logging on approved policy, centralized collection and correlation, protected log integrity, and detections designed for relevant threats.", "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": "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:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 400, "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.", "primary_source": { "name": "CISA: Best Practices for Event Logging and Threat Detection", "url": "https://www.cisa.gov/resources-tools/resources/best-practices-event-logging-and-threat-detection", "published_on": "2024-08-21", "authority": "Cybersecurity and Infrastructure Security Agency" }, "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": "
\n

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.

\n\n

Four practices in the joint guidance

\n

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.

\n

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.

\n\n

Define the evidence before the platform

\n

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.

\n
    \n
  1. Inventory identity, administrator, endpoint, server, application, cloud, firewall, network-device, DNS, remote-access, mobile, and relevant OT sources.
    2. \n
  2. Prioritize events that can establish authentication, privilege, configuration change, execution, network movement, data access, service health, and defensive-control activity.
    3. \n
  3. Normalize timestamps and preserve source, user, device, action, result, and correlation context where the system can provide it.
    4. \n
  4. Centralize high-value events and monitor for delayed, malformed, duplicated, or stopped ingestion.
    5. \n
  5. Restrict and monitor access, protect events from alteration and deletion, and maintain recovery appropriate to the evidence requirement.
    6. \n
\n\n

Prove detection and response

\n

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.

\n\n

Applicability and limits

\n

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.

\n\n

Official reference

\n

Best Practices for Event Logging and Threat Detection — joint baseline for policy, centralization, integrity, and detection.

\n
", "content_text": "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.\n\n Four practices in the joint guidance\n 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.\n 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.\n\n Define the evidence before the platform\n 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.\n \n Inventory identity, administrator, endpoint, server, application, cloud, firewall, network-device, DNS, remote-access, mobile, and relevant OT sources.\n Prioritize events that can establish authentication, privilege, configuration change, execution, network movement, data access, service health, and defensive-control activity.\n Normalize timestamps and preserve source, user, device, action, result, and correlation context where the system can provide it.\n Centralize high-value events and monitor for delayed, malformed, duplicated, or stopped ingestion.\n Restrict and monitor access, protect events from alteration and deletion, and maintain recovery appropriate to the evidence requirement.\n \n\n Prove detection and response\n 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.\n\n Applicability and limits\n 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.\n\n Official reference\n Best Practices for Event Logging and Threat Detection — joint baseline for policy, centralization, integrity, and detection.", "content_markdown": "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.\n\n## Four practices in the joint guidance\n\nSource 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.\n\nSource 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.\n\n## Define the evidence before the platform\n\nDSE 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.\n\n- Inventory identity, administrator, endpoint, server, application, cloud, firewall, network-device, DNS, remote-access, mobile, and relevant OT sources.\n\n- Prioritize events that can establish authentication, privilege, configuration change, execution, network movement, data access, service health, and defensive-control activity.\n\n- Normalize timestamps and preserve source, user, device, action, result, and correlation context where the system can provide it.\n\n- Centralize high-value events and monitor for delayed, malformed, duplicated, or stopped ingestion.\n\n- Restrict and monitor access, protect events from alteration and deletion, and maintain recovery appropriate to the evidence requirement.\n\n## Prove detection and response\n\nDSE 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.\n\n## Applicability and limits\n\nThe 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.\n\n## Official reference\n\n[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." }, { "id": "https://update.dsesecurity.com/updates/enterprise-log-management-policy/", "slug": "enterprise-log-management-policy", "url": "https://update.dsesecurity.com/updates/enterprise-log-management-policy/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/enterprise-log-management-policy.md", "json": "https://update.dsesecurity.com/api/v1/posts/enterprise-log-management-policy/" }, "title": "Create an enterprise log-management policy before choosing a SIEM", "summary": "NIST’s durable log-management structure starts with policy, organization-wide responsibility, infrastructure, operating processes, and supported staff—not a particular analytics product.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "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": "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:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 377, "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.", "primary_source": { "name": "NIST SP 800-92: Guide to Computer Security Log Management", "url": "https://csrc.nist.gov/pubs/sp/800/92/final", "published_on": "2006-09-13", "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": "
\n

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.

\n\n

NIST’s program-level foundation

\n

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.

\n

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.

\n\n

Write requirements that systems can implement

\n

DSE recommendation: define requirements by system and data class. A policy should state:

\n \n\n

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.

\n\n

Operate and audit the lifecycle

\n

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.

\n\n

Applicability and limits

\n

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.

\n\n

Official reference

\n

NIST SP 800-92 — final NIST guidance on enterprise computer-security log management.

\n
", "content_text": "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.\n\n NIST’s program-level foundation\n 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.\n 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.\n\n Write requirements that systems can implement\n DSE recommendation: define requirements by system and data class. A policy should state:\n \n the security, operational, legal, contractual, and records purposes for collection;\n minimum event types and context, time synchronization, and expected source reliability;\n approved collection paths, protection in transit and storage, and recovery expectations;\n roles allowed to configure, access, analyze, export, preserve, and dispose of records;\n retention and disposal authority, including preservation when an incident or legal hold applies;\n monitoring for collection failure, capacity exhaustion, time drift, and unauthorized change.\n \n\n 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.\n\n Operate and audit the lifecycle\n 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.\n\n Applicability and limits\n 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.\n\n Official reference\n NIST SP 800-92 — final NIST guidance on enterprise computer-security log management.", "content_markdown": "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.\n\n## NIST’s program-level foundation\n\nSource 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.\n\nSource 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.\n\n## Write requirements that systems can implement\n\nDSE recommendation: define requirements by system and data class. A policy should state:\n\n- the security, operational, legal, contractual, and records purposes for collection;\n\n- minimum event types and context, time synchronization, and expected source reliability;\n\n- approved collection paths, protection in transit and storage, and recovery expectations;\n\n- roles allowed to configure, access, analyze, export, preserve, and dispose of records;\n\n- retention and disposal authority, including preservation when an incident or legal hold applies;\n\n- monitoring for collection failure, capacity exhaustion, time drift, and unauthorized change.\n\nDSE 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.\n\n## Operate and audit the lifecycle\n\nPrioritize 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.\n\n## Applicability and limits\n\nSP 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.\n\n## Official reference\n\n[NIST SP 800-92](https://csrc.nist.gov/pubs/sp/800/92/final) — final NIST guidance on enterprise computer-security log management." }, { "id": "https://update.dsesecurity.com/updates/protective-dns-provider-selection/", "slug": "protective-dns-provider-selection", "url": "https://update.dsesecurity.com/updates/protective-dns-provider-selection/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/protective-dns-provider-selection.md", "json": "https://update.dsesecurity.com/api/v1/posts/protective-dns-provider-selection/" }, "title": "Protective DNS: evaluate the resolver, the data, and the bypass paths", "summary": "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.", "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": "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:26:27+00:00", "modified_at": "2026-07-19T21:26:27+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 2, "word_count": 434, "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.", "primary_source": { "name": "NIST SP 800-81 Rev. 3: Secure Domain Name System (DNS) Deployment Guide", "url": "https://csrc.nist.gov/pubs/sp/800/81/r3/final", "published_on": "2026-03-19", "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": "
\n

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.

\n\n

What protective DNS does

\n

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.

\n

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.

\n

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.

\n\n

Evaluate service and operating evidence

\n

DSE recommendation: define requirements before comparing providers:

\n \n\n

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.

\n\n

Control bypass without breaking operations

\n

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.

\n\n

Applicability and limits

\n

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.

\n\n

Official reference

\n

NIST SP 800-81 Rev. 3 — current NIST guidance for secure DNS deployment, including protective DNS, resolver policy, logging, and encrypted DNS.

\n
", "content_text": "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.\n\n What protective DNS does\n 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.\n 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.\n 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.\n\n Evaluate service and operating evidence\n DSE recommendation: define requirements before comparing providers:\n \n malicious-domain, phishing, malware, command-and-control, and domain-generation detection;\n DNSSEC validation and approved encrypted-DNS support;\n alerts, historical logs, dashboards, API or security-platform integration, and investigation workflow;\n high availability, performance, outage behavior, support, and change notification;\n policies by user, device, group, or network and coverage for roaming, home, branch, and cloud-connected devices;\n DNS-query ownership, retention, location, access, security use, and any non-security use by the provider.\n \n\n 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.\n\n Control bypass without breaking operations\n 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.\n\n Applicability and limits\n 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.\n\n Official reference\n NIST SP 800-81 Rev. 3 — current NIST guidance for secure DNS deployment, including protective DNS, resolver policy, logging, and encrypted DNS.", "content_markdown": "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.\n\n## What protective DNS does\n\nSource 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.\n\nSource 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.\n\nDSE 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.\n\n## Evaluate service and operating evidence\n\nDSE recommendation: define requirements before comparing providers:\n\n- malicious-domain, phishing, malware, command-and-control, and domain-generation detection;\n\n- DNSSEC validation and approved encrypted-DNS support;\n\n- alerts, historical logs, dashboards, API or security-platform integration, and investigation workflow;\n\n- high availability, performance, outage behavior, support, and change notification;\n\n- policies by user, device, group, or network and coverage for roaming, home, branch, and cloud-connected devices;\n\n- DNS-query ownership, retention, location, access, security use, and any non-security use by the provider.\n\nDSE 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.\n\n## Control bypass without breaking operations\n\nWhere 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.\n\n## Applicability and limits\n\nSP 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.\n\n## Official reference\n\n[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." } ] }