Put affected upgrades on hold. If your site has already upgraded from an affected version, contact Avigilon Technical Support immediately, even if the system appears to be operating normally.
\r\nMotorola Solutions technical notice MTN-0168-26, issued September 2, 2026, warns that an affected system can run normally for weeks before routine log cleanup triggers repeated server crashes. The potential data loss includes event metadata, saved bookmarks, and protected videos. Avigilon rates the notice High severity.
\r\nMTN-0168-26 identifies these upgrade paths. ACC means Avigilon Control Center; Unity refers to Avigilon Unity Video.
\r\n| Current version | Planned upgrade destination | Required action |
|---|---|---|
| ACC 7.14.44.4 | ACC 7.14.46.4 | Pause |
| ACC 7.14.44 or 7.14.46 | Unity 8.x | Pause |
| Unity 8.7.x or 8.8.0.x | Unity 8.8.1.x | Pause |
Broader planning hold: The notice’s corrective actions also direct customers to halt planned upgrades from ACC 7 to ACC 7.14.46.4 or any Unity 8.8.x version until an official service release is available. Confirm the exact path with Technical Support before rescheduling.
\r\nAvigilon says it has removed problematic downloads and is blocking affected ACC 7 upgrades to Unity 8.x in Avigilon Software Manager. Its partner communication also directs a pause on the listed paths until an official resolution is released and certified.
\r\nThe technical notice attributes the failure to mismatched secondary indexes in the event-log database. Background retention maintenance can encounter those inconsistencies and crash the service, potentially leaving the server in a continuous crash loop.
\r\nCleanup may occur 14 days or longer after an upgrade, depending on retention settings. That describes typical timing, not a grace period or a deadline after which a site is clear. Contact support now rather than waiting for symptoms.
\r\nThe notice limits potential loss to system event logs, license plate recognition (LPR), point-of-sale (POS) and analytics event metadata, plus saved bookmarks and protected videos. The partner email warns that mitigation may require a database reset. Technical Support should assess preservation options and the mitigation plan for each site.
\r\nThe following operational steps are DSE recommendations based on the vendor guidance:
\r\nKeep the support case, responsible owner, version history, and vendor instructions in the change record. After support-directed work, document the requested checks for server stability, footage retrieval, event metadata, bookmarks, and protected videos. Record remaining limitations before closing the case.
\r\nThe partner communication says a support tool and resolution are being developed and that end-user emails are planned for September 15, 2026. It does not provide a release date. Recheck the notice with support before acting.
\r\nSource review completed September 15, 2026.
", "content_text": "Put affected upgrades on hold. If your site has already upgraded from an affected version, contact Avigilon Technical Support immediately, even if the system appears to be operating normally.\r\nMotorola Solutions technical notice MTN-0168-26, issued September 2, 2026, warns that an affected system can run normally for weeks before routine log cleanup triggers repeated server crashes. The potential data loss includes event metadata, saved bookmarks, and protected videos. Avigilon rates the notice High severity.\r\nSource facts and affected upgrade paths\r\nMTN-0168-26 identifies these upgrade paths. ACC means Avigilon Control Center; Unity refers to Avigilon Unity Video.\r\nCurrent versionPlanned upgrade destinationRequired actionACC 7.14.44.4ACC 7.14.46.4PauseACC 7.14.44 or 7.14.46Unity 8.xPauseUnity 8.7.x or 8.8.0.xUnity 8.8.1.xPause\r\nBroader planning hold: The notice’s corrective actions also direct customers to halt planned upgrades from ACC 7 to ACC 7.14.46.4 or any Unity 8.8.x version until an official service release is available. Confirm the exact path with Technical Support before rescheduling.\r\nAvigilon says it has removed problematic downloads and is blocking affected ACC 7 upgrades to Unity 8.x in Avigilon Software Manager. Its partner communication also directs a pause on the listed paths until an official resolution is released and certified.\r\nWhy a working system still needs attention\r\nThe technical notice attributes the failure to mismatched secondary indexes in the event-log database. Background retention maintenance can encounter those inconsistencies and crash the service, potentially leaving the server in a continuous crash loop.\r\nCleanup may occur 14 days or longer after an upgrade, depending on retention settings. That describes typical timing, not a grace period or a deadline after which a site is clear. Contact support now rather than waiting for symptoms.\r\nThe notice limits potential loss to system event logs, license plate recognition (LPR), point-of-sale (POS) and analytics event metadata, plus saved bookmarks and protected videos. The partner email warns that mitigation may require a database reset. Technical Support should assess preservation options and the mitigation plan for each site.\r\nDSE recommendation and immediate next steps\r\nThe following operational steps are DSE recommendations based on the vendor guidance:\r\n\r\nHold the work. Flag affected upgrades in maintenance schedules and notify the site owner and service team. Include the broader ACC 7 planning hold above.\r\nCheck upgrade history. Record the current build, previous build, upgrade date, and retention configuration. The installed version alone does not show how the site reached it.\r\nOpen a support case immediately if already upgraded. This includes affected source versions in the table and the notice’s explicit instruction for recent ACC 7 upgrades to ACC 7.14.46.4 or Unity 8.8.0 or later. If history is uncertain, ask support to assess it. Provide the version history and any observed errors.\r\nFollow support-directed mitigation. Have support guide monitoring, data preservation, and recovery. Do not independently reset the database or roll back the system based on this article.\r\nVerify before resuming. Obtain the vendor’s official resolution and confirmation of the supported upgrade path before scheduling the change.\r\n\r\nVerification and evidence\r\nKeep the support case, responsible owner, version history, and vendor instructions in the change record. After support-directed work, document the requested checks for server stability, footage retrieval, event metadata, bookmarks, and protected videos. Record remaining limitations before closing the case.\r\nThe partner communication says a support tool and resolution are being developed and that end-user emails are planned for September 15, 2026. It does not provide a release date. Recheck the notice with support before acting.\r\nOfficial references and support\r\n\r\nMotorola Solutions MTN-0168-26 — issued September 2, 2026; direct PDF.\r\nAvigilon partner communication — upgrade pause and planned September 15 customer notification.\r\nAvigilon Technical Support · Open a support case.\r\nDSE customers can also contact the DSE helpdesk for help coordinating their response.\r\n\r\nSource review completed September 15, 2026.", "content_markdown": "Put affected upgrades on hold. If your site has already upgraded from an affected version, contact [Avigilon Technical Support](https://www.avigilon.com/support/help) immediately, even if the system appears to be operating normally.\n\nMotorola Solutions technical notice MTN-0168-26, issued September 2, 2026, warns that an affected system can run normally for weeks before routine log cleanup triggers repeated server crashes. The potential data loss includes event metadata, saved bookmarks, and protected videos. Avigilon rates the notice High severity.\n\n## Source facts and affected upgrade paths\n\n[MTN-0168-26](https://docs.avigilon.com/bundle/global-mtn-0168-26/) identifies these upgrade paths. ACC means Avigilon Control Center; Unity refers to Avigilon Unity Video.\n\nCurrent versionPlanned upgrade destinationRequired action\n\nACC 7.14.44.4ACC 7.14.46.4Pause\n\nACC 7.14.44 or 7.14.46Unity 8.xPause\n\nUnity 8.7.x or 8.8.0.xUnity 8.8.1.xPause\n\nBroader planning hold: The notice’s corrective actions also direct customers to halt planned upgrades from ACC 7 to ACC 7.14.46.4 or any Unity 8.8.x version until an official service release is available. Confirm the exact path with Technical Support before rescheduling.\n\nAvigilon says it has removed problematic downloads and is blocking affected ACC 7 upgrades to Unity 8.x in Avigilon Software Manager. Its partner communication also directs a pause on the listed paths until an official resolution is released and certified.\n\n## Why a working system still needs attention\n\nThe technical notice attributes the failure to mismatched secondary indexes in the event-log database. Background retention maintenance can encounter those inconsistencies and crash the service, potentially leaving the server in a continuous crash loop.\n\nCleanup may occur 14 days or longer after an upgrade, depending on retention settings. That describes typical timing, not a grace period or a deadline after which a site is clear. Contact support now rather than waiting for symptoms.\n\nThe notice limits potential loss to system event logs, license plate recognition (LPR), point-of-sale (POS) and analytics event metadata, plus saved bookmarks and protected videos. The partner email warns that mitigation may require a database reset. Technical Support should assess preservation options and the mitigation plan for each site.\n\n## DSE recommendation and immediate next steps\n\nThe following operational steps are DSE recommendations based on the vendor guidance:\n\n- Hold the work. Flag affected upgrades in maintenance schedules and notify the site owner and service team. Include the broader ACC 7 planning hold above.\n\n- Check upgrade history. Record the current build, previous build, upgrade date, and retention configuration. The installed version alone does not show how the site reached it.\n\n- Open a support case immediately if already upgraded. This includes affected source versions in the table and the notice’s explicit instruction for recent ACC 7 upgrades to ACC 7.14.46.4 or Unity 8.8.0 or later. If history is uncertain, ask support to assess it. Provide the version history and any observed errors.\n\n- Follow support-directed mitigation. Have support guide monitoring, data preservation, and recovery. Do not independently reset the database or roll back the system based on this article.\n\n- Verify before resuming. Obtain the vendor’s official resolution and confirmation of the supported upgrade path before scheduling the change.\n\n## Verification and evidence\n\nKeep the support case, responsible owner, version history, and vendor instructions in the change record. After support-directed work, document the requested checks for server stability, footage retrieval, event metadata, bookmarks, and protected videos. Record remaining limitations before closing the case.\n\nThe partner communication says a support tool and resolution are being developed and that end-user emails are planned for September 15, 2026. It does not provide a release date. Recheck the notice with support before acting.\n\n## Official references and support\n\n- [Motorola Solutions MTN-0168-26](https://docs.avigilon.com/bundle/global-mtn-0168-26/) — issued September 2, 2026; [direct PDF](https://docs-be.avigilon.com/bundle/global-mtn-0168-26/raw/resource/enus/global-mtn-0168-26.pdf).\n\n- Avigilon partner communication — upgrade pause and planned September 15 customer notification.\n\n- [Avigilon Technical Support](https://www.avigilon.com/support/help) · [Open a support case](https://support.avigilon.com/s/contactsupport).\n\n- DSE customers can also [contact the DSE helpdesk](https://help.dsesecurity.com/) for help coordinating their response.\n\nSource review completed September 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/ccure-9000-victor-cve-2026-21655-cisa-update-a/", "slug": "ccure-9000-victor-cve-2026-21655-cisa-update-a", "url": "https://update.dsesecurity.com/updates/ccure-9000-victor-cve-2026-21655-cisa-update-a/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/ccure-9000-victor-cve-2026-21655-cisa-update-a.md", "json": "https://update.dsesecurity.com/api/v1/posts/ccure-9000-victor-cve-2026-21655-cisa-update-a/" }, "title": "C-CURE 9000 and victor RCE: What CISA Update A Changes", "summary": "CISA Update A revises critical guidance for Johnson Controls C-CURE 9000 and victor. Review CVE-2026-21655, adjacent-network exposure on port 8999, affected versions, fixed releases, and temporary mitigations.", "format": { "slug": "briefing", "name": "Briefing" }, "priority": { "slug": "critical", "name": "Critical" }, "featured": true, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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": "video-surveillance", "name": "Video Surveillance", "url": "https://update.dsesecurity.com/topic/video-surveillance/" } ], "author": { "name": "Gavin Stewart", "url": "https://www.linkedin.com/in/gavin-stewart-0718/", "type": "Person" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-12T14:47:53+00:00", "modified_at": "2026-08-12T14:47:53+00:00", "reviewed_on": "2026-08-12", "reading_minutes": 4, "word_count": 782, "potentially_affected": "Organizations operating C-CURE 9000, victor Application Server, victor, or victor Web—including security operations workstations, disaster-recovery systems, test environments, and connected management networks.", "dse_recommendation": "Inventory exact versions and network paths, restrict port 8999 and management access, expedite vendor-supported upgrades, review relevant logs, and functionally test access-control and video operations after the change.", "primary_source": { "name": "CISA ICSA-26-204-01 Update A", "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01", "published_on": "2026-08-11", "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": "\r\nBottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.
\r\n\r\nCISA ICSA-26-204-01 Update A covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.
\r\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its product advisory also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.
\r\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.
\r\n\r\n| Finding | Affected product | Vendor-directed update |
|---|---|---|
| CVE-2026-21655 | C-CURE 9000 3.10.1 and earlier | Upgrade to 3.20 or later |
| CVE-2026-21655 | victor Application Server 4.10 and earlier | Upgrade to 4.20 or later |
| CVE-2026-21655 | victor 7.0 and earlier | Upgrade to 8.0 or later |
| CVE-2026-21653 | victor Web versions before 7.0 | Upgrade to 7.0 or later |
| CVE-2026-34496 | victor Web 7.1 and earlier | Use the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator |
The Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.
\r\n\r\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.
\r\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.
\r\n\r\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.
For CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.
\r\n\r\nThe following steps are DSE recommendations based on the official advisories.
\r\nSoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.Source review completed August 12, 2026. Recheck the official advisories before changing production systems.
\r\n", "content_text": "Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.\r\n\r\nSource fact: what CISA Update A covers\r\nCISA ICSA-26-204-01 Update A covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.\r\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its product advisory also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.\r\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.\r\n\r\nAffected versions and vendor-directed updates\r\n\r\nFindingAffected productVendor-directed update\r\n\r\nCVE-2026-21655C-CURE 9000 3.10.1 and earlierUpgrade to 3.20 or later\r\nCVE-2026-21655victor Application Server 4.10 and earlierUpgrade to 4.20 or later\r\nCVE-2026-21655victor 7.0 and earlierUpgrade to 8.0 or later\r\nCVE-2026-21653victor Web versions before 7.0Upgrade to 7.0 or later\r\nCVE-2026-34496victor Web 7.1 and earlierUse the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator\r\n\r\n\r\nThe Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.\r\n\r\nWhy “adjacent network” still deserves urgency\r\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.\r\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.\r\n\r\nVendor-provided temporary mitigations\r\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.\r\nFor CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.\r\n\r\nDSE recommendation: prioritized response\r\nThe following steps are DSE recommendations based on the official advisories.\r\n\r\nConfirm exposure now. Inventory every production, disaster-recovery, and test deployment. Record exact product versions, application and web servers, operator clients, network paths, owners, integrations, and remote-support routes.\r\nContain pending upgrades. Restrict port 8999, remove unnecessary cross-segment access, limit victor Web to trusted management paths, and constrain outbound web traffic. Give every temporary exception an owner and expiration date.\r\nExpedite vendor-supported updates. Prioritize the RCE path. For CVE-2026-34496, verify the precise fixed victor Web build with the vendor or integrator.\r\nProtect operations during the change. Follow supported backup and rollback procedures. After updating, test operator sign-in, access-control commands, alarm receipt and acknowledgment, video recording and retrieval, event-to-video associations, reports, and critical integrations.\r\nReview available evidence. Look for unexplained child processes from SoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.\r\nDocument closure. Record fixed versions, containment changes, functional-test results, residual exceptions, and the date the official advisories were rechecked.\r\n\r\n\r\nOfficial reference\r\n\r\nCISA ICSA-26-204-01 Update A, updated August 11, 2026\r\nJohnson Controls JCI-PSA-2026-13 v2, updated August 6, 2026\r\nJohnson Controls JCI-PSA-2026-07\r\nJohnson Controls JCI-PSA-2026-16\r\nJohnson Controls Product Security Advisory register\r\n\r\nSource review completed August 12, 2026. Recheck the official advisories before changing production systems.", "content_markdown": "Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.\n\n## Source fact: what CISA Update A covers\n\n[CISA ICSA-26-204-01 Update A](https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01) covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.\n\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its [product advisory](https://tyco.widen.net/s/9xktps8hl6/jci-psa-2026-13-v2) also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.\n\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.\n\n## Affected versions and vendor-directed updates\n\nFindingAffected productVendor-directed update\n\nCVE-2026-21655C-CURE 9000 3.10.1 and earlierUpgrade to 3.20 or later\n\nCVE-2026-21655victor Application Server 4.10 and earlierUpgrade to 4.20 or later\n\nCVE-2026-21655victor 7.0 and earlierUpgrade to 8.0 or later\n\nCVE-2026-21653victor Web versions before 7.0Upgrade to 7.0 or later\n\nCVE-2026-34496victor Web 7.1 and earlierUse the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator\n\nThe Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.\n\n## Why “adjacent network” still deserves urgency\n\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.\n\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.\n\n## Vendor-provided temporary mitigations\n\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.\n\nFor CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.\n\n## DSE recommendation: prioritized response\n\nThe following steps are DSE recommendations based on the official advisories.\n\n- Confirm exposure now. Inventory every production, disaster-recovery, and test deployment. Record exact product versions, application and web servers, operator clients, network paths, owners, integrations, and remote-support routes.\n\n- Contain pending upgrades. Restrict port 8999, remove unnecessary cross-segment access, limit victor Web to trusted management paths, and constrain outbound web traffic. Give every temporary exception an owner and expiration date.\n\n- Expedite vendor-supported updates. Prioritize the RCE path. For CVE-2026-34496, verify the precise fixed victor Web build with the vendor or integrator.\n\n- Protect operations during the change. Follow supported backup and rollback procedures. After updating, test operator sign-in, access-control commands, alarm receipt and acknowledgment, video recording and retrieval, event-to-video associations, reports, and critical integrations.\n\n- Review available evidence. Look for unexplained child processes from SoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.\n\n- Document closure. Record fixed versions, containment changes, functional-test results, residual exceptions, and the date the official advisories were rechecked.\n\n## Official reference\n\n- [CISA ICSA-26-204-01 Update A](https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01), updated August 11, 2026\n\n- [Johnson Controls JCI-PSA-2026-13 v2](https://tyco.widen.net/s/9xktps8hl6/jci-psa-2026-13-v2), updated August 6, 2026\n\n- [Johnson Controls JCI-PSA-2026-07](https://tyco.widen.net/s/n5vdddqbcs/jci-psa-2026-07)\n\n- [Johnson Controls JCI-PSA-2026-16](https://tyco.widen.net/s/s9cchrkg87/jci-psa-2026-16)\n\n- [Johnson Controls Product Security Advisory register](https://www.johnsoncontrols.com/trust-center/cybersecurity/security-advisories)\n\nSource review completed August 12, 2026. Recheck the official advisories before changing production systems." }, { "id": "https://update.dsesecurity.com/updates/include-viewports-and-active-viewers-when-assessing-protect-camera-capacity/", "slug": "include-viewports-and-active-viewers-when-assessing-protect-camera-capacity", "url": "https://update.dsesecurity.com/updates/include-viewports-and-active-viewers-when-assessing-protect-camera-capacity/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/include-viewports-and-active-viewers-when-assessing-protect-camera-capacity.md", "json": "https://update.dsesecurity.com/api/v1/posts/include-viewports-and-active-viewers-when-assessing-protect-camera-capacity/" }, "title": "Include Viewports and active viewers when assessing Protect camera capacity", "summary": "Include normal displays, operators, resolutions, and disk health in the recorder capacity acceptance workload.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:32:19+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 275, "potentially_affected": "Applies to Protect’s current recommended capacity guidance and supported console models. The table is a planning reference; this article does not assign an unsupported universal stream or viewer limit.", "dse_recommendation": "DSE recommends documenting the complete viewing workload when reviewing recorder capacity.", "primary_source": { "name": "Ubiquiti Help Center — UniFi Protect - Supported Camera Limits", "url": "https://help.ui.com/hc/en-us/articles/360063280653-UniFi-Protect-Supported-Camera-Limits", "published_on": null, "authority": "help.ui.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Include normal displays, operators, resolutions, and disk health in the recorder capacity acceptance workload.
\nUniFi Protect reports recommended camera capacity rather than a hard camera-count limit. Its guide says active viewer volume, Viewports, and disk health can affect whether a console approaches or exceeds that capacity. Published model tables also distinguish camera resolutions and include deployment assumptions, such as dedicating a CloudKey to Protect and reduced UNVR-G2 capacity when its integrated Viewport is used. A count that fits one table column therefore does not independently establish acceptance of the installed viewing and recording workload.
\nSource: Ubiquiti Help Center — UniFi Protect – Supported Camera Limits.
\nApplies to Protect’s current recommended capacity guidance and supported console models. The table is a planning reference; this article does not assign an unsupported universal stream or viewer limit.
\nDSE recommends documenting the complete viewing workload when reviewing recorder capacity. Include concurrent operators, display appliances, camera resolutions, other running applications, and storage health. Use the vendor calculator for the actual mix and agree on expected playback responsiveness and recording continuity. Investigate a capacity warning before adding more cameras, and keep a planned expansion path. Do not dismiss the warning solely because the application still allows another camera to be adopted.
\nDuring an approved representative load period, check dashboard warnings, expected live views, historical playback, and continuous new recording across the camera set. Include the normal Viewports and operator sessions. Record the actual workload and results so a later display expansion triggers a fresh review rather than reusing an earlier camera-count acceptance.
\nUbiquiti Help Center — UniFi Protect – Supported Camera Limits. Reviewed October 15, 2026.
", "content_text": "Include normal displays, operators, resolutions, and disk health in the recorder capacity acceptance workload.\nSource facts\nUniFi Protect reports recommended camera capacity rather than a hard camera-count limit. Its guide says active viewer volume, Viewports, and disk health can affect whether a console approaches or exceeds that capacity. Published model tables also distinguish camera resolutions and include deployment assumptions, such as dedicating a CloudKey to Protect and reduced UNVR-G2 capacity when its integrated Viewport is used. A count that fits one table column therefore does not independently establish acceptance of the installed viewing and recording workload.\nSource: Ubiquiti Help Center — UniFi Protect – Supported Camera Limits.\nApplicability\nApplies to Protect’s current recommended capacity guidance and supported console models. The table is a planning reference; this article does not assign an unsupported universal stream or viewer limit.\nDSE recommendation\nDSE recommends documenting the complete viewing workload when reviewing recorder capacity. Include concurrent operators, display appliances, camera resolutions, other running applications, and storage health. Use the vendor calculator for the actual mix and agree on expected playback responsiveness and recording continuity. Investigate a capacity warning before adding more cameras, and keep a planned expansion path. Do not dismiss the warning solely because the application still allows another camera to be adopted.\nVerification\nDuring an approved representative load period, check dashboard warnings, expected live views, historical playback, and continuous new recording across the camera set. Include the normal Viewports and operator sessions. Record the actual workload and results so a later display expansion triggers a fresh review rather than reusing an earlier camera-count acceptance.\nOfficial reference\nUbiquiti Help Center — UniFi Protect – Supported Camera Limits. Reviewed October 15, 2026.", "content_markdown": "Include normal displays, operators, resolutions, and disk health in the recorder capacity acceptance workload.\n\n## Source facts\n\nUniFi Protect reports recommended camera capacity rather than a hard camera-count limit. Its guide says active viewer volume, Viewports, and disk health can affect whether a console approaches or exceeds that capacity. Published model tables also distinguish camera resolutions and include deployment assumptions, such as dedicating a CloudKey to Protect and reduced UNVR-G2 capacity when its integrated Viewport is used. A count that fits one table column therefore does not independently establish acceptance of the installed viewing and recording workload.\n\nSource: [Ubiquiti Help Center — UniFi Protect – Supported Camera Limits](https://help.ui.com/hc/en-us/articles/360063280653-UniFi-Protect-Supported-Camera-Limits).\n\n## Applicability\n\nApplies to Protect’s current recommended capacity guidance and supported console models. The table is a planning reference; this article does not assign an unsupported universal stream or viewer limit.\n\n## DSE recommendation\n\nDSE recommends documenting the complete viewing workload when reviewing recorder capacity. Include concurrent operators, display appliances, camera resolutions, other running applications, and storage health. Use the vendor calculator for the actual mix and agree on expected playback responsiveness and recording continuity. Investigate a capacity warning before adding more cameras, and keep a planned expansion path. Do not dismiss the warning solely because the application still allows another camera to be adopted.\n\n## Verification\n\nDuring an approved representative load period, check dashboard warnings, expected live views, historical playback, and continuous new recording across the camera set. Include the normal Viewports and operator sessions. Record the actual workload and results so a later display expansion triggers a fresh review rather than reusing an earlier camera-count acceptance.\n\n## Official reference\n\n[Ubiquiti Help Center — UniFi Protect – Supported Camera Limits](https://help.ui.com/hc/en-us/articles/360063280653-UniFi-Protect-Supported-Camera-Limits). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/check-whether-a-unifi-nvr-raid-transition-requires-reformatting/", "slug": "check-whether-a-unifi-nvr-raid-transition-requires-reformatting", "url": "https://update.dsesecurity.com/updates/check-whether-a-unifi-nvr-raid-transition-requires-reformatting/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-whether-a-unifi-nvr-raid-transition-requires-reformatting.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-whether-a-unifi-nvr-raid-transition-requires-reformatting/" }, "title": "Check whether a UniFi NVR RAID transition requires reformatting", "summary": "Match the exact model, drive count, and target layout to the vendor’s reformatting table before changing RAID.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:32:18+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 278, "potentially_affected": "Applies to the UNVR/ENVR transition tables in the current UniFi storage guide, with the ENVR examples stated above. Do not apply those examples to UNAS, ENAS, or a different drive layout.", "dse_recommendation": "DSE recommends checking the exact transition row before approving a storage-protection change.", "primary_source": { "name": "Ubiquiti Help Center — Storage Protection and Data Redundancy in UniFi (RAID)", "url": "https://help.ui.com/hc/en-us/articles/12395353544727-Storage-Protection-and-Data-Redundancy-in-UniFi-RAID", "published_on": null, "authority": "help.ui.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Match the exact model, drive count, and target layout to the vendor’s reformatting table before changing RAID.
\nUniFi’s storage guide distinguishes RAID transitions by recorder model, current layout, drive count, and target layout. Its ENVR table shows that adding a hot spare to a full 16-drive RAID 5/6 configuration requires reformatting, while the listed one-to-fifteen-drive transition does not. The same table marks transitions from RAID 5/6, with or without a hot spare, to RAID 10 as requiring reformatting. For existing NVR arrays, adding or replacing drives triggers a rebuild and can temporarily affect performance.
\nSource: Ubiquiti Help Center — Storage Protection and Data Redundancy in UniFi (RAID).
\nApplies to the UNVR/ENVR transition tables in the current UniFi storage guide, with the ENVR examples stated above. Do not apply those examples to UNAS, ENAS, or a different drive layout.
\nDSE recommends checking the exact transition row before approving a storage-protection change. Record the model, bay occupancy, current RAID state, desired target, and whether the vendor marks it destructive. Preserve required footage and configurations independently before any reformatting path. Plan a maintenance window and acceptance criteria for the rebuilt system. Avoid treating an apparently empty usable-capacity display or a hot-spare label as permission to improvise a different disk sequence.
\nHave a second qualified reviewer compare the planned operation with the current model-specific table. After the approved change, inspect array state, camera recording, playback, and actual usable capacity. Record completion of rebuild and preservation checks; do not claim that changing RAID protection replaces the need for a separate recoverable evidence copy.
\nUbiquiti Help Center — Storage Protection and Data Redundancy in UniFi (RAID). Reviewed October 15, 2026.
", "content_text": "Match the exact model, drive count, and target layout to the vendor’s reformatting table before changing RAID.\nSource facts\nUniFi’s storage guide distinguishes RAID transitions by recorder model, current layout, drive count, and target layout. Its ENVR table shows that adding a hot spare to a full 16-drive RAID 5/6 configuration requires reformatting, while the listed one-to-fifteen-drive transition does not. The same table marks transitions from RAID 5/6, with or without a hot spare, to RAID 10 as requiring reformatting. For existing NVR arrays, adding or replacing drives triggers a rebuild and can temporarily affect performance.\nSource: Ubiquiti Help Center — Storage Protection and Data Redundancy in UniFi (RAID).\nApplicability\nApplies to the UNVR/ENVR transition tables in the current UniFi storage guide, with the ENVR examples stated above. Do not apply those examples to UNAS, ENAS, or a different drive layout.\nDSE recommendation\nDSE recommends checking the exact transition row before approving a storage-protection change. Record the model, bay occupancy, current RAID state, desired target, and whether the vendor marks it destructive. Preserve required footage and configurations independently before any reformatting path. Plan a maintenance window and acceptance criteria for the rebuilt system. Avoid treating an apparently empty usable-capacity display or a hot-spare label as permission to improvise a different disk sequence.\nVerification\nHave a second qualified reviewer compare the planned operation with the current model-specific table. After the approved change, inspect array state, camera recording, playback, and actual usable capacity. Record completion of rebuild and preservation checks; do not claim that changing RAID protection replaces the need for a separate recoverable evidence copy.\nOfficial reference\nUbiquiti Help Center — Storage Protection and Data Redundancy in UniFi (RAID). Reviewed October 15, 2026.", "content_markdown": "Match the exact model, drive count, and target layout to the vendor’s reformatting table before changing RAID.\n\n## Source facts\n\nUniFi’s storage guide distinguishes RAID transitions by recorder model, current layout, drive count, and target layout. Its ENVR table shows that adding a hot spare to a full 16-drive RAID 5/6 configuration requires reformatting, while the listed one-to-fifteen-drive transition does not. The same table marks transitions from RAID 5/6, with or without a hot spare, to RAID 10 as requiring reformatting. For existing NVR arrays, adding or replacing drives triggers a rebuild and can temporarily affect performance.\n\nSource: [Ubiquiti Help Center — Storage Protection and Data Redundancy in UniFi (RAID)](https://help.ui.com/hc/en-us/articles/12395353544727-Storage-Protection-and-Data-Redundancy-in-UniFi-RAID).\n\n## Applicability\n\nApplies to the UNVR/ENVR transition tables in the current UniFi storage guide, with the ENVR examples stated above. Do not apply those examples to UNAS, ENAS, or a different drive layout.\n\n## DSE recommendation\n\nDSE recommends checking the exact transition row before approving a storage-protection change. Record the model, bay occupancy, current RAID state, desired target, and whether the vendor marks it destructive. Preserve required footage and configurations independently before any reformatting path. Plan a maintenance window and acceptance criteria for the rebuilt system. Avoid treating an apparently empty usable-capacity display or a hot-spare label as permission to improvise a different disk sequence.\n\n## Verification\n\nHave a second qualified reviewer compare the planned operation with the current model-specific table. After the approved change, inspect array state, camera recording, playback, and actual usable capacity. Record completion of rebuild and preservation checks; do not claim that changing RAID protection replaces the need for a separate recoverable evidence copy.\n\n## Official reference\n\n[Ubiquiti Help Center — Storage Protection and Data Redundancy in UniFi (RAID)](https://help.ui.com/hc/en-us/articles/12395353544727-Storage-Protection-and-Data-Redundancy-in-UniFi-RAID). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/pair-ai-port-cameras-explicitly-and-check-mixed-camera-capacity-restrictions/", "slug": "pair-ai-port-cameras-explicitly-and-check-mixed-camera-capacity-restrictions", "url": "https://update.dsesecurity.com/updates/pair-ai-port-cameras-explicitly-and-check-mixed-camera-capacity-restrictions/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/pair-ai-port-cameras-explicitly-and-check-mixed-camera-capacity-restrictions.md", "json": "https://update.dsesecurity.com/api/v1/posts/pair-ai-port-cameras-explicitly-and-check-mixed-camera-capacity-restrictions/" }, "title": "Pair AI Port cameras explicitly and check mixed-camera capacity restrictions", "summary": "Approve a per-port camera allocation and confirm explicit pairing before counting its AI-enabled channels.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:32:17+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 267, "potentially_affected": "Applies to the AI Port accessory and the camera/stream matrix in its current FAQ. This concerns channel allocation and pairing, not a guarantee that every camera or recognition task is supported.", "dse_recommendation": "DSE recommends preparing a per-port allocation sheet with camera family, resolution, stream rate, and intended detection functions.", "primary_source": { "name": "Ubiquiti Help Center — Protect AI Port FAQs", "url": "https://help.ui.com/hc/en-us/articles/28315005177239-Protect-AI-Port-FAQs", "published_on": null, "authority": "help.ui.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Approve a per-port camera allocation and confirm explicit pairing before counting its AI-enabled channels.
\nUniFi AI Port camera capacity depends on camera type and resolution, and its FAQ says third-party cameras cannot be mixed with Protect cameras on one AI Port. A directly connected camera still needs explicit pairing in Protect; physical attachment alone does not complete configuration. The FAQ also excludes Protect AI-series cameras, limits supported stream resolution and frame rate, and identifies limitations for very wide multi-sensor aspect ratios. Compatibility and pairing therefore need checking before counting every connected camera as an AI-enabled channel.
\nSource: Ubiquiti Help Center — Protect AI Port FAQs.
\nApplies to the AI Port accessory and the camera/stream matrix in its current FAQ. This concerns channel allocation and pairing, not a guarantee that every camera or recognition task is supported.
\nDSE recommends preparing a per-port allocation sheet with camera family, resolution, stream rate, and intended detection functions. Keep third-party and Protect allocations separate and verify each exact model against the current FAQ. Do not infer support from an Ethernet connection or the fact that the camera already records normally. Pair a representative camera first and confirm its required detections before purchasing or assigning the remaining accessories.
\nInspect the AI Port pairing list, compare it with the allocation sheet, and check that the intended camera produces the required detection controls and events. Confirm the configured stream fits the documented limits. Record unsupported models and aspect ratios explicitly instead of troubleshooting them as ordinary network failures.
\nUbiquiti Help Center — Protect AI Port FAQs. Reviewed October 15, 2026.
", "content_text": "Approve a per-port camera allocation and confirm explicit pairing before counting its AI-enabled channels.\nSource facts\nUniFi AI Port camera capacity depends on camera type and resolution, and its FAQ says third-party cameras cannot be mixed with Protect cameras on one AI Port. A directly connected camera still needs explicit pairing in Protect; physical attachment alone does not complete configuration. The FAQ also excludes Protect AI-series cameras, limits supported stream resolution and frame rate, and identifies limitations for very wide multi-sensor aspect ratios. Compatibility and pairing therefore need checking before counting every connected camera as an AI-enabled channel.\nSource: Ubiquiti Help Center — Protect AI Port FAQs.\nApplicability\nApplies to the AI Port accessory and the camera/stream matrix in its current FAQ. This concerns channel allocation and pairing, not a guarantee that every camera or recognition task is supported.\nDSE recommendation\nDSE recommends preparing a per-port allocation sheet with camera family, resolution, stream rate, and intended detection functions. Keep third-party and Protect allocations separate and verify each exact model against the current FAQ. Do not infer support from an Ethernet connection or the fact that the camera already records normally. Pair a representative camera first and confirm its required detections before purchasing or assigning the remaining accessories.\nVerification\nInspect the AI Port pairing list, compare it with the allocation sheet, and check that the intended camera produces the required detection controls and events. Confirm the configured stream fits the documented limits. Record unsupported models and aspect ratios explicitly instead of troubleshooting them as ordinary network failures.\nOfficial reference\nUbiquiti Help Center — Protect AI Port FAQs. Reviewed October 15, 2026.", "content_markdown": "Approve a per-port camera allocation and confirm explicit pairing before counting its AI-enabled channels.\n\n## Source facts\n\nUniFi AI Port camera capacity depends on camera type and resolution, and its FAQ says third-party cameras cannot be mixed with Protect cameras on one AI Port. A directly connected camera still needs explicit pairing in Protect; physical attachment alone does not complete configuration. The FAQ also excludes Protect AI-series cameras, limits supported stream resolution and frame rate, and identifies limitations for very wide multi-sensor aspect ratios. Compatibility and pairing therefore need checking before counting every connected camera as an AI-enabled channel.\n\nSource: [Ubiquiti Help Center — Protect AI Port FAQs](https://help.ui.com/hc/en-us/articles/28315005177239-Protect-AI-Port-FAQs).\n\n## Applicability\n\nApplies to the AI Port accessory and the camera/stream matrix in its current FAQ. This concerns channel allocation and pairing, not a guarantee that every camera or recognition task is supported.\n\n## DSE recommendation\n\nDSE recommends preparing a per-port allocation sheet with camera family, resolution, stream rate, and intended detection functions. Keep third-party and Protect allocations separate and verify each exact model against the current FAQ. Do not infer support from an Ethernet connection or the fact that the camera already records normally. Pair a representative camera first and confirm its required detections before purchasing or assigning the remaining accessories.\n\n## Verification\n\nInspect the AI Port pairing list, compare it with the allocation sheet, and check that the intended camera produces the required detection controls and events. Confirm the configured stream fits the documented limits. Record unsupported models and aspect ratios explicitly instead of troubleshooting them as ordinary network failures.\n\n## Official reference\n\n[Ubiquiti Help Center — Protect AI Port FAQs](https://help.ui.com/hc/en-us/articles/28315005177239-Protect-AI-Port-FAQs). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/separate-protect-settings-migration-from-preservation-of-existing-recordings/", "slug": "separate-protect-settings-migration-from-preservation-of-existing-recordings", "url": "https://update.dsesecurity.com/updates/separate-protect-settings-migration-from-preservation-of-existing-recordings/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/separate-protect-settings-migration-from-preservation-of-existing-recordings.md", "json": "https://update.dsesecurity.com/api/v1/posts/separate-protect-settings-migration-from-preservation-of-existing-recordings/" }, "title": "Separate Protect settings migration from preservation of existing recordings", "summary": "Verify configuration continuity and historical footage preservation separately before retiring the old recorder.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:32:16+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 274, "potentially_affected": "Applies to the model-specific migration paths in UniFi’s current guide. Confirm the source and destination models before choosing a procedure; this article does not promise that every disk set is portable.", "dse_recommendation": "DSE recommends maintaining separate checklists for configuration continuity and footage preservation.", "primary_source": { "name": "Ubiquiti Help Center — Migrating Cameras Between NVRs", "url": "https://help.ui.com/hc/en-us/articles/19118654419607-Migrating-Cameras-Between-NVRs", "published_on": null, "authority": "help.ui.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Verify configuration continuity and historical footage preservation separately before retiring the old recorder.
\nUniFi’s migration guide separates a Cloud Gateway-to-NVR move from replacement or upgraded NVR workflows. For a gateway move, the guide explicitly says recordings do not migrate, directs users to export clips they need, and restores a recent settings backup after stopping Protect on the old console. NVR replacement procedures instead include a supported shutdown and disk-move sequence, warn that recordings may not migrate, and instruct users not to add extra new disks during the initial move.
\nSource: Ubiquiti Help Center — Migrating Cameras Between NVRs.
\nApplies to the model-specific migration paths in UniFi’s current guide. Confirm the source and destination models before choosing a procedure; this article does not promise that every disk set is portable.
\nDSE recommends maintaining separate checklists for configuration continuity and footage preservation. Identify required historical clips and verify independent copies before stopping the old recorder. Record the exact migration path, approved backup, disk inventory, and rollback point. Do not combine a recorder replacement with an unplanned storage expansion. Keep the old system and required evidence under the agreed retention process until the owner accepts the new recorder and the preservation requirement has been satisfied.
\nAfter the approved migration, verify camera ownership, newly recorded playback, and restored administrative settings. Separately open the preserved historical clips from their intended destination. If the chosen supported path includes a disk move, confirm array readiness before adding disks. Document any missing history rather than interpreting restored camera names as proof of migrated recordings.
\nUbiquiti Help Center — Migrating Cameras Between NVRs. Reviewed October 15, 2026.
", "content_text": "Verify configuration continuity and historical footage preservation separately before retiring the old recorder.\nSource facts\nUniFi’s migration guide separates a Cloud Gateway-to-NVR move from replacement or upgraded NVR workflows. For a gateway move, the guide explicitly says recordings do not migrate, directs users to export clips they need, and restores a recent settings backup after stopping Protect on the old console. NVR replacement procedures instead include a supported shutdown and disk-move sequence, warn that recordings may not migrate, and instruct users not to add extra new disks during the initial move.\nSource: Ubiquiti Help Center — Migrating Cameras Between NVRs.\nApplicability\nApplies to the model-specific migration paths in UniFi’s current guide. Confirm the source and destination models before choosing a procedure; this article does not promise that every disk set is portable.\nDSE recommendation\nDSE recommends maintaining separate checklists for configuration continuity and footage preservation. Identify required historical clips and verify independent copies before stopping the old recorder. Record the exact migration path, approved backup, disk inventory, and rollback point. Do not combine a recorder replacement with an unplanned storage expansion. Keep the old system and required evidence under the agreed retention process until the owner accepts the new recorder and the preservation requirement has been satisfied.\nVerification\nAfter the approved migration, verify camera ownership, newly recorded playback, and restored administrative settings. Separately open the preserved historical clips from their intended destination. If the chosen supported path includes a disk move, confirm array readiness before adding disks. Document any missing history rather than interpreting restored camera names as proof of migrated recordings.\nOfficial reference\nUbiquiti Help Center — Migrating Cameras Between NVRs. Reviewed October 15, 2026.", "content_markdown": "Verify configuration continuity and historical footage preservation separately before retiring the old recorder.\n\n## Source facts\n\nUniFi’s migration guide separates a Cloud Gateway-to-NVR move from replacement or upgraded NVR workflows. For a gateway move, the guide explicitly says recordings do not migrate, directs users to export clips they need, and restores a recent settings backup after stopping Protect on the old console. NVR replacement procedures instead include a supported shutdown and disk-move sequence, warn that recordings may not migrate, and instruct users not to add extra new disks during the initial move.\n\nSource: [Ubiquiti Help Center — Migrating Cameras Between NVRs](https://help.ui.com/hc/en-us/articles/19118654419607-Migrating-Cameras-Between-NVRs).\n\n## Applicability\n\nApplies to the model-specific migration paths in UniFi’s current guide. Confirm the source and destination models before choosing a procedure; this article does not promise that every disk set is portable.\n\n## DSE recommendation\n\nDSE recommends maintaining separate checklists for configuration continuity and footage preservation. Identify required historical clips and verify independent copies before stopping the old recorder. Record the exact migration path, approved backup, disk inventory, and rollback point. Do not combine a recorder replacement with an unplanned storage expansion. Keep the old system and required evidence under the agreed retention process until the owner accepts the new recorder and the preservation requirement has been satisfied.\n\n## Verification\n\nAfter the approved migration, verify camera ownership, newly recorded playback, and restored administrative settings. Separately open the preserved historical clips from their intended destination. If the chosen supported path includes a disk move, confirm array readiness before adding disks. Document any missing history rather than interpreting restored camera names as proof of migrated recordings.\n\n## Official reference\n\n[Ubiquiti Help Center — Migrating Cameras Between NVRs](https://help.ui.com/hc/en-us/articles/19118654419607-Migrating-Cameras-Between-NVRs). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/set-up-each-recorder-before-adding-it-to-a-unifi-vantage-point/", "slug": "set-up-each-recorder-before-adding-it-to-a-unifi-vantage-point", "url": "https://update.dsesecurity.com/updates/set-up-each-recorder-before-adding-it-to-a-unifi-vantage-point/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/set-up-each-recorder-before-adding-it-to-a-unifi-vantage-point.md", "json": "https://update.dsesecurity.com/api/v1/posts/set-up-each-recorder-before-adding-it-to-a-unifi-vantage-point/" }, "title": "Set up each recorder before adding it to a UniFi Vantage Point", "summary": "Accept each recorder independently and preserve camera-to-recorder identity when building a combined management view.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:32:15+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 282, "potentially_affected": "Applies to the multi-NVR management workflow documented for UniFi Vantage Point. A combined management interface does not, by itself, establish that recordings are replicated between recorders or that their retention settings match.", "dse_recommendation": "DSE recommends commissioning each recorder independently before building the combined operator view.", "primary_source": { "name": "Ubiquiti Help Center — UniFi Vantage Point: Multi-NVR Camera Management", "url": "https://help.ui.com/hc/en-us/articles/27719500615959-UniFi-Vantage-Point-Multi-NVR-Camera-Management", "published_on": null, "authority": "help.ui.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Accept each recorder independently and preserve camera-to-recorder identity when building a combined management view.
\nUniFi Vantage Point combines management of up to five NVRs in one interface. Its guide describes cross-recorder live views, playback, custom multiviews, and settings management for consoles in one facility or different locations. Vantage Points appear under the Physical Security section of Site Manager. A new console must first be set up through its own web or mobile setup workflow before it can be added to an existing Vantage Point. Adding the combined view is therefore a separate step from initial recorder setup.
\nSource: Ubiquiti Help Center — UniFi Vantage Point: Multi-NVR Camera Management.
\nApplies to the multi-NVR management workflow documented for UniFi Vantage Point. A combined management interface does not, by itself, establish that recordings are replicated between recorders or that their retention settings match.
\nDSE recommends commissioning each recorder independently before building the combined operator view. Assign clear recorder and camera names, confirm the intended users and sites, and preserve an inventory that identifies where each camera records. Design multiviews around the operator’s task while retaining visible source identity. When making settings changes through the combined interface, review the target recorder set explicitly so a local change is not applied more broadly than intended.
\nOpen a camera from each enrolled recorder, verify live and historical viewing, and compare the combined inventory with each recorder’s own inventory. Test an approved limited settings change and inspect the intended target. Record any unavailable recorder separately rather than treating a partially populated multiview as proof that every recorder is healthy.
\nUbiquiti Help Center — UniFi Vantage Point: Multi-NVR Camera Management. Reviewed October 15, 2026.
", "content_text": "Accept each recorder independently and preserve camera-to-recorder identity when building a combined management view.\nSource facts\nUniFi Vantage Point combines management of up to five NVRs in one interface. Its guide describes cross-recorder live views, playback, custom multiviews, and settings management for consoles in one facility or different locations. Vantage Points appear under the Physical Security section of Site Manager. A new console must first be set up through its own web or mobile setup workflow before it can be added to an existing Vantage Point. Adding the combined view is therefore a separate step from initial recorder setup.\nSource: Ubiquiti Help Center — UniFi Vantage Point: Multi-NVR Camera Management.\nApplicability\nApplies to the multi-NVR management workflow documented for UniFi Vantage Point. A combined management interface does not, by itself, establish that recordings are replicated between recorders or that their retention settings match.\nDSE recommendation\nDSE recommends commissioning each recorder independently before building the combined operator view. Assign clear recorder and camera names, confirm the intended users and sites, and preserve an inventory that identifies where each camera records. Design multiviews around the operator’s task while retaining visible source identity. When making settings changes through the combined interface, review the target recorder set explicitly so a local change is not applied more broadly than intended.\nVerification\nOpen a camera from each enrolled recorder, verify live and historical viewing, and compare the combined inventory with each recorder’s own inventory. Test an approved limited settings change and inspect the intended target. Record any unavailable recorder separately rather than treating a partially populated multiview as proof that every recorder is healthy.\nOfficial reference\nUbiquiti Help Center — UniFi Vantage Point: Multi-NVR Camera Management. Reviewed October 15, 2026.", "content_markdown": "Accept each recorder independently and preserve camera-to-recorder identity when building a combined management view.\n\n## Source facts\n\nUniFi Vantage Point combines management of up to five NVRs in one interface. Its guide describes cross-recorder live views, playback, custom multiviews, and settings management for consoles in one facility or different locations. Vantage Points appear under the Physical Security section of Site Manager. A new console must first be set up through its own web or mobile setup workflow before it can be added to an existing Vantage Point. Adding the combined view is therefore a separate step from initial recorder setup.\n\nSource: [Ubiquiti Help Center — UniFi Vantage Point: Multi-NVR Camera Management](https://help.ui.com/hc/en-us/articles/27719500615959-UniFi-Vantage-Point-Multi-NVR-Camera-Management).\n\n## Applicability\n\nApplies to the multi-NVR management workflow documented for UniFi Vantage Point. A combined management interface does not, by itself, establish that recordings are replicated between recorders or that their retention settings match.\n\n## DSE recommendation\n\nDSE recommends commissioning each recorder independently before building the combined operator view. Assign clear recorder and camera names, confirm the intended users and sites, and preserve an inventory that identifies where each camera records. Design multiviews around the operator’s task while retaining visible source identity. When making settings changes through the combined interface, review the target recorder set explicitly so a local change is not applied more broadly than intended.\n\n## Verification\n\nOpen a camera from each enrolled recorder, verify live and historical viewing, and compare the combined inventory with each recorder’s own inventory. Test an approved limited settings change and inspect the intended target. Record any unavailable recorder separately rather than treating a partially populated multiview as proof that every recorder is healthy.\n\n## Official reference\n\n[Ubiquiti Help Center — UniFi Vantage Point: Multi-NVR Camera Management](https://help.ui.com/hc/en-us/articles/27719500615959-UniFi-Vantage-Point-Multi-NVR-Camera-Management). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/plan-on-site-recovery-before-disabling-teleport-for-remote-protect-cameras/", "slug": "plan-on-site-recovery-before-disabling-teleport-for-remote-protect-cameras", "url": "https://update.dsesecurity.com/updates/plan-on-site-recovery-before-disabling-teleport-for-remote-protect-cameras/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/plan-on-site-recovery-before-disabling-teleport-for-remote-protect-cameras.md", "json": "https://update.dsesecurity.com/api/v1/posts/plan-on-site-recovery-before-disabling-teleport-for-remote-protect-cameras/" }, "title": "Plan on-site recovery before disabling Teleport for remote Protect cameras", "summary": "Identify the technician and on-site recovery path before changing the remote cameras’ Teleport dependency.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:32:14+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 270, "potentially_affected": "Applies to Protect Teleport Adoption and the supported models listed in the current guide. Do not assume older or third-party cameras qualify, or that every camera has local edge-recording capability.", "dse_recommendation": "DSE recommends treating the Teleport setting as a recording dependency in the change inventory.", "primary_source": { "name": "Ubiquiti Help Center — UniFi Protect: Teleport Adoption", "url": "https://help.ui.com/hc/en-us/articles/43693427639319-UniFi-Protect-Teleport-Adoption", "published_on": null, "authority": "help.ui.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Identify the technician and on-site recovery path before changing the remote cameras’ Teleport dependency.
\nUniFi Protect Teleport Adoption records a remote camera to a destination gateway or NVR across the internet. The guide requires supported cameras, specified minimum software versions, a direct Teleport connection, and an administrator on both destination devices. It warns that disabling Teleport disconnects remote cameras and stops their recording to that destination. Turning it back on does not automatically reconnect them: setup must be repeated from the camera’s location. Already locally adopted cameras require a factory reset to switch to Teleport.
\nSource: Ubiquiti Help Center — UniFi Protect: Teleport Adoption.
\nApplies to Protect Teleport Adoption and the supported models listed in the current guide. Do not assume older or third-party cameras qualify, or that every camera has local edge-recording capability.
\nDSE recommends treating the Teleport setting as a recording dependency in the change inventory. Before disabling it or rebuilding the destination, identify remote entrances, on-site contacts, and an approved recovery visit. Agree which clips need preservation before any factory-reset transition and document the intended recording destination. Include uplink demand and outage expectations in the design review. Keep a local recovery procedure available to the technician who can physically reach the camera.
\nPilot the approved adoption workflow at a non-critical camera and confirm the selected recorder receives new footage. Record camera and destination versions and supported features. Rehearse the recovery steps as a planned test rather than disabling Teleport on production cameras without on-site assistance and an accepted recording interruption.
\nUbiquiti Help Center — UniFi Protect: Teleport Adoption. Reviewed October 15, 2026.
", "content_text": "Identify the technician and on-site recovery path before changing the remote cameras’ Teleport dependency.\nSource facts\nUniFi Protect Teleport Adoption records a remote camera to a destination gateway or NVR across the internet. The guide requires supported cameras, specified minimum software versions, a direct Teleport connection, and an administrator on both destination devices. It warns that disabling Teleport disconnects remote cameras and stops their recording to that destination. Turning it back on does not automatically reconnect them: setup must be repeated from the camera’s location. Already locally adopted cameras require a factory reset to switch to Teleport.\nSource: Ubiquiti Help Center — UniFi Protect: Teleport Adoption.\nApplicability\nApplies to Protect Teleport Adoption and the supported models listed in the current guide. Do not assume older or third-party cameras qualify, or that every camera has local edge-recording capability.\nDSE recommendation\nDSE recommends treating the Teleport setting as a recording dependency in the change inventory. Before disabling it or rebuilding the destination, identify remote entrances, on-site contacts, and an approved recovery visit. Agree which clips need preservation before any factory-reset transition and document the intended recording destination. Include uplink demand and outage expectations in the design review. Keep a local recovery procedure available to the technician who can physically reach the camera.\nVerification\nPilot the approved adoption workflow at a non-critical camera and confirm the selected recorder receives new footage. Record camera and destination versions and supported features. Rehearse the recovery steps as a planned test rather than disabling Teleport on production cameras without on-site assistance and an accepted recording interruption.\nOfficial reference\nUbiquiti Help Center — UniFi Protect: Teleport Adoption. Reviewed October 15, 2026.", "content_markdown": "Identify the technician and on-site recovery path before changing the remote cameras’ Teleport dependency.\n\n## Source facts\n\nUniFi Protect Teleport Adoption records a remote camera to a destination gateway or NVR across the internet. The guide requires supported cameras, specified minimum software versions, a direct Teleport connection, and an administrator on both destination devices. It warns that disabling Teleport disconnects remote cameras and stops their recording to that destination. Turning it back on does not automatically reconnect them: setup must be repeated from the camera’s location. Already locally adopted cameras require a factory reset to switch to Teleport.\n\nSource: [Ubiquiti Help Center — UniFi Protect: Teleport Adoption](https://help.ui.com/hc/en-us/articles/43693427639319-UniFi-Protect-Teleport-Adoption).\n\n## Applicability\n\nApplies to Protect Teleport Adoption and the supported models listed in the current guide. Do not assume older or third-party cameras qualify, or that every camera has local edge-recording capability.\n\n## DSE recommendation\n\nDSE recommends treating the Teleport setting as a recording dependency in the change inventory. Before disabling it or rebuilding the destination, identify remote entrances, on-site contacts, and an approved recovery visit. Agree which clips need preservation before any factory-reset transition and document the intended recording destination. Include uplink demand and outage expectations in the design review. Keep a local recovery procedure available to the technician who can physically reach the camera.\n\n## Verification\n\nPilot the approved adoption workflow at a non-critical camera and confirm the selected recorder receives new footage. Record camera and destination versions and supported features. Rehearse the recovery steps as a planned test rather than disabling Teleport on production cameras without on-site assistance and an accepted recording interruption.\n\n## Official reference\n\n[Ubiquiti Help Center — UniFi Protect: Teleport Adoption](https://help.ui.com/hc/en-us/articles/43693427639319-UniFi-Protect-Teleport-Adoption). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/prepare-ece-recovery-codes-before-normal-secret-access-is-lost/", "slug": "prepare-ece-recovery-codes-before-normal-secret-access-is-lost", "url": "https://update.dsesecurity.com/updates/prepare-ece-recovery-codes-before-normal-secret-access-is-lost/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/prepare-ece-recovery-codes-before-normal-secret-access-is-lost.md", "json": "https://update.dsesecurity.com/api/v1/posts/prepare-ece-recovery-codes-before-normal-secret-access-is-lost/" }, "title": "Prepare ECE recovery codes before normal secret access is lost", "summary": "Validate the administrator recovery path while normal access works, and keep recovery-code values out of tickets.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:50+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 269, "potentially_affected": "Applies to ECE account recovery in Verkada Command. A recovery code is distinct from an organization invitation, and this article does not guarantee recovery when all required key access has been lost.", "dse_recommendation": "DSE recommends completing recovery-code onboarding while normal access works.", "primary_source": { "name": "Verkada Help — Enterprise Controlled Encryption Account Recovery", "url": "https://help.verkada.com/command/security/enterprise-controlled-encryption/ece-account-recovery", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Validate the administrator recovery path while normal access works, and keep recovery-code values out of tickets.
\nVerkada ECE recovery codes provide another way for a user to decrypt the customer secret when normal access is unavailable. An account-specific code is emailed after the user accepts an invitation and sets a password, and remains valid until rotated or the account is deleted. An authorized Org Admin can send a new code, which invalidates the old one. Managing recovery codes requires access to the current customer secret and a validated administrator recovery code.
\nSource: Verkada Help — Enterprise Controlled Encryption Account Recovery.
\nApplies to ECE account recovery in Verkada Command. A recovery code is distinct from an organization invitation, and this article does not guarantee recovery when all required key access has been lost.
\nDSE recommends completing recovery-code onboarding while normal access works. Have each user store the code in an approved protected location and identify a trained administrator who has validated their own recovery path. Record readiness without collecting users’ codes into a general spreadsheet. Include recovery-code rotation when assessing a suspected disclosure and update the recovery instructions afterward. Do not wait for the only knowledgeable administrator to be locked out before discovering the prerequisite.
\nUse a disposable or explicitly approved test account to rehearse the documented recovery flow. Confirm the replacement code arrives through the intended channel and that the old code is invalidated when rotated. Keep the outcome and responsible owner in the record, while excluding code values and decrypted key material.
\nVerkada Help — Enterprise Controlled Encryption Account Recovery. Reviewed October 15, 2026.
", "content_text": "Validate the administrator recovery path while normal access works, and keep recovery-code values out of tickets.\nSource facts\nVerkada ECE recovery codes provide another way for a user to decrypt the customer secret when normal access is unavailable. An account-specific code is emailed after the user accepts an invitation and sets a password, and remains valid until rotated or the account is deleted. An authorized Org Admin can send a new code, which invalidates the old one. Managing recovery codes requires access to the current customer secret and a validated administrator recovery code.\nSource: Verkada Help — Enterprise Controlled Encryption Account Recovery.\nApplicability\nApplies to ECE account recovery in Verkada Command. A recovery code is distinct from an organization invitation, and this article does not guarantee recovery when all required key access has been lost.\nDSE recommendation\nDSE recommends completing recovery-code onboarding while normal access works. Have each user store the code in an approved protected location and identify a trained administrator who has validated their own recovery path. Record readiness without collecting users’ codes into a general spreadsheet. Include recovery-code rotation when assessing a suspected disclosure and update the recovery instructions afterward. Do not wait for the only knowledgeable administrator to be locked out before discovering the prerequisite.\nVerification\nUse a disposable or explicitly approved test account to rehearse the documented recovery flow. Confirm the replacement code arrives through the intended channel and that the old code is invalidated when rotated. Keep the outcome and responsible owner in the record, while excluding code values and decrypted key material.\nOfficial reference\nVerkada Help — Enterprise Controlled Encryption Account Recovery. Reviewed October 15, 2026.", "content_markdown": "Validate the administrator recovery path while normal access works, and keep recovery-code values out of tickets.\n\n## Source facts\n\nVerkada ECE recovery codes provide another way for a user to decrypt the customer secret when normal access is unavailable. An account-specific code is emailed after the user accepts an invitation and sets a password, and remains valid until rotated or the account is deleted. An authorized Org Admin can send a new code, which invalidates the old one. Managing recovery codes requires access to the current customer secret and a validated administrator recovery code.\n\nSource: [Verkada Help — Enterprise Controlled Encryption Account Recovery](https://help.verkada.com/command/security/enterprise-controlled-encryption/ece-account-recovery).\n\n## Applicability\n\nApplies to ECE account recovery in Verkada Command. A recovery code is distinct from an organization invitation, and this article does not guarantee recovery when all required key access has been lost.\n\n## DSE recommendation\n\nDSE recommends completing recovery-code onboarding while normal access works. Have each user store the code in an approved protected location and identify a trained administrator who has validated their own recovery path. Record readiness without collecting users’ codes into a general spreadsheet. Include recovery-code rotation when assessing a suspected disclosure and update the recovery instructions afterward. Do not wait for the only knowledgeable administrator to be locked out before discovering the prerequisite.\n\n## Verification\n\nUse a disposable or explicitly approved test account to rehearse the documented recovery flow. Confirm the replacement code arrives through the intended channel and that the old code is invalidated when rotated. Keep the outcome and responsible owner in the record, while excluding code values and decrypted key material.\n\n## Official reference\n\n[Verkada Help — Enterprise Controlled Encryption Account Recovery](https://help.verkada.com/command/security/enterprise-controlled-encryption/ece-account-recovery). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/resolve-backup-and-timelapse-dependencies-before-enabling-verkada-low-bandwidth-mode/", "slug": "resolve-backup-and-timelapse-dependencies-before-enabling-verkada-low-bandwidth-mode", "url": "https://update.dsesecurity.com/updates/resolve-backup-and-timelapse-dependencies-before-enabling-verkada-low-bandwidth-mode/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/resolve-backup-and-timelapse-dependencies-before-enabling-verkada-low-bandwidth-mode.md", "json": "https://update.dsesecurity.com/api/v1/posts/resolve-backup-and-timelapse-dependencies-before-enabling-verkada-low-bandwidth-mode/" }, "title": "Resolve backup and timelapse dependencies before enabling Verkada Low Bandwidth Mode", "summary": "Obtain an explicit decision on dependent backup and timelapse workflows before reducing camera bandwidth.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:49+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 261, "potentially_affected": "Applies to the Low Bandwidth Mode feature and dependencies documented for Verkada cameras. This article does not promise a particular percentage reduction, image quality, or storage-retention outcome.", "dse_recommendation": "DSE recommends checking backup and investigation requirements before approving this toggle at a constrained site.", "primary_source": { "name": "Verkada Help — Optimize Low Bandwidth Mode", "url": "https://help.verkada.com/verkada-cameras/configuration/camera-network-settings/optimize-low-bandwidth-mode", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Obtain an explicit decision on dependent backup and timelapse workflows before reducing camera bandwidth.
\nVerkada Low Bandwidth Mode changes more than live-stream bitrate. The documentation says cloud backup and timelapse cannot be used while the camera operates in this mode. It reduces non-motion thumbnail frequency and thumbnail size and quality, while motion thumbnails follow a different interval. Enabling the mode removes older cached thumbnails on the camera and uploads new ones from that point. Org Admins and Site Admins can apply it to an individual camera or multiple selected cameras.
\nSource: Verkada Help — Optimize Low Bandwidth Mode.
\nApplies to the Low Bandwidth Mode feature and dependencies documented for Verkada cameras. This article does not promise a particular percentage reduction, image quality, or storage-retention outcome.
\nDSE recommends checking backup and investigation requirements before approving this toggle at a constrained site. Have the footage owner explicitly accept any loss of cloud backup or timelapse and identify an alternative preservation approach if required. Change a limited pilot first and record when the thumbnail behavior changes. Keep the bandwidth objective separate from recording and backup acceptance; a quieter uplink alone does not demonstrate that the required incident workflow still works.
\nCompare the camera’s backup, timelapse, and thumbnail behavior before and after an approved pilot change. Run a representative history search and inspect the resulting views with an investigator. Measure the site’s actual network impact and document the accepted feature tradeoffs before applying the setting to more cameras.
\nVerkada Help — Optimize Low Bandwidth Mode. Reviewed October 15, 2026.
", "content_text": "Obtain an explicit decision on dependent backup and timelapse workflows before reducing camera bandwidth.\nSource facts\nVerkada Low Bandwidth Mode changes more than live-stream bitrate. The documentation says cloud backup and timelapse cannot be used while the camera operates in this mode. It reduces non-motion thumbnail frequency and thumbnail size and quality, while motion thumbnails follow a different interval. Enabling the mode removes older cached thumbnails on the camera and uploads new ones from that point. Org Admins and Site Admins can apply it to an individual camera or multiple selected cameras.\nSource: Verkada Help — Optimize Low Bandwidth Mode.\nApplicability\nApplies to the Low Bandwidth Mode feature and dependencies documented for Verkada cameras. This article does not promise a particular percentage reduction, image quality, or storage-retention outcome.\nDSE recommendation\nDSE recommends checking backup and investigation requirements before approving this toggle at a constrained site. Have the footage owner explicitly accept any loss of cloud backup or timelapse and identify an alternative preservation approach if required. Change a limited pilot first and record when the thumbnail behavior changes. Keep the bandwidth objective separate from recording and backup acceptance; a quieter uplink alone does not demonstrate that the required incident workflow still works.\nVerification\nCompare the camera’s backup, timelapse, and thumbnail behavior before and after an approved pilot change. Run a representative history search and inspect the resulting views with an investigator. Measure the site’s actual network impact and document the accepted feature tradeoffs before applying the setting to more cameras.\nOfficial reference\nVerkada Help — Optimize Low Bandwidth Mode. Reviewed October 15, 2026.", "content_markdown": "Obtain an explicit decision on dependent backup and timelapse workflows before reducing camera bandwidth.\n\n## Source facts\n\nVerkada Low Bandwidth Mode changes more than live-stream bitrate. The documentation says cloud backup and timelapse cannot be used while the camera operates in this mode. It reduces non-motion thumbnail frequency and thumbnail size and quality, while motion thumbnails follow a different interval. Enabling the mode removes older cached thumbnails on the camera and uploads new ones from that point. Org Admins and Site Admins can apply it to an individual camera or multiple selected cameras.\n\nSource: [Verkada Help — Optimize Low Bandwidth Mode](https://help.verkada.com/verkada-cameras/configuration/camera-network-settings/optimize-low-bandwidth-mode).\n\n## Applicability\n\nApplies to the Low Bandwidth Mode feature and dependencies documented for Verkada cameras. This article does not promise a particular percentage reduction, image quality, or storage-retention outcome.\n\n## DSE recommendation\n\nDSE recommends checking backup and investigation requirements before approving this toggle at a constrained site. Have the footage owner explicitly accept any loss of cloud backup or timelapse and identify an alternative preservation approach if required. Change a limited pilot first and record when the thumbnail behavior changes. Keep the bandwidth objective separate from recording and backup acceptance; a quieter uplink alone does not demonstrate that the required incident workflow still works.\n\n## Verification\n\nCompare the camera’s backup, timelapse, and thumbnail behavior before and after an approved pilot change. Run a representative history search and inspect the resulting views with an investigator. Measure the site’s actual network impact and document the accepted feature tradeoffs before applying the setting to more cameras.\n\n## Official reference\n\n[Verkada Help — Optimize Low Bandwidth Mode](https://help.verkada.com/verkada-cameras/configuration/camera-network-settings/optimize-low-bandwidth-mode). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/verify-ece-identity-provider-key-mapping-before-enrolling-cameras/", "slug": "verify-ece-identity-provider-key-mapping-before-enrolling-cameras", "url": "https://update.dsesecurity.com/updates/verify-ece-identity-provider-key-mapping-before-enrolling-cameras/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/verify-ece-identity-provider-key-mapping-before-enrolling-cameras.md", "json": "https://update.dsesecurity.com/api/v1/posts/verify-ece-identity-provider-key-mapping-before-enrolling-cameras/" }, "title": "Verify ECE identity-provider key mapping before enrolling cameras", "summary": "Make successful identity-provider key verification a release gate before enrolling cameras into ECE.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:48+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 262, "potentially_affected": "Applies to the documented Enterprise Controlled Encryption onboarding sequence. Identity-provider field mapping is provider-specific; this article is a rollout decision guide rather than a replacement for the vendor’s setup instructions.", "dse_recommendation": "DSE recommends treating the logout-and-test stage as a release gate before enrolling cameras.", "primary_source": { "name": "Verkada Help — Enable Enterprise Controlled Encryption", "url": "https://help.verkada.com/command/security/enterprise-controlled-encryption/enable-enterprise-controlled-encryption", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Make successful identity-provider key verification a release gate before enrolling cameras into ECE.
\nVerkada’s ECE enablement workflow requires OIDC single sign-on before camera enrollment. The documented identity providers are Okta, Microsoft Entra ID, and Google Workspace. The administrator generates and downloads an encryption key, maps it into the identity provider, logs out and tests the mapping, and then selects devices for enrollment. The guide instructs administrators to generate the key once and avoid regenerating it after verification. It also calls for current Command mobile apps before deployment.
\nSource: Verkada Help — Enable Enterprise Controlled Encryption.
\nApplies to the documented Enterprise Controlled Encryption onboarding sequence. Identity-provider field mapping is provider-specific; this article is a rollout decision guide rather than a replacement for the vendor’s setup instructions.
\nDSE recommends treating the logout-and-test stage as a release gate before enrolling cameras. Identify the identity owner, video owner, and protected storage location for the downloaded key. Pilot with representative users and supported mobile clients, including newly provisioned identities. Resolve any mapping failure before expanding enrollment. Make changes through an approved procedure and keep key material out of tickets, screenshots, and article examples. Coordinate recovery arrangements separately from routine enrollment.
\nUse the vendor’s verification step with an authorized pilot account and confirm the expected user receives the required mapping. Record a pass/fail result without recording the secret. Validate the selected pilot device and mobile workflow before extending enrollment, and seek vendor guidance rather than repeatedly generating replacement keys.
\nVerkada Help — Enable Enterprise Controlled Encryption. Reviewed October 15, 2026.
", "content_text": "Make successful identity-provider key verification a release gate before enrolling cameras into ECE.\nSource facts\nVerkada’s ECE enablement workflow requires OIDC single sign-on before camera enrollment. The documented identity providers are Okta, Microsoft Entra ID, and Google Workspace. The administrator generates and downloads an encryption key, maps it into the identity provider, logs out and tests the mapping, and then selects devices for enrollment. The guide instructs administrators to generate the key once and avoid regenerating it after verification. It also calls for current Command mobile apps before deployment.\nSource: Verkada Help — Enable Enterprise Controlled Encryption.\nApplicability\nApplies to the documented Enterprise Controlled Encryption onboarding sequence. Identity-provider field mapping is provider-specific; this article is a rollout decision guide rather than a replacement for the vendor’s setup instructions.\nDSE recommendation\nDSE recommends treating the logout-and-test stage as a release gate before enrolling cameras. Identify the identity owner, video owner, and protected storage location for the downloaded key. Pilot with representative users and supported mobile clients, including newly provisioned identities. Resolve any mapping failure before expanding enrollment. Make changes through an approved procedure and keep key material out of tickets, screenshots, and article examples. Coordinate recovery arrangements separately from routine enrollment.\nVerification\nUse the vendor’s verification step with an authorized pilot account and confirm the expected user receives the required mapping. Record a pass/fail result without recording the secret. Validate the selected pilot device and mobile workflow before extending enrollment, and seek vendor guidance rather than repeatedly generating replacement keys.\nOfficial reference\nVerkada Help — Enable Enterprise Controlled Encryption. Reviewed October 15, 2026.", "content_markdown": "Make successful identity-provider key verification a release gate before enrolling cameras into ECE.\n\n## Source facts\n\nVerkada’s ECE enablement workflow requires OIDC single sign-on before camera enrollment. The documented identity providers are Okta, Microsoft Entra ID, and Google Workspace. The administrator generates and downloads an encryption key, maps it into the identity provider, logs out and tests the mapping, and then selects devices for enrollment. The guide instructs administrators to generate the key once and avoid regenerating it after verification. It also calls for current Command mobile apps before deployment.\n\nSource: [Verkada Help — Enable Enterprise Controlled Encryption](https://help.verkada.com/command/security/enterprise-controlled-encryption/enable-enterprise-controlled-encryption).\n\n## Applicability\n\nApplies to the documented Enterprise Controlled Encryption onboarding sequence. Identity-provider field mapping is provider-specific; this article is a rollout decision guide rather than a replacement for the vendor’s setup instructions.\n\n## DSE recommendation\n\nDSE recommends treating the logout-and-test stage as a release gate before enrolling cameras. Identify the identity owner, video owner, and protected storage location for the downloaded key. Pilot with representative users and supported mobile clients, including newly provisioned identities. Resolve any mapping failure before expanding enrollment. Make changes through an approved procedure and keep key material out of tickets, screenshots, and article examples. Coordinate recovery arrangements separately from routine enrollment.\n\n## Verification\n\nUse the vendor’s verification step with an authorized pilot account and confirm the expected user receives the required mapping. Record a pass/fail result without recording the secret. Validate the selected pilot device and mobile workflow before extending enrollment, and seek vendor guidance rather than repeatedly generating replacement keys.\n\n## Official reference\n\n[Verkada Help — Enable Enterprise Controlled Encryption](https://help.verkada.com/command/security/enterprise-controlled-encryption/enable-enterprise-controlled-encryption). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/choose-whether-a-verkada-viewing-station-may-expose-historical-video/", "slug": "choose-whether-a-verkada-viewing-station-may-expose-historical-video", "url": "https://update.dsesecurity.com/updates/choose-whether-a-verkada-viewing-station-may-expose-historical-video/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/choose-whether-a-verkada-viewing-station-may-expose-historical-video.md", "json": "https://update.dsesecurity.com/api/v1/posts/choose-whether-a-verkada-viewing-station-may-expose-historical-video/" }, "title": "Choose whether a Verkada Viewing Station may expose historical video", "summary": "Approve the shared display’s audience before allowing its remote control to browse historical recordings.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:47+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 278, "potentially_affected": "Applies to Verkada Viewing Station configuration, including the VX52 workflow in the guide. This concerns the authority available at a shared physical display rather than a named browser user’s permissions.", "dse_recommendation": "DSE recommends approving the display’s audience before enabling history playback.", "primary_source": { "name": "Verkada Help — Set Up Your Viewing Station", "url": "https://help.verkada.com/viewing-station/configuration/set-up-your-viewing-station", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Approve the shared display’s audience before allowing its remote control to browse historical recordings.
\nVerkada Viewing Stations are claimed and managed by Org Admins and display configured camera tiles. The Enable History Playback setting permits a person at the display to scrub earlier footage with the remote; disabling it limits that station to live footage. A separate Enable Cloud Streaming setting is required for remote cameras when local video is unavailable. The configuration also includes offline notifications and a Test Offline Mode function, allowing the station’s viewing behavior to be evaluated separately from ordinary Command browser access.
\nSource: Verkada Help — Set Up Your Viewing Station.
\nApplies to Verkada Viewing Station configuration, including the VX52 workflow in the guide. This concerns the authority available at a shared physical display rather than a named browser user’s permissions.
\nDSE recommends approving the display’s audience before enabling history playback. Consider visitors, cleaners, and staff who can reach the screen or remote, and place sensitive cameras only on an appropriately controlled display. Decide whether remote camera viewing is needed and name recipients for station-offline alerts. Keep the layout and history setting in the station inventory. When copying another station’s configuration, reapprove the audience instead of assuming its location has identical privacy needs.
\nAt the actual display, verify whether the remote can enter history and whether each approved local and remote camera appears. Use the documented offline test during an agreed window and record which views remain available. Check that the designated alert recipient can recognize and respond to a station outage.
\nVerkada Help — Set Up Your Viewing Station. Reviewed October 15, 2026.
", "content_text": "Approve the shared display’s audience before allowing its remote control to browse historical recordings.\nSource facts\nVerkada Viewing Stations are claimed and managed by Org Admins and display configured camera tiles. The Enable History Playback setting permits a person at the display to scrub earlier footage with the remote; disabling it limits that station to live footage. A separate Enable Cloud Streaming setting is required for remote cameras when local video is unavailable. The configuration also includes offline notifications and a Test Offline Mode function, allowing the station’s viewing behavior to be evaluated separately from ordinary Command browser access.\nSource: Verkada Help — Set Up Your Viewing Station.\nApplicability\nApplies to Verkada Viewing Station configuration, including the VX52 workflow in the guide. This concerns the authority available at a shared physical display rather than a named browser user’s permissions.\nDSE recommendation\nDSE recommends approving the display’s audience before enabling history playback. Consider visitors, cleaners, and staff who can reach the screen or remote, and place sensitive cameras only on an appropriately controlled display. Decide whether remote camera viewing is needed and name recipients for station-offline alerts. Keep the layout and history setting in the station inventory. When copying another station’s configuration, reapprove the audience instead of assuming its location has identical privacy needs.\nVerification\nAt the actual display, verify whether the remote can enter history and whether each approved local and remote camera appears. Use the documented offline test during an agreed window and record which views remain available. Check that the designated alert recipient can recognize and respond to a station outage.\nOfficial reference\nVerkada Help — Set Up Your Viewing Station. Reviewed October 15, 2026.", "content_markdown": "Approve the shared display’s audience before allowing its remote control to browse historical recordings.\n\n## Source facts\n\nVerkada Viewing Stations are claimed and managed by Org Admins and display configured camera tiles. The Enable History Playback setting permits a person at the display to scrub earlier footage with the remote; disabling it limits that station to live footage. A separate Enable Cloud Streaming setting is required for remote cameras when local video is unavailable. The configuration also includes offline notifications and a Test Offline Mode function, allowing the station’s viewing behavior to be evaluated separately from ordinary Command browser access.\n\nSource: [Verkada Help — Set Up Your Viewing Station](https://help.verkada.com/viewing-station/configuration/set-up-your-viewing-station).\n\n## Applicability\n\nApplies to Verkada Viewing Station configuration, including the VX52 workflow in the guide. This concerns the authority available at a shared physical display rather than a named browser user’s permissions.\n\n## DSE recommendation\n\nDSE recommends approving the display’s audience before enabling history playback. Consider visitors, cleaners, and staff who can reach the screen or remote, and place sensitive cameras only on an appropriately controlled display. Decide whether remote camera viewing is needed and name recipients for station-offline alerts. Keep the layout and history setting in the station inventory. When copying another station’s configuration, reapprove the audience instead of assuming its location has identical privacy needs.\n\n## Verification\n\nAt the actual display, verify whether the remote can enter history and whether each approved local and remote camera appears. Use the documented offline test during an agreed window and record which views remain available. Check that the designated alert recipient can recognize and respond to a station outage.\n\n## Official reference\n\n[Verkada Help — Set Up Your Viewing Station](https://help.verkada.com/viewing-station/configuration/set-up-your-viewing-station). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/prepare-camera-addressing-and-stream-profiles-before-command-connector-adoption/", "slug": "prepare-camera-addressing-and-stream-profiles-before-command-connector-adoption", "url": "https://update.dsesecurity.com/updates/prepare-camera-addressing-and-stream-profiles-before-command-connector-adoption/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/prepare-camera-addressing-and-stream-profiles-before-command-connector-adoption.md", "json": "https://update.dsesecurity.com/api/v1/posts/prepare-camera-addressing-and-stream-profiles-before-command-connector-adoption/" }, "title": "Prepare camera addressing and stream profiles before Command Connector adoption", "summary": "Reserve camera addresses and review connector-created accounts and selected profiles before accepting third-party adoption.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:46+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 269, "potentially_affected": "Applies specifically to the Command Connector adoption workflow and its documented camera compatibility requirements. It does not establish that every ONVIF model is supported or that existing VMS profiles are untouched.", "dse_recommendation": "DSE recommends reviewing camera configuration ownership before onboarding.", "primary_source": { "name": "Verkada Help — Add a non-Verkada camera to a Command Connector", "url": "https://help.verkada.com/command-connector/configuration/add-a-non-verkada-camera-to-a-command-connector", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Reserve camera addresses and review connector-created accounts and selected profiles before accepting third-party adoption.
\nVerkada Command Connector communicates with third-party cameras by IP address, so an address change can interrupt streaming. Its guide requires a static address or DHCP reservation and excludes dynamic NAT or Layer 3 translation between connector and camera. Only I- and P-frames are supported, not B-frames. ONVIF adoption creates a camera administrator account. Optimal streaming-profile selection creates high- and standard-quality profiles for each channel; Manufacturer mode instead uses profiles already on the camera.
\nSource: Verkada Help — Add a non-Verkada camera to a Command Connector.
\nApplies specifically to the Command Connector adoption workflow and its documented camera compatibility requirements. It does not establish that every ONVIF model is supported or that existing VMS profiles are untouched.
\nDSE recommends reviewing camera configuration ownership before onboarding. Reserve addresses, identify existing integrations, and agree who may manage the account and stream profiles. Save the approved pre-change settings and confirm the camera’s encoding and selected profile mode before beginning. Pilot a representative multi-sensor device if the deployment includes them. Treat an IP change as a coordinated connector change and keep the camera inventory synchronized with the connector’s channel records.
\nAfter adoption, inspect the account and created or reused media profiles through the camera’s approved administration interface. Play each expected sensor channel in Command and confirm any pre-existing VMS still works. Record the actual address and frame configuration; discovering a device on the network is not complete integration verification.
\nVerkada Help — Add a non-Verkada camera to a Command Connector. Reviewed October 15, 2026.
", "content_text": "Reserve camera addresses and review connector-created accounts and selected profiles before accepting third-party adoption.\nSource facts\nVerkada Command Connector communicates with third-party cameras by IP address, so an address change can interrupt streaming. Its guide requires a static address or DHCP reservation and excludes dynamic NAT or Layer 3 translation between connector and camera. Only I- and P-frames are supported, not B-frames. ONVIF adoption creates a camera administrator account. Optimal streaming-profile selection creates high- and standard-quality profiles for each channel; Manufacturer mode instead uses profiles already on the camera.\nSource: Verkada Help — Add a non-Verkada camera to a Command Connector.\nApplicability\nApplies specifically to the Command Connector adoption workflow and its documented camera compatibility requirements. It does not establish that every ONVIF model is supported or that existing VMS profiles are untouched.\nDSE recommendation\nDSE recommends reviewing camera configuration ownership before onboarding. Reserve addresses, identify existing integrations, and agree who may manage the account and stream profiles. Save the approved pre-change settings and confirm the camera’s encoding and selected profile mode before beginning. Pilot a representative multi-sensor device if the deployment includes them. Treat an IP change as a coordinated connector change and keep the camera inventory synchronized with the connector’s channel records.\nVerification\nAfter adoption, inspect the account and created or reused media profiles through the camera’s approved administration interface. Play each expected sensor channel in Command and confirm any pre-existing VMS still works. Record the actual address and frame configuration; discovering a device on the network is not complete integration verification.\nOfficial reference\nVerkada Help — Add a non-Verkada camera to a Command Connector. Reviewed October 15, 2026.", "content_markdown": "Reserve camera addresses and review connector-created accounts and selected profiles before accepting third-party adoption.\n\n## Source facts\n\nVerkada Command Connector communicates with third-party cameras by IP address, so an address change can interrupt streaming. Its guide requires a static address or DHCP reservation and excludes dynamic NAT or Layer 3 translation between connector and camera. Only I- and P-frames are supported, not B-frames. ONVIF adoption creates a camera administrator account. Optimal streaming-profile selection creates high- and standard-quality profiles for each channel; Manufacturer mode instead uses profiles already on the camera.\n\nSource: [Verkada Help — Add a non-Verkada camera to a Command Connector](https://help.verkada.com/command-connector/configuration/add-a-non-verkada-camera-to-a-command-connector).\n\n## Applicability\n\nApplies specifically to the Command Connector adoption workflow and its documented camera compatibility requirements. It does not establish that every ONVIF model is supported or that existing VMS profiles are untouched.\n\n## DSE recommendation\n\nDSE recommends reviewing camera configuration ownership before onboarding. Reserve addresses, identify existing integrations, and agree who may manage the account and stream profiles. Save the approved pre-change settings and confirm the camera’s encoding and selected profile mode before beginning. Pilot a representative multi-sensor device if the deployment includes them. Treat an IP change as a coordinated connector change and keep the camera inventory synchronized with the connector’s channel records.\n\n## Verification\n\nAfter adoption, inspect the account and created or reused media profiles through the camera’s approved administration interface. Play each expected sensor channel in Command and confirm any pre-existing VMS still works. Record the actual address and frame configuration; discovering a device on the network is not complete integration verification.\n\n## Official reference\n\n[Verkada Help — Add a non-Verkada camera to a Command Connector](https://help.verkada.com/command-connector/configuration/add-a-non-verkada-camera-to-a-command-connector). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/trace-verkada-local-streaming-through-the-camera-private-address/", "slug": "trace-verkada-local-streaming-through-the-camera-private-address", "url": "https://update.dsesecurity.com/updates/trace-verkada-local-streaming-through-the-camera-private-address/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/trace-verkada-local-streaming-through-the-camera-private-address.md", "json": "https://update.dsesecurity.com/api/v1/posts/trace-verkada-local-streaming-through-the-camera-private-address/" }, "title": "Trace Verkada local streaming through the camera private address", "summary": "Trace the approved client-to-camera network path before widening rules to fix a cloud-only viewing session.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:45+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 269, "potentially_affected": "Applies to Verkada Command local streaming, including routed client networks with approved camera reachability. This is a streaming-path diagnosis, not permission to open a camera VLAN to all endpoints.", "dse_recommendation": "DSE recommends tracing one authorized viewer-to-camera path before widening firewall rules.", "primary_source": { "name": "Verkada Help — Local Streaming on Verkada Cameras", "url": "https://help.verkada.com/verkada-cameras/video-streaming-and-sharing/live-streaming/local-streaming-on-verkada-cameras", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Trace the approved client-to-camera network path before widening rules to fix a cloud-only viewing session.
\nVerkada local streaming sends the camera feed directly to the viewing device instead of proxying it through the cloud. The client must reach the camera’s private address, and the documentation requires bidirectional TCP/UDP port 4100 connectivity without an intervening proxy. Command uses a camera-specific DNS name that resolves to the camera’s private IPv4 address. If the client cannot establish that local connection, viewing may remain remote. H.265 client support can also distinguish available standard- and high-quality local streams.
\nSource: Verkada Help — Local Streaming on Verkada Cameras.
\nApplies to Verkada Command local streaming, including routed client networks with approved camera reachability. This is a streaming-path diagnosis, not permission to open a camera VLAN to all endpoints.
\nDSE recommends tracing one authorized viewer-to-camera path before widening firewall rules. Record the resolved private address, client network, relevant rule, and whether a proxy is present. Use the camera’s actual Command metadata when checking address consistency. If local viewing is an operational requirement, approve a specific viewer group and network path; keep cloud viewing behavior separate in the acceptance record. Evaluate codec support only after basic reachability is established.
\nOpen a test camera from the intended workstation and inspect the local/remote streaming indicator. Compare DNS resolution and connection attempts with the camera’s private address. Repeat from an authorized routed network and a remote connection so the team can recognize a path change without assuming the camera failed.
\nVerkada Help — Local Streaming on Verkada Cameras. Reviewed October 15, 2026.
", "content_text": "Trace the approved client-to-camera network path before widening rules to fix a cloud-only viewing session.\nSource facts\nVerkada local streaming sends the camera feed directly to the viewing device instead of proxying it through the cloud. The client must reach the camera’s private address, and the documentation requires bidirectional TCP/UDP port 4100 connectivity without an intervening proxy. Command uses a camera-specific DNS name that resolves to the camera’s private IPv4 address. If the client cannot establish that local connection, viewing may remain remote. H.265 client support can also distinguish available standard- and high-quality local streams.\nSource: Verkada Help — Local Streaming on Verkada Cameras.\nApplicability\nApplies to Verkada Command local streaming, including routed client networks with approved camera reachability. This is a streaming-path diagnosis, not permission to open a camera VLAN to all endpoints.\nDSE recommendation\nDSE recommends tracing one authorized viewer-to-camera path before widening firewall rules. Record the resolved private address, client network, relevant rule, and whether a proxy is present. Use the camera’s actual Command metadata when checking address consistency. If local viewing is an operational requirement, approve a specific viewer group and network path; keep cloud viewing behavior separate in the acceptance record. Evaluate codec support only after basic reachability is established.\nVerification\nOpen a test camera from the intended workstation and inspect the local/remote streaming indicator. Compare DNS resolution and connection attempts with the camera’s private address. Repeat from an authorized routed network and a remote connection so the team can recognize a path change without assuming the camera failed.\nOfficial reference\nVerkada Help — Local Streaming on Verkada Cameras. Reviewed October 15, 2026.", "content_markdown": "Trace the approved client-to-camera network path before widening rules to fix a cloud-only viewing session.\n\n## Source facts\n\nVerkada local streaming sends the camera feed directly to the viewing device instead of proxying it through the cloud. The client must reach the camera’s private address, and the documentation requires bidirectional TCP/UDP port 4100 connectivity without an intervening proxy. Command uses a camera-specific DNS name that resolves to the camera’s private IPv4 address. If the client cannot establish that local connection, viewing may remain remote. H.265 client support can also distinguish available standard- and high-quality local streams.\n\nSource: [Verkada Help — Local Streaming on Verkada Cameras](https://help.verkada.com/verkada-cameras/video-streaming-and-sharing/live-streaming/local-streaming-on-verkada-cameras).\n\n## Applicability\n\nApplies to Verkada Command local streaming, including routed client networks with approved camera reachability. This is a streaming-path diagnosis, not permission to open a camera VLAN to all endpoints.\n\n## DSE recommendation\n\nDSE recommends tracing one authorized viewer-to-camera path before widening firewall rules. Record the resolved private address, client network, relevant rule, and whether a proxy is present. Use the camera’s actual Command metadata when checking address consistency. If local viewing is an operational requirement, approve a specific viewer group and network path; keep cloud viewing behavior separate in the acceptance record. Evaluate codec support only after basic reachability is established.\n\n## Verification\n\nOpen a test camera from the intended workstation and inspect the local/remote streaming indicator. Compare DNS resolution and connection attempts with the camera’s private address. Repeat from an authorized routed network and a remote connection so the team can recognize a path change without assuming the camera failed.\n\n## Official reference\n\n[Verkada Help — Local Streaming on Verkada Cameras](https://help.verkada.com/verkada-cameras/video-streaming-and-sharing/live-streaming/local-streaming-on-verkada-cameras). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/account-for-per-camera-overrides-when-changing-verkada-cloud-storage-regions/", "slug": "account-for-per-camera-overrides-when-changing-verkada-cloud-storage-regions", "url": "https://update.dsesecurity.com/updates/account-for-per-camera-overrides-when-changing-verkada-cloud-storage-regions/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/account-for-per-camera-overrides-when-changing-verkada-cloud-storage-regions.md", "json": "https://update.dsesecurity.com/api/v1/posts/account-for-per-camera-overrides-when-changing-verkada-cloud-storage-regions/" }, "title": "Account for per-camera overrides when changing Verkada cloud storage regions", "summary": "Review camera overrides and historical uploads before reporting a cloud-storage region change as complete.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:44+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 260, "potentially_affected": "Applies to Verkada camera image and video cloud storage settings. This article does not determine contractual residency obligations or assert that a region change moves or deletes existing data.", "dse_recommendation": "DSE recommends building a camera-by-camera residency worksheet before changing the default.", "primary_source": { "name": "Verkada Help — Set Data Storage Location", "url": "https://help.verkada.com/command/security/privacy-and-security-disclosure/set-a-default-or-camera-specific-location-for-image-and-video-data-storage-and-processing", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Review camera overrides and historical uploads before reporting a cloud-storage region change as complete.
\nVerkada allows an organization default for cloud storage of camera image and video data and a per-camera selection. The per-camera setting takes precedence over the organization default. The documented region change is not retroactive: only data uploaded after the selection uses the new location. For storage-only regions, including Canada and South Korea, processing remains in the organization’s primary processing region: United States, European Union, or Australia. A single organization-level dropdown therefore does not describe every camera or every existing upload.
\nSource: Verkada Help — Set Data Storage Location.
\nApplies to Verkada camera image and video cloud storage settings. This article does not determine contractual residency obligations or assert that a region change moves or deletes existing data.
\nDSE recommends building a camera-by-camera residency worksheet before changing the default. Record explicit overrides, the approved region, the effective change time, and how pre-change uploads will be handled. Have the responsible privacy or contract owner evaluate processing separately from storage. Do not report the entire organization as migrated merely because the default was saved. Include new cameras in the review so inherited settings and deliberate exceptions remain distinguishable.
\nInspect a sample of explicitly overridden cameras and cameras intended to inherit the default. Retain configuration evidence and the change time. Ask the vendor to clarify any unresolved historical-data requirement before claiming completion; a newly selected region alone cannot prove that older uploads were relocated.
\nVerkada Help — Set Data Storage Location. Reviewed October 15, 2026.
", "content_text": "Review camera overrides and historical uploads before reporting a cloud-storage region change as complete.\nSource facts\nVerkada allows an organization default for cloud storage of camera image and video data and a per-camera selection. The per-camera setting takes precedence over the organization default. The documented region change is not retroactive: only data uploaded after the selection uses the new location. For storage-only regions, including Canada and South Korea, processing remains in the organization’s primary processing region: United States, European Union, or Australia. A single organization-level dropdown therefore does not describe every camera or every existing upload.\nSource: Verkada Help — Set Data Storage Location.\nApplicability\nApplies to Verkada camera image and video cloud storage settings. This article does not determine contractual residency obligations or assert that a region change moves or deletes existing data.\nDSE recommendation\nDSE recommends building a camera-by-camera residency worksheet before changing the default. Record explicit overrides, the approved region, the effective change time, and how pre-change uploads will be handled. Have the responsible privacy or contract owner evaluate processing separately from storage. Do not report the entire organization as migrated merely because the default was saved. Include new cameras in the review so inherited settings and deliberate exceptions remain distinguishable.\nVerification\nInspect a sample of explicitly overridden cameras and cameras intended to inherit the default. Retain configuration evidence and the change time. Ask the vendor to clarify any unresolved historical-data requirement before claiming completion; a newly selected region alone cannot prove that older uploads were relocated.\nOfficial reference\nVerkada Help — Set Data Storage Location. Reviewed October 15, 2026.", "content_markdown": "Review camera overrides and historical uploads before reporting a cloud-storage region change as complete.\n\n## Source facts\n\nVerkada allows an organization default for cloud storage of camera image and video data and a per-camera selection. The per-camera setting takes precedence over the organization default. The documented region change is not retroactive: only data uploaded after the selection uses the new location. For storage-only regions, including Canada and South Korea, processing remains in the organization’s primary processing region: United States, European Union, or Australia. A single organization-level dropdown therefore does not describe every camera or every existing upload.\n\nSource: [Verkada Help — Set Data Storage Location](https://help.verkada.com/command/security/privacy-and-security-disclosure/set-a-default-or-camera-specific-location-for-image-and-video-data-storage-and-processing).\n\n## Applicability\n\nApplies to Verkada camera image and video cloud storage settings. This article does not determine contractual residency obligations or assert that a region change moves or deletes existing data.\n\n## DSE recommendation\n\nDSE recommends building a camera-by-camera residency worksheet before changing the default. Record explicit overrides, the approved region, the effective change time, and how pre-change uploads will be handled. Have the responsible privacy or contract owner evaluate processing separately from storage. Do not report the entire organization as migrated merely because the default was saved. Include new cameras in the review so inherited settings and deliberate exceptions remain distinguishable.\n\n## Verification\n\nInspect a sample of explicitly overridden cameras and cameras intended to inherit the default. Retain configuration evidence and the change time. Ask the vendor to clarify any unresolved historical-data requirement before claiming completion; a newly selected region alone cannot prove that older uploads were relocated.\n\n## Official reference\n\n[Verkada Help — Set Data Storage Location](https://help.verkada.com/command/security/privacy-and-security-disclosure/set-a-default-or-camera-specific-location-for-image-and-video-data-storage-and-processing). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/treat-a-new-verkada-privacy-region-as-a-forward-only-recording-change/", "slug": "treat-a-new-verkada-privacy-region-as-a-forward-only-recording-change", "url": "https://update.dsesecurity.com/updates/treat-a-new-verkada-privacy-region-as-a-forward-only-recording-change/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/treat-a-new-verkada-privacy-region-as-a-forward-only-recording-change.md", "json": "https://update.dsesecurity.com/api/v1/posts/treat-a-new-verkada-privacy-region-as-a-forward-only-recording-change/" }, "title": "Treat a new Verkada privacy region as a forward-only recording change", "summary": "Record when a privacy mask takes effect and handle older footage through a separate disclosure decision.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:43+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 257, "potentially_affected": "Applies to camera-side Verkada privacy regions, not a later redaction of an already recorded or exported clip. Check the current model list before designing a masked area.", "dse_recommendation": "DSE recommends recording the activation time and the intended protected boundary, then treating older footage as a separate privacy review.", "primary_source": { "name": "Verkada Help — Privacy Regions", "url": "https://help.verkada.com/verkada-cameras/configuration/security-and-privacy/privacy-regions", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Record when a privacy mask takes effect and handle older footage through a separate disclosure decision.
\nVerkada privacy regions block selected parts of the camera view in live video and historical recordings made after configuration. The documentation explicitly states that privacy regions are not retroactive and that configuration can take time to reach the camera. Site Admin permissions are required. Support and region granularity vary by model: the guide excludes D80 and PTZ cameras and distinguishes basic from granular regions on other models. Removing a region is a separate administrative change.
\nSource: Verkada Help — Privacy Regions.
\nApplies to camera-side Verkada privacy regions, not a later redaction of an already recorded or exported clip. Check the current model list before designing a masked area.
\nDSE recommends recording the activation time and the intended protected boundary, then treating older footage as a separate privacy review. Use an approved non-sensitive target when checking mask coverage and include any camera movement or orientation change in the review. If existing footage contains material that should not be disclosed, obtain a specific redaction or access decision rather than representing the new mask as a historical correction. Assign ownership for future mask changes.
\nAfter the configuration has reached the camera, inspect live video and newly recorded history at the protected boundary. Compare a pre-change interval only with proper authorization to demonstrate the time boundary. Document the exact model and observed mask edges, including any parts of the scene still visible.
\nVerkada Help — Privacy Regions. Reviewed October 15, 2026.
", "content_text": "Record when a privacy mask takes effect and handle older footage through a separate disclosure decision.\nSource facts\nVerkada privacy regions block selected parts of the camera view in live video and historical recordings made after configuration. The documentation explicitly states that privacy regions are not retroactive and that configuration can take time to reach the camera. Site Admin permissions are required. Support and region granularity vary by model: the guide excludes D80 and PTZ cameras and distinguishes basic from granular regions on other models. Removing a region is a separate administrative change.\nSource: Verkada Help — Privacy Regions.\nApplicability\nApplies to camera-side Verkada privacy regions, not a later redaction of an already recorded or exported clip. Check the current model list before designing a masked area.\nDSE recommendation\nDSE recommends recording the activation time and the intended protected boundary, then treating older footage as a separate privacy review. Use an approved non-sensitive target when checking mask coverage and include any camera movement or orientation change in the review. If existing footage contains material that should not be disclosed, obtain a specific redaction or access decision rather than representing the new mask as a historical correction. Assign ownership for future mask changes.\nVerification\nAfter the configuration has reached the camera, inspect live video and newly recorded history at the protected boundary. Compare a pre-change interval only with proper authorization to demonstrate the time boundary. Document the exact model and observed mask edges, including any parts of the scene still visible.\nOfficial reference\nVerkada Help — Privacy Regions. Reviewed October 15, 2026.", "content_markdown": "Record when a privacy mask takes effect and handle older footage through a separate disclosure decision.\n\n## Source facts\n\nVerkada privacy regions block selected parts of the camera view in live video and historical recordings made after configuration. The documentation explicitly states that privacy regions are not retroactive and that configuration can take time to reach the camera. Site Admin permissions are required. Support and region granularity vary by model: the guide excludes D80 and PTZ cameras and distinguishes basic from granular regions on other models. Removing a region is a separate administrative change.\n\nSource: [Verkada Help — Privacy Regions](https://help.verkada.com/verkada-cameras/configuration/security-and-privacy/privacy-regions).\n\n## Applicability\n\nApplies to camera-side Verkada privacy regions, not a later redaction of an already recorded or exported clip. Check the current model list before designing a masked area.\n\n## DSE recommendation\n\nDSE recommends recording the activation time and the intended protected boundary, then treating older footage as a separate privacy review. Use an approved non-sensitive target when checking mask coverage and include any camera movement or orientation change in the review. If existing footage contains material that should not be disclosed, obtain a specific redaction or access decision rather than representing the new mask as a historical correction. Assign ownership for future mask changes.\n\n## Verification\n\nAfter the configuration has reached the camera, inspect live video and newly recorded history at the protected boundary. Compare a pre-change interval only with proper authorization to demonstrate the time boundary. Document the exact model and observed mask edges, including any parts of the scene still visible.\n\n## Official reference\n\n[Verkada Help — Privacy Regions](https://help.verkada.com/verkada-cameras/configuration/security-and-privacy/privacy-regions). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/check-verkada-ece-feature-compatibility-before-promising-a-video-api-integration/", "slug": "check-verkada-ece-feature-compatibility-before-promising-a-video-api-integration", "url": "https://update.dsesecurity.com/updates/check-verkada-ece-feature-compatibility-before-promising-a-video-api-integration/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-verkada-ece-feature-compatibility-before-promising-a-video-api-integration.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-verkada-ece-feature-compatibility-before-promising-a-video-api-integration/" }, "title": "Check Verkada ECE feature compatibility before promising a video API integration", "summary": "Separate event metadata from media retrieval when assessing an integration that will depend on ECE cameras.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:42+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 273, "potentially_affected": "Applies to the ECE feature compatibility matrix reviewed for this article. Recheck the live matrix for the exact feature and device before enrollment; this is not a claim about every API endpoint.", "dse_recommendation": "DSE recommends inventorying integrations by the data they retrieve before proposing ECE enrollment.", "primary_source": { "name": "Verkada Help — Enterprise Controlled Encryption Device & Feature Compatibility", "url": "https://help.verkada.com/verkada-cameras/configuration/security-and-privacy/enterprise-controlled-encryption-device-feature-compatibility", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Separate event metadata from media retrieval when assessing an integration that will depend on ECE cameras.
\nVerkada publishes an Enterprise Controlled Encryption compatibility matrix that distinguishes encrypted operation, Cloud Assist, ordinary compatibility, and unsupported features. The matrix lists the video, audio, and image API as incompatible while metadata/configuration API functions and metadata-only webhooks are compatible. It also distinguishes local Viewing Station streaming from cloud and history viewing. A camera’s ECE enrollment therefore cannot be evaluated solely by whether its live view opens; dependent integration functions have their own documented status.
\nSource: Verkada Help — Enterprise Controlled Encryption Device & Feature Compatibility.
\nApplies to the ECE feature compatibility matrix reviewed for this article. Recheck the live matrix for the exact feature and device before enrollment; this is not a claim about every API endpoint.
\nDSE recommends inventorying integrations by the data they retrieve before proposing ECE enrollment. Separate a webhook that announces an event from a process that downloads its associated image or video. Ask the application owner to approve any lost function and assess the documented Cloud Assist category explicitly. Pilot with representative users, viewers, and integrations before changing a fleet. Keep the compatibility decision with the enrollment record so a future integration owner can understand the constraints.
\nExercise a harmless test event through each approved integration and verify both metadata delivery and any required media retrieval. Compare actual results with the matrix categories and document unsupported needs. Stop the rollout if the workflow depends on a media function the vendor marks incompatible.
\nVerkada Help — Enterprise Controlled Encryption Device & Feature Compatibility. Reviewed October 15, 2026.
", "content_text": "Separate event metadata from media retrieval when assessing an integration that will depend on ECE cameras.\nSource facts\nVerkada publishes an Enterprise Controlled Encryption compatibility matrix that distinguishes encrypted operation, Cloud Assist, ordinary compatibility, and unsupported features. The matrix lists the video, audio, and image API as incompatible while metadata/configuration API functions and metadata-only webhooks are compatible. It also distinguishes local Viewing Station streaming from cloud and history viewing. A camera’s ECE enrollment therefore cannot be evaluated solely by whether its live view opens; dependent integration functions have their own documented status.\nSource: Verkada Help — Enterprise Controlled Encryption Device & Feature Compatibility.\nApplicability\nApplies to the ECE feature compatibility matrix reviewed for this article. Recheck the live matrix for the exact feature and device before enrollment; this is not a claim about every API endpoint.\nDSE recommendation\nDSE recommends inventorying integrations by the data they retrieve before proposing ECE enrollment. Separate a webhook that announces an event from a process that downloads its associated image or video. Ask the application owner to approve any lost function and assess the documented Cloud Assist category explicitly. Pilot with representative users, viewers, and integrations before changing a fleet. Keep the compatibility decision with the enrollment record so a future integration owner can understand the constraints.\nVerification\nExercise a harmless test event through each approved integration and verify both metadata delivery and any required media retrieval. Compare actual results with the matrix categories and document unsupported needs. Stop the rollout if the workflow depends on a media function the vendor marks incompatible.\nOfficial reference\nVerkada Help — Enterprise Controlled Encryption Device & Feature Compatibility. Reviewed October 15, 2026.", "content_markdown": "Separate event metadata from media retrieval when assessing an integration that will depend on ECE cameras.\n\n## Source facts\n\nVerkada publishes an Enterprise Controlled Encryption compatibility matrix that distinguishes encrypted operation, Cloud Assist, ordinary compatibility, and unsupported features. The matrix lists the video, audio, and image API as incompatible while metadata/configuration API functions and metadata-only webhooks are compatible. It also distinguishes local Viewing Station streaming from cloud and history viewing. A camera’s ECE enrollment therefore cannot be evaluated solely by whether its live view opens; dependent integration functions have their own documented status.\n\nSource: [Verkada Help — Enterprise Controlled Encryption Device & Feature Compatibility](https://help.verkada.com/verkada-cameras/configuration/security-and-privacy/enterprise-controlled-encryption-device-feature-compatibility).\n\n## Applicability\n\nApplies to the ECE feature compatibility matrix reviewed for this article. Recheck the live matrix for the exact feature and device before enrollment; this is not a claim about every API endpoint.\n\n## DSE recommendation\n\nDSE recommends inventorying integrations by the data they retrieve before proposing ECE enrollment. Separate a webhook that announces an event from a process that downloads its associated image or video. Ask the application owner to approve any lost function and assess the documented Cloud Assist category explicitly. Pilot with representative users, viewers, and integrations before changing a fleet. Keep the compatibility decision with the enrollment record so a future integration owner can understand the constraints.\n\n## Verification\n\nExercise a harmless test event through each approved integration and verify both metadata delivery and any required media retrieval. Compare actual results with the matrix categories and document unsupported needs. Stop the rollout if the workflow depends on a media function the vendor marks incompatible.\n\n## Official reference\n\n[Verkada Help — Enterprise Controlled Encryption Device & Feature Compatibility](https://help.verkada.com/verkada-cameras/configuration/security-and-privacy/enterprise-controlled-encryption-device-feature-compatibility). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/configure-fisheye-privacy-regions-in-the-view-mode-that-supports-editing/", "slug": "configure-fisheye-privacy-regions-in-the-view-mode-that-supports-editing", "url": "https://update.dsesecurity.com/updates/configure-fisheye-privacy-regions-in-the-view-mode-that-supports-editing/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/configure-fisheye-privacy-regions-in-the-view-mode-that-supports-editing.md", "json": "https://update.dsesecurity.com/api/v1/posts/configure-fisheye-privacy-regions-in-the-view-mode-that-supports-editing/" }, "title": "Configure fisheye privacy regions in the view mode that supports editing", "summary": "Complete fisheye privacy editing in the supported mode and verify the final operator layouts afterward.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:41+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 271, "potentially_affected": "Applies to Verkada fisheye models covered by the view-mode guide. Confirm the exact model’s feature table before changing an existing deployment or promising a particular analytics widget.", "dse_recommendation": "DSE recommends completing privacy-region editing in the supported mode before choosing the operator’s final display layout.", "primary_source": { "name": "Verkada Help — Change Fisheye View Modes", "url": "https://help.verkada.com/verkada-cameras/configuration/view-and-edit-camera-settings/change-fisheye-view-modes", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Complete fisheye privacy editing in the supported mode and verify the final operator layouts afterward.
\nVerkada fisheye cameras offer panoramic, four-way split, and pan-tilt-zoom viewing modes. Site Admin permissions are needed to change the mode. The documented compatibility table says privacy regions must be configured while the fisheye is in PTZ mode; those regions then carry into panoramic and four-way views. After selecting PTZ, the guide requires setting the actual wall or ceiling mount location so digital controls behave correctly. The D80 does not support PTZ mode, so this editing path is not universal.
\nSource: Verkada Help — Change Fisheye View Modes.
\nApplies to Verkada fisheye models covered by the view-mode guide. Confirm the exact model’s feature table before changing an existing deployment or promising a particular analytics widget.
\nDSE recommends completing privacy-region editing in the supported mode before choosing the operator’s final display layout. Keep a marked scene image showing intended protected areas and check that every displayed projection respects them. Confirm the recorded mount location and set useful home positions for the operators who will use the tiles. Document the accepted layout so a later mode or mount change triggers a targeted privacy review rather than silently inheriting an unsuitable arrangement.
\nUsing authorized non-sensitive test footage, inspect the protected area in PTZ, panoramic, and split views after configuration. Confirm that controls behave correctly for the actual mount and that users can navigate the selected layout. Record model and mode with the results rather than applying one fisheye’s behavior to all models.
\nVerkada Help — Change Fisheye View Modes. Reviewed October 15, 2026.
", "content_text": "Complete fisheye privacy editing in the supported mode and verify the final operator layouts afterward.\nSource facts\nVerkada fisheye cameras offer panoramic, four-way split, and pan-tilt-zoom viewing modes. Site Admin permissions are needed to change the mode. The documented compatibility table says privacy regions must be configured while the fisheye is in PTZ mode; those regions then carry into panoramic and four-way views. After selecting PTZ, the guide requires setting the actual wall or ceiling mount location so digital controls behave correctly. The D80 does not support PTZ mode, so this editing path is not universal.\nSource: Verkada Help — Change Fisheye View Modes.\nApplicability\nApplies to Verkada fisheye models covered by the view-mode guide. Confirm the exact model’s feature table before changing an existing deployment or promising a particular analytics widget.\nDSE recommendation\nDSE recommends completing privacy-region editing in the supported mode before choosing the operator’s final display layout. Keep a marked scene image showing intended protected areas and check that every displayed projection respects them. Confirm the recorded mount location and set useful home positions for the operators who will use the tiles. Document the accepted layout so a later mode or mount change triggers a targeted privacy review rather than silently inheriting an unsuitable arrangement.\nVerification\nUsing authorized non-sensitive test footage, inspect the protected area in PTZ, panoramic, and split views after configuration. Confirm that controls behave correctly for the actual mount and that users can navigate the selected layout. Record model and mode with the results rather than applying one fisheye’s behavior to all models.\nOfficial reference\nVerkada Help — Change Fisheye View Modes. Reviewed October 15, 2026.", "content_markdown": "Complete fisheye privacy editing in the supported mode and verify the final operator layouts afterward.\n\n## Source facts\n\nVerkada fisheye cameras offer panoramic, four-way split, and pan-tilt-zoom viewing modes. Site Admin permissions are needed to change the mode. The documented compatibility table says privacy regions must be configured while the fisheye is in PTZ mode; those regions then carry into panoramic and four-way views. After selecting PTZ, the guide requires setting the actual wall or ceiling mount location so digital controls behave correctly. The D80 does not support PTZ mode, so this editing path is not universal.\n\nSource: [Verkada Help — Change Fisheye View Modes](https://help.verkada.com/verkada-cameras/configuration/view-and-edit-camera-settings/change-fisheye-view-modes).\n\n## Applicability\n\nApplies to Verkada fisheye models covered by the view-mode guide. Confirm the exact model’s feature table before changing an existing deployment or promising a particular analytics widget.\n\n## DSE recommendation\n\nDSE recommends completing privacy-region editing in the supported mode before choosing the operator’s final display layout. Keep a marked scene image showing intended protected areas and check that every displayed projection respects them. Confirm the recorded mount location and set useful home positions for the operators who will use the tiles. Document the accepted layout so a later mode or mount change triggers a targeted privacy review rather than silently inheriting an unsuitable arrangement.\n\n## Verification\n\nUsing authorized non-sensitive test footage, inspect the protected area in PTZ, panoramic, and split views after configuration. Confirm that controls behave correctly for the actual mount and that users can navigate the selected layout. Record model and mode with the results rather than applying one fisheye’s behavior to all models.\n\n## Official reference\n\n[Verkada Help — Change Fisheye View Modes](https://help.verkada.com/verkada-cameras/configuration/view-and-edit-camera-settings/change-fisheye-view-modes). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/keep-aggregated-occupancy-lines-separate-from-independent-counting-presets/", "slug": "keep-aggregated-occupancy-lines-separate-from-independent-counting-presets", "url": "https://update.dsesecurity.com/updates/keep-aggregated-occupancy-lines-separate-from-independent-counting-presets/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/keep-aggregated-occupancy-lines-separate-from-independent-counting-presets.md", "json": "https://update.dsesecurity.com/api/v1/posts/keep-aggregated-occupancy-lines-separate-from-independent-counting-presets/" }, "title": "Keep aggregated occupancy lines separate from independent counting presets", "summary": "Decide whether crossings belong in one aggregate or separate presets before distributing occupancy statistics.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:40+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 259, "potentially_affected": "Applies to supported Verkada cameras using Occupancy Trends. These are analytics estimates for operational review; this article does not establish a certified life-safety headcount or an evacuation accounting system.", "dse_recommendation": "DSE recommends naming every line and preset according to the business question.", "primary_source": { "name": "Verkada Help — Occupancy Trends", "url": "https://help.verkada.com/verkada-cameras/analytics/people-analytics/occupancy-trends", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Decide whether crossings belong in one aggregate or separate presets before distributing occupancy statistics.
\nVerkada Occupancy Trends estimates people or vehicle movement across configured virtual lines. Its guidance favors clear one-directional paths, limited occlusion, and adequate visibility on both sides. Multiple lines within the same configuration contribute to aggregated data. Custom line presets maintain separate data from one another. Results can be reviewed by date and interval and exported as CSV. The supported-camera list is model-specific, so a camera’s ability to display video does not establish availability of this analytics feature.
\nSource: Verkada Help — Occupancy Trends.
\nApplies to supported Verkada cameras using Occupancy Trends. These are analytics estimates for operational review; this article does not establish a certified life-safety headcount or an evacuation accounting system.
\nDSE recommends naming every line and preset according to the business question. Combine lines only when their counts are intended to contribute to one measure; use separate presets for comparisons that must remain independent. Map entrances that can bypass the selected cameras and record known counting limitations. Have the operations owner approve the meaning of in and out before distributing a dashboard. Keep manual observation samples with the calibration record.
\nWalk a planned sequence through each crossing direction, including overlapping people and a bypass path where safe. Compare the resulting aggregated and preset-specific counts with observations over the same time interval. Document the difference and accepted limitations; do not turn a successful single-person crossing into a universal accuracy claim.
\nVerkada Help — Occupancy Trends. Reviewed October 15, 2026.
", "content_text": "Decide whether crossings belong in one aggregate or separate presets before distributing occupancy statistics.\nSource facts\nVerkada Occupancy Trends estimates people or vehicle movement across configured virtual lines. Its guidance favors clear one-directional paths, limited occlusion, and adequate visibility on both sides. Multiple lines within the same configuration contribute to aggregated data. Custom line presets maintain separate data from one another. Results can be reviewed by date and interval and exported as CSV. The supported-camera list is model-specific, so a camera’s ability to display video does not establish availability of this analytics feature.\nSource: Verkada Help — Occupancy Trends.\nApplicability\nApplies to supported Verkada cameras using Occupancy Trends. These are analytics estimates for operational review; this article does not establish a certified life-safety headcount or an evacuation accounting system.\nDSE recommendation\nDSE recommends naming every line and preset according to the business question. Combine lines only when their counts are intended to contribute to one measure; use separate presets for comparisons that must remain independent. Map entrances that can bypass the selected cameras and record known counting limitations. Have the operations owner approve the meaning of in and out before distributing a dashboard. Keep manual observation samples with the calibration record.\nVerification\nWalk a planned sequence through each crossing direction, including overlapping people and a bypass path where safe. Compare the resulting aggregated and preset-specific counts with observations over the same time interval. Document the difference and accepted limitations; do not turn a successful single-person crossing into a universal accuracy claim.\nOfficial reference\nVerkada Help — Occupancy Trends. Reviewed October 15, 2026.", "content_markdown": "Decide whether crossings belong in one aggregate or separate presets before distributing occupancy statistics.\n\n## Source facts\n\nVerkada Occupancy Trends estimates people or vehicle movement across configured virtual lines. Its guidance favors clear one-directional paths, limited occlusion, and adequate visibility on both sides. Multiple lines within the same configuration contribute to aggregated data. Custom line presets maintain separate data from one another. Results can be reviewed by date and interval and exported as CSV. The supported-camera list is model-specific, so a camera’s ability to display video does not establish availability of this analytics feature.\n\nSource: [Verkada Help — Occupancy Trends](https://help.verkada.com/verkada-cameras/analytics/people-analytics/occupancy-trends).\n\n## Applicability\n\nApplies to supported Verkada cameras using Occupancy Trends. These are analytics estimates for operational review; this article does not establish a certified life-safety headcount or an evacuation accounting system.\n\n## DSE recommendation\n\nDSE recommends naming every line and preset according to the business question. Combine lines only when their counts are intended to contribute to one measure; use separate presets for comparisons that must remain independent. Map entrances that can bypass the selected cameras and record known counting limitations. Have the operations owner approve the meaning of in and out before distributing a dashboard. Keep manual observation samples with the calibration record.\n\n## Verification\n\nWalk a planned sequence through each crossing direction, including overlapping people and a bypass path where safe. Compare the resulting aggregated and preset-specific counts with observations over the same time interval. Document the difference and accepted limitations; do not turn a successful single-person crossing into a universal accuracy claim.\n\n## Official reference\n\n[Verkada Help — Occupancy Trends](https://help.verkada.com/verkada-cameras/analytics/people-analytics/occupancy-trends). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/split-verkada-audit-investigations-into-complete-query-windows/", "slug": "split-verkada-audit-investigations-into-complete-query-windows", "url": "https://update.dsesecurity.com/updates/split-verkada-audit-investigations-into-complete-query-windows/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/split-verkada-audit-investigations-into-complete-query-windows.md", "json": "https://update.dsesecurity.com/api/v1/posts/split-verkada-audit-investigations-into-complete-query-windows/" }, "title": "Split Verkada audit investigations into complete query windows", "summary": "Preserve query boundaries and filters when assembling an audit investigation longer than one interface window.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "managed-it", "label": "Managed IT operations", "alt": "A controlled technology lifecycle progressing from assessment to approved production.", "card_url": "https://update.dsesecurity.com/assets/editorial/managed-it-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/managed-it-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "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", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:31:39+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 250, "potentially_affected": "Applies to the Verkada Command organization audit interface. A maximum query window is not a statement that only that much history exists or that every conceivable activity is logged.", "dse_recommendation": "DSE recommends dividing a longer investigation into explicit adjacent windows and preserving the filter definition with each export.", "primary_source": { "name": "Verkada Help — Audit Logs", "url": "https://help.verkada.com/command/organization-settings/manage-your-admin-page-settings/manage-and-view-audit-logs", "published_on": null, "authority": "help.verkada.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Preserve query boundaries and filters when assembling an audit investigation longer than one interface window.
\nVerkada audit logs record Command user and device activity at organization and individual-camera levels. Events include an action timestamp and information about the actor, target, and originating address or device. Filters support time range, actor, event category, target, device type, and serial number. The documented interface queries up to 90 days at once. Org Admins can inspect the organization audit log, export CSV results, and create scheduled reports from selected filters.
\nSource: Verkada Help — Audit Logs.
\nApplies to the Verkada Command organization audit interface. A maximum query window is not a statement that only that much history exists or that every conceivable activity is logged.
\nDSE recommends dividing a longer investigation into explicit adjacent windows and preserving the filter definition with each export. Define whether the review concerns logins, footage viewing, support activity, or configuration changes before selecting event categories. Keep actor and target identities intact when combining files, and reconcile boundary timestamps to prevent omissions or double counting. Schedule recurring exports only to approved recipients with a clear evidence-storage location and retention owner.
\nRun a small known activity through the chosen filters and confirm that the resulting event is present. For a multi-window review, compare earliest and latest timestamps in every export against the requested coverage. Record any absent categories or inaccessible periods as limitations rather than reporting a complete audit.
\nVerkada Help — Audit Logs. Reviewed October 15, 2026.
", "content_text": "Preserve query boundaries and filters when assembling an audit investigation longer than one interface window.\nSource facts\nVerkada audit logs record Command user and device activity at organization and individual-camera levels. Events include an action timestamp and information about the actor, target, and originating address or device. Filters support time range, actor, event category, target, device type, and serial number. The documented interface queries up to 90 days at once. Org Admins can inspect the organization audit log, export CSV results, and create scheduled reports from selected filters.\nSource: Verkada Help — Audit Logs.\nApplicability\nApplies to the Verkada Command organization audit interface. A maximum query window is not a statement that only that much history exists or that every conceivable activity is logged.\nDSE recommendation\nDSE recommends dividing a longer investigation into explicit adjacent windows and preserving the filter definition with each export. Define whether the review concerns logins, footage viewing, support activity, or configuration changes before selecting event categories. Keep actor and target identities intact when combining files, and reconcile boundary timestamps to prevent omissions or double counting. Schedule recurring exports only to approved recipients with a clear evidence-storage location and retention owner.\nVerification\nRun a small known activity through the chosen filters and confirm that the resulting event is present. For a multi-window review, compare earliest and latest timestamps in every export against the requested coverage. Record any absent categories or inaccessible periods as limitations rather than reporting a complete audit.\nOfficial reference\nVerkada Help — Audit Logs. Reviewed October 15, 2026.", "content_markdown": "Preserve query boundaries and filters when assembling an audit investigation longer than one interface window.\n\n## Source facts\n\nVerkada audit logs record Command user and device activity at organization and individual-camera levels. Events include an action timestamp and information about the actor, target, and originating address or device. Filters support time range, actor, event category, target, device type, and serial number. The documented interface queries up to 90 days at once. Org Admins can inspect the organization audit log, export CSV results, and create scheduled reports from selected filters.\n\nSource: [Verkada Help — Audit Logs](https://help.verkada.com/command/organization-settings/manage-your-admin-page-settings/manage-and-view-audit-logs).\n\n## Applicability\n\nApplies to the Verkada Command organization audit interface. A maximum query window is not a statement that only that much history exists or that every conceivable activity is logged.\n\n## DSE recommendation\n\nDSE recommends dividing a longer investigation into explicit adjacent windows and preserving the filter definition with each export. Define whether the review concerns logins, footage viewing, support activity, or configuration changes before selecting event categories. Keep actor and target identities intact when combining files, and reconcile boundary timestamps to prevent omissions or double counting. Schedule recurring exports only to approved recipients with a clear evidence-storage location and retention owner.\n\n## Verification\n\nRun a small known activity through the chosen filters and confirm that the resulting event is present. For a multi-window review, compare earliest and latest timestamps in every export against the requested coverage. Record any absent categories or inaccessible periods as limitations rather than reporting a complete audit.\n\n## Official reference\n\n[Verkada Help — Audit Logs](https://help.verkada.com/command/organization-settings/manage-your-admin-page-settings/manage-and-view-audit-logs). Reviewed October 15, 2026." } ] }