Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.
\r\n\r\nCISA ICSA-26-204-01 Update A covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.
\r\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its product advisory also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.
\r\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.
\r\n\r\n| Finding | Affected product | Vendor-directed update |
|---|---|---|
| CVE-2026-21655 | C-CURE 9000 3.10.1 and earlier | Upgrade to 3.20 or later |
| CVE-2026-21655 | victor Application Server 4.10 and earlier | Upgrade to 4.20 or later |
| CVE-2026-21655 | victor 7.0 and earlier | Upgrade to 8.0 or later |
| CVE-2026-21653 | victor Web versions before 7.0 | Upgrade to 7.0 or later |
| CVE-2026-34496 | victor Web 7.1 and earlier | Use the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator |
The Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.
\r\n\r\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.
\r\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.
\r\n\r\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.
For CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.
\r\n\r\nThe following steps are DSE recommendations based on the official advisories.
\r\nSoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.Source review completed August 12, 2026. Recheck the official advisories before changing production systems.
\r\n", "content_text": "Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.\r\n\r\nSource fact: what CISA Update A covers\r\nCISA ICSA-26-204-01 Update A covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.\r\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its product advisory also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.\r\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.\r\n\r\nAffected versions and vendor-directed updates\r\n\r\nFindingAffected productVendor-directed update\r\n\r\nCVE-2026-21655C-CURE 9000 3.10.1 and earlierUpgrade to 3.20 or later\r\nCVE-2026-21655victor Application Server 4.10 and earlierUpgrade to 4.20 or later\r\nCVE-2026-21655victor 7.0 and earlierUpgrade to 8.0 or later\r\nCVE-2026-21653victor Web versions before 7.0Upgrade to 7.0 or later\r\nCVE-2026-34496victor Web 7.1 and earlierUse the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator\r\n\r\n\r\nThe Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.\r\n\r\nWhy “adjacent network” still deserves urgency\r\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.\r\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.\r\n\r\nVendor-provided temporary mitigations\r\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.\r\nFor CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.\r\n\r\nDSE recommendation: prioritized response\r\nThe following steps are DSE recommendations based on the official advisories.\r\n\r\nConfirm exposure now. Inventory every production, disaster-recovery, and test deployment. Record exact product versions, application and web servers, operator clients, network paths, owners, integrations, and remote-support routes.\r\nContain pending upgrades. Restrict port 8999, remove unnecessary cross-segment access, limit victor Web to trusted management paths, and constrain outbound web traffic. Give every temporary exception an owner and expiration date.\r\nExpedite vendor-supported updates. Prioritize the RCE path. For CVE-2026-34496, verify the precise fixed victor Web build with the vendor or integrator.\r\nProtect operations during the change. Follow supported backup and rollback procedures. After updating, test operator sign-in, access-control commands, alarm receipt and acknowledgment, video recording and retrieval, event-to-video associations, reports, and critical integrations.\r\nReview available evidence. Look for unexplained child processes from SoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.\r\nDocument closure. Record fixed versions, containment changes, functional-test results, residual exceptions, and the date the official advisories were rechecked.\r\n\r\n\r\nOfficial reference\r\n\r\nCISA ICSA-26-204-01 Update A, updated August 11, 2026\r\nJohnson Controls JCI-PSA-2026-13 v2, updated August 6, 2026\r\nJohnson Controls JCI-PSA-2026-07\r\nJohnson Controls JCI-PSA-2026-16\r\nJohnson Controls Product Security Advisory register\r\n\r\nSource review completed August 12, 2026. Recheck the official advisories before changing production systems.", "content_markdown": "Bottom line: CISA published Update A to ICSA-26-204-01 on August 11, revising affected-product and mitigation information for three vulnerabilities in Johnson Controls C-CURE 9000 and victor products. The most consequential finding, CVE-2026-21655, can allow an unauthenticated attacker with adjacent-network access to execute code on security-management servers and connected clients, including physical-security operator workstations. CISA rates the advisory up to CVSS 9.6, Critical. As of August 12, CISA reports no known public exploitation specifically targeting these vulnerabilities.\n\n## Source fact: what CISA Update A covers\n\n[CISA ICSA-26-204-01 Update A](https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01) covers CVE-2026-21655, CVE-2026-21653, and CVE-2026-34496. Update A revises the affected-product and mitigation details from the advisory first published July 23.\n\nJohnson Controls describes CVE-2026-21655 as deserialization of untrusted data. Under certain circumstances, an unauthenticated attacker on an adjacent network could execute arbitrary code on C-CURE 9000, victor Application Server, victor, and connected clients. The vendor says the attack could affect physical-security controls. Its [product advisory](https://tyco.widen.net/s/9xktps8hl6/jci-psa-2026-13-v2) also says the C-CURE IQ client, victor Web Services integrations, and communications between iSTAR controllers, VideoEdge NVRs, and victor Application Server are not affected by this CVE.\n\nCVE-2026-21653 is a server-side request forgery issue in victor Web. It can cause the application to make requests to services on the host or local network, creating possible information-disclosure or lateral-movement risk. CVE-2026-34496 has a different prerequisite: a low-privilege victor Web user may reach unauthorized pages such as Users and Logs and view sensitive account, system, or audit information.\n\n## Affected versions and vendor-directed updates\n\nFindingAffected productVendor-directed update\n\nCVE-2026-21655C-CURE 9000 3.10.1 and earlierUpgrade to 3.20 or later\n\nCVE-2026-21655victor Application Server 4.10 and earlierUpgrade to 4.20 or later\n\nCVE-2026-21655victor 7.0 and earlierUpgrade to 8.0 or later\n\nCVE-2026-21653victor Web versions before 7.0Upgrade to 7.0 or later\n\nCVE-2026-34496victor Web 7.1 and earlierUse the latest available fixed release; confirm the exact build with Johnson Controls or the authorized integrator\n\nThe Johnson Controls bulletin for CVE-2026-34496 directs customers to the latest available version but does not name a minimum fixed build. That distinction should be confirmed before closing the change record.\n\n## Why “adjacent network” still deserves urgency\n\nThe RCE path is not described as arbitrary internet-wide exploitation. However, “not internet-facing” is not a complete exposure test. A vulnerable service may still be reachable from a compromised workstation, shared server segment, vendor-access path, or another connected security network. Actual operational consequences depend on privileges, integrations, segmentation, and configuration.\n\nNeither CISA nor Johnson Controls says these flaws automatically unlock doors, disable cameras, or create a specific physical outcome. The verified concern is code execution and access to security-system information, with potential impact to physical-security controls.\n\n## Vendor-provided temporary mitigations\n\nFor CVE-2026-21655, Johnson Controls recommends isolating application servers on a dedicated segment and allowing port 8999 only from authorized systems. It also recommends blocking unnecessary inbound port 8999 traffic, detecting known .NET deserialization patterns, using application allowlisting and least privilege, and monitoring anomalous process creation by SoftwareHouse.CrossFire.Server.exe. If the ClientConnectionManager_NF.SynchronousServerNotification callback is unnecessary, disable or restrict it.\n\nFor CVE-2026-21653, the vendor recommends trusted-management-only access to victor Web, internal segmentation, unusual outbound HTTP monitoring, and egress filtering. For CVE-2026-34496, it recommends strict role-based access control, server-side restrictions on administrative pages, auditing, management-network segmentation, and a web application firewall. These controls reduce exposure while an upgrade is pending; they do not replace fixed releases.\n\n## DSE recommendation: prioritized response\n\nThe following steps are DSE recommendations based on the official advisories.\n\n- Confirm exposure now. Inventory every production, disaster-recovery, and test deployment. Record exact product versions, application and web servers, operator clients, network paths, owners, integrations, and remote-support routes.\n\n- Contain pending upgrades. Restrict port 8999, remove unnecessary cross-segment access, limit victor Web to trusted management paths, and constrain outbound web traffic. Give every temporary exception an owner and expiration date.\n\n- Expedite vendor-supported updates. Prioritize the RCE path. For CVE-2026-34496, verify the precise fixed victor Web build with the vendor or integrator.\n\n- Protect operations during the change. Follow supported backup and rollback procedures. After updating, test operator sign-in, access-control commands, alarm receipt and acknowledgment, video recording and retrieval, event-to-video associations, reports, and critical integrations.\n\n- Review available evidence. Look for unexplained child processes from SoftwareHouse.CrossFire.Server.exe, unusual port 8999 traffic, unexpected outbound HTTP from victor Web, and low-privilege access to Users or Logs. Preserve relevant records and escalate unexplained findings; none alone proves exploitation.\n\n- Document closure. Record fixed versions, containment changes, functional-test results, residual exceptions, and the date the official advisories were rechecked.\n\n## Official reference\n\n- [CISA ICSA-26-204-01 Update A](https://www.cisa.gov/news-events/ics-advisories/icsa-26-204-01), updated August 11, 2026\n\n- [Johnson Controls JCI-PSA-2026-13 v2](https://tyco.widen.net/s/9xktps8hl6/jci-psa-2026-13-v2), updated August 6, 2026\n\n- [Johnson Controls JCI-PSA-2026-07](https://tyco.widen.net/s/n5vdddqbcs/jci-psa-2026-07)\n\n- [Johnson Controls JCI-PSA-2026-16](https://tyco.widen.net/s/s9cchrkg87/jci-psa-2026-16)\n\n- [Johnson Controls Product Security Advisory register](https://www.johnsoncontrols.com/trust-center/cybersecurity/security-advisories)\n\nSource review completed August 12, 2026. Recheck the official advisories before changing production systems." }, { "id": "https://update.dsesecurity.com/updates/coordinate-global-pin-length-with-reader-specific-randomized-keypads/", "slug": "coordinate-global-pin-length-with-reader-specific-randomized-keypads", "url": "https://update.dsesecurity.com/updates/coordinate-global-pin-length-with-reader-specific-randomized-keypads/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/coordinate-global-pin-length-with-reader-specific-randomized-keypads.md", "json": "https://update.dsesecurity.com/api/v1/posts/coordinate-global-pin-length-with-reader-specific-randomized-keypads/" }, "title": "Coordinate global PIN length with reader-specific randomized keypads", "summary": "Record global PIN policy and each reader’s layout separately, then test the approved user experience.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:22+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 281, "potentially_affected": "Applies to regular-user PIN management in UniFi Access and supported readers. This article distinguishes configuration scope; it does not claim that changing a keypad layout changes a user’s PIN or door authorization.", "dse_recommendation": "DSE recommends documenting global PIN policy before tuning individual readers.", "primary_source": { "name": "Ubiquiti Help Center — Configuring PIN Unlock in UniFi Access", "url": "https://help.ui.com/hc/en-us/articles/29027022553239-Configuring-PIN-Unlock-in-UniFi-Access", "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": "Record global PIN policy and each reader’s layout separately, then test the approved user experience.
\nUniFi Access assigns one PIN to each regular user. An administrator can enter a PIN or generate a random one in that person’s credential settings. PIN length is a global setting for all readers, with fixed-length choices or variable length. Keypad layout is configured separately for each supported camera-equipped reader, where Standard and Randomized layouts are offered. The user enters the PIN and submits it on a compatible reader. Visitor PIN provisioning follows a separate visitor workflow.
\nSource: Ubiquiti Help Center — Configuring PIN Unlock in UniFi Access.
\nApplies to regular-user PIN management in UniFi Access and supported readers. This article distinguishes configuration scope; it does not claim that changing a keypad layout changes a user’s PIN or door authorization.
\nDSE recommends documenting global PIN policy before tuning individual readers. Have the access owner approve length and assignment practices, then review randomized-keypad usability at the actual entry points. Avoid shared codes when individual accountability is required by site policy. Communicate an approved PIN-policy change before rollout and retain an alternative authorized entry path for users who need assistance. Keep visitor credential handling separate so temporary guests are not created as permanent staff solely to obtain a PIN.
\nUse controlled test users to check the approved PIN format on representative readers with both configured layouts. Verify correct entry, a deliberate incorrect code, and normal cancellation or retry behavior without recording real users’ PINs. Confirm the global policy and per-reader layout evidence separately in the change record.
\nUbiquiti Help Center — Configuring PIN Unlock in UniFi Access. Reviewed October 15, 2026.
", "content_text": "Record global PIN policy and each reader’s layout separately, then test the approved user experience.\nSource facts\nUniFi Access assigns one PIN to each regular user. An administrator can enter a PIN or generate a random one in that person’s credential settings. PIN length is a global setting for all readers, with fixed-length choices or variable length. Keypad layout is configured separately for each supported camera-equipped reader, where Standard and Randomized layouts are offered. The user enters the PIN and submits it on a compatible reader. Visitor PIN provisioning follows a separate visitor workflow.\nSource: Ubiquiti Help Center — Configuring PIN Unlock in UniFi Access.\nApplicability\nApplies to regular-user PIN management in UniFi Access and supported readers. This article distinguishes configuration scope; it does not claim that changing a keypad layout changes a user’s PIN or door authorization.\nDSE recommendation\nDSE recommends documenting global PIN policy before tuning individual readers. Have the access owner approve length and assignment practices, then review randomized-keypad usability at the actual entry points. Avoid shared codes when individual accountability is required by site policy. Communicate an approved PIN-policy change before rollout and retain an alternative authorized entry path for users who need assistance. Keep visitor credential handling separate so temporary guests are not created as permanent staff solely to obtain a PIN.\nVerification\nUse controlled test users to check the approved PIN format on representative readers with both configured layouts. Verify correct entry, a deliberate incorrect code, and normal cancellation or retry behavior without recording real users’ PINs. Confirm the global policy and per-reader layout evidence separately in the change record.\nOfficial reference\nUbiquiti Help Center — Configuring PIN Unlock in UniFi Access. Reviewed October 15, 2026.", "content_markdown": "Record global PIN policy and each reader’s layout separately, then test the approved user experience.\n\n## Source facts\n\nUniFi Access assigns one PIN to each regular user. An administrator can enter a PIN or generate a random one in that person’s credential settings. PIN length is a global setting for all readers, with fixed-length choices or variable length. Keypad layout is configured separately for each supported camera-equipped reader, where Standard and Randomized layouts are offered. The user enters the PIN and submits it on a compatible reader. Visitor PIN provisioning follows a separate visitor workflow.\n\nSource: [Ubiquiti Help Center — Configuring PIN Unlock in UniFi Access](https://help.ui.com/hc/en-us/articles/29027022553239-Configuring-PIN-Unlock-in-UniFi-Access).\n\n## Applicability\n\nApplies to regular-user PIN management in UniFi Access and supported readers. This article distinguishes configuration scope; it does not claim that changing a keypad layout changes a user’s PIN or door authorization.\n\n## DSE recommendation\n\nDSE recommends documenting global PIN policy before tuning individual readers. Have the access owner approve length and assignment practices, then review randomized-keypad usability at the actual entry points. Avoid shared codes when individual accountability is required by site policy. Communicate an approved PIN-policy change before rollout and retain an alternative authorized entry path for users who need assistance. Keep visitor credential handling separate so temporary guests are not created as permanent staff solely to obtain a PIN.\n\n## Verification\n\nUse controlled test users to check the approved PIN format on representative readers with both configured layouts. Verify correct entry, a deliberate incorrect code, and normal cancellation or retry behavior without recording real users’ PINs. Confirm the global policy and per-reader layout evidence separately in the change record.\n\n## Official reference\n\n[Ubiquiti Help Center — Configuring PIN Unlock in UniFi Access](https://help.ui.com/hc/en-us/articles/29027022553239-Configuring-PIN-Unlock-in-UniFi-Access). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/account-for-door-attendant-exceptions-when-scheduling-unifi-doorbell-receivers/", "slug": "account-for-door-attendant-exceptions-when-scheduling-unifi-doorbell-receivers", "url": "https://update.dsesecurity.com/updates/account-for-door-attendant-exceptions-when-scheduling-unifi-doorbell-receivers/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/account-for-door-attendant-exceptions-when-scheduling-unifi-doorbell-receivers.md", "json": "https://update.dsesecurity.com/api/v1/posts/account-for-door-attendant-exceptions-when-scheduling-unifi-doorbell-receivers/" }, "title": "Account for Door Attendant exceptions when scheduling UniFi doorbell receivers", "summary": "Review Door Attendant assignments separately when setting notification schedules or an on-call reception rotation.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:21+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 283, "potentially_affected": "Applies to the Door Attendant exception documented in UniFi Access doorbell call configuration. Verify role assignment and app settings; this article does not assume that all mobile notifications follow an identical schedule.", "dse_recommendation": "DSE recommends reviewing Door Attendant assignments when establishing reception hours or an on-call rotation.", "primary_source": { "name": "Ubiquiti Help Center — Configuring Doorbell Call Methods and Receivers in UniFi Access", "url": "https://help.ui.com/hc/en-us/articles/25095707427863-Configuring-Doorbell-Call-Methods-and-Receivers-in-UniFi-Access", "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": "Review Door Attendant assignments separately when setting notification schedules or an on-call reception rotation.
\nUniFi Access doorbell receiver lists support scheduled recipients and sequential call groups. The guide separately states that Door Attendants always receive doorbell calls, even when they are not listed as receivers, their listed receiver schedule is inactive, or Notify Admins of Doorbell Rings is disabled. Door Attendants can mute calls through their mobile app. Ordinary administrators and users have other notification paths and settings, so changing a reader’s receiver schedule alone does not describe the entire notification audience.
\nSource: Ubiquiti Help Center — Configuring Doorbell Call Methods and Receivers in UniFi Access.
\nApplies to the Door Attendant exception documented in UniFi Access doorbell call configuration. Verify role assignment and app settings; this article does not assume that all mobile notifications follow an identical schedule.
\nDSE recommends reviewing Door Attendant assignments when establishing reception hours or an on-call rotation. Name the people who should receive calls outside the configured receiver window and document how temporary muting is used. Keep normal receiver schedules, broad administrator notifications, and Door Attendant behavior as separate checks. Train staff to report the role and device receiving an unexpected call so troubleshooting does not repeatedly edit a schedule that the role intentionally bypasses.
\nWith consenting test recipients, trigger calls inside and outside the receiver schedule and compare an ordinary recipient with a Door Attendant. Check the administrator-notification toggle and the attendant’s mute state independently. Record who actually receives each call and confirm the approved fallback still works after any role or notification change.
\nUbiquiti Help Center — Configuring Doorbell Call Methods and Receivers in UniFi Access. Reviewed October 15, 2026.
", "content_text": "Review Door Attendant assignments separately when setting notification schedules or an on-call reception rotation.\nSource facts\nUniFi Access doorbell receiver lists support scheduled recipients and sequential call groups. The guide separately states that Door Attendants always receive doorbell calls, even when they are not listed as receivers, their listed receiver schedule is inactive, or Notify Admins of Doorbell Rings is disabled. Door Attendants can mute calls through their mobile app. Ordinary administrators and users have other notification paths and settings, so changing a reader’s receiver schedule alone does not describe the entire notification audience.\nSource: Ubiquiti Help Center — Configuring Doorbell Call Methods and Receivers in UniFi Access.\nApplicability\nApplies to the Door Attendant exception documented in UniFi Access doorbell call configuration. Verify role assignment and app settings; this article does not assume that all mobile notifications follow an identical schedule.\nDSE recommendation\nDSE recommends reviewing Door Attendant assignments when establishing reception hours or an on-call rotation. Name the people who should receive calls outside the configured receiver window and document how temporary muting is used. Keep normal receiver schedules, broad administrator notifications, and Door Attendant behavior as separate checks. Train staff to report the role and device receiving an unexpected call so troubleshooting does not repeatedly edit a schedule that the role intentionally bypasses.\nVerification\nWith consenting test recipients, trigger calls inside and outside the receiver schedule and compare an ordinary recipient with a Door Attendant. Check the administrator-notification toggle and the attendant’s mute state independently. Record who actually receives each call and confirm the approved fallback still works after any role or notification change.\nOfficial reference\nUbiquiti Help Center — Configuring Doorbell Call Methods and Receivers in UniFi Access. Reviewed October 15, 2026.", "content_markdown": "Review Door Attendant assignments separately when setting notification schedules or an on-call reception rotation.\n\n## Source facts\n\nUniFi Access doorbell receiver lists support scheduled recipients and sequential call groups. The guide separately states that Door Attendants always receive doorbell calls, even when they are not listed as receivers, their listed receiver schedule is inactive, or Notify Admins of Doorbell Rings is disabled. Door Attendants can mute calls through their mobile app. Ordinary administrators and users have other notification paths and settings, so changing a reader’s receiver schedule alone does not describe the entire notification audience.\n\nSource: [Ubiquiti Help Center — Configuring Doorbell Call Methods and Receivers in UniFi Access](https://help.ui.com/hc/en-us/articles/25095707427863-Configuring-Doorbell-Call-Methods-and-Receivers-in-UniFi-Access).\n\n## Applicability\n\nApplies to the Door Attendant exception documented in UniFi Access doorbell call configuration. Verify role assignment and app settings; this article does not assume that all mobile notifications follow an identical schedule.\n\n## DSE recommendation\n\nDSE recommends reviewing Door Attendant assignments when establishing reception hours or an on-call rotation. Name the people who should receive calls outside the configured receiver window and document how temporary muting is used. Keep normal receiver schedules, broad administrator notifications, and Door Attendant behavior as separate checks. Train staff to report the role and device receiving an unexpected call so troubleshooting does not repeatedly edit a schedule that the role intentionally bypasses.\n\n## Verification\n\nWith consenting test recipients, trigger calls inside and outside the receiver schedule and compare an ordinary recipient with a Door Attendant. Check the administrator-notification toggle and the attendant’s mute state independently. Record who actually receives each call and confirm the approved fallback still works after any role or notification change.\n\n## Official reference\n\n[Ubiquiti Help Center — Configuring Doorbell Call Methods and Receivers in UniFi Access](https://help.ui.com/hc/en-us/articles/25095707427863-Configuring-Doorbell-Call-Methods-and-Receivers-in-UniFi-Access). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/require-kiosk-check-in-before-a-scheduled-unifi-visitor-can-open-doors/", "slug": "require-kiosk-check-in-before-a-scheduled-unifi-visitor-can-open-doors", "url": "https://update.dsesecurity.com/updates/require-kiosk-check-in-before-a-scheduled-unifi-visitor-can-open-doors/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/require-kiosk-check-in-before-a-scheduled-unifi-visitor-can-open-doors.md", "json": "https://update.dsesecurity.com/api/v1/posts/require-kiosk-check-in-before-a-scheduled-unifi-visitor-can-open-doors/" }, "title": "Require kiosk check-in before a scheduled UniFi visitor can open doors", "summary": "Decide whether arrival check-in must precede door access and verify the staffed fallback without bypassing approval.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:20+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 UniFi Access visitor schedules and supported kiosk hardware/software. Select the approval steps authorized by the site’s visitor policy and confirm the supported printing and mobile-app prerequisites before rollout.", "dse_recommendation": "DSE recommends deciding whether pre-arrival credentials should work before a visitor reaches reception.", "primary_source": { "name": "Ubiquiti Help Center — Configuring Visitor Schedules in UniFi Access", "url": "https://help.ui.com/hc/en-us/articles/29026499254935-Configuring-Visitor-Schedules-in-UniFi-Access", "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": "Decide whether arrival check-in must precede door access and verify the staffed fallback without bypassing approval.
\nUniFi Access visitor configuration defines a one-time or recurring schedule, visit locations, and door credentials. An optional Require Check-In at the Kiosk setting makes self-service check-in a prerequisite to opening doors. The documented kiosk workflow supports check-in, approval, and badge printing as configured. The guide specifies supported printer models and minimum application versions; iPad is used to configure kiosk mode, while supported mobile apps can approve visitor check-in requests. An invitation alone is therefore not the whole check-in workflow.
\nSource: Ubiquiti Help Center — Configuring Visitor Schedules in UniFi Access.
\nApplies to UniFi Access visitor schedules and supported kiosk hardware/software. Select the approval steps authorized by the site’s visitor policy and confirm the supported printing and mobile-app prerequisites before rollout.
\nDSE recommends deciding whether pre-arrival credentials should work before a visitor reaches reception. If check-in is required, document the approval owner, supported kiosk and printer, and a staffed fallback when the kiosk is unavailable. Limit visit locations and timing to the approved purpose. Tell the host and visitor what to expect before arrival and review how the approval record and printed badge will be handled under the site’s visitor policy.
\nCreate an authorized test invitation and check the intended door before check-in, after approval, and after the visit window ends. Observe the actual badge and credential delivery if printing is used. Confirm the staffed fallback preserves the approved access decision instead of removing the check-in requirement simply to clear a queue.
\nUbiquiti Help Center — Configuring Visitor Schedules in UniFi Access. Reviewed October 15, 2026.
", "content_text": "Decide whether arrival check-in must precede door access and verify the staffed fallback without bypassing approval.\nSource facts\nUniFi Access visitor configuration defines a one-time or recurring schedule, visit locations, and door credentials. An optional Require Check-In at the Kiosk setting makes self-service check-in a prerequisite to opening doors. The documented kiosk workflow supports check-in, approval, and badge printing as configured. The guide specifies supported printer models and minimum application versions; iPad is used to configure kiosk mode, while supported mobile apps can approve visitor check-in requests. An invitation alone is therefore not the whole check-in workflow.\nSource: Ubiquiti Help Center — Configuring Visitor Schedules in UniFi Access.\nApplicability\nApplies to UniFi Access visitor schedules and supported kiosk hardware/software. Select the approval steps authorized by the site’s visitor policy and confirm the supported printing and mobile-app prerequisites before rollout.\nDSE recommendation\nDSE recommends deciding whether pre-arrival credentials should work before a visitor reaches reception. If check-in is required, document the approval owner, supported kiosk and printer, and a staffed fallback when the kiosk is unavailable. Limit visit locations and timing to the approved purpose. Tell the host and visitor what to expect before arrival and review how the approval record and printed badge will be handled under the site’s visitor policy.\nVerification\nCreate an authorized test invitation and check the intended door before check-in, after approval, and after the visit window ends. Observe the actual badge and credential delivery if printing is used. Confirm the staffed fallback preserves the approved access decision instead of removing the check-in requirement simply to clear a queue.\nOfficial reference\nUbiquiti Help Center — Configuring Visitor Schedules in UniFi Access. Reviewed October 15, 2026.", "content_markdown": "Decide whether arrival check-in must precede door access and verify the staffed fallback without bypassing approval.\n\n## Source facts\n\nUniFi Access visitor configuration defines a one-time or recurring schedule, visit locations, and door credentials. An optional Require Check-In at the Kiosk setting makes self-service check-in a prerequisite to opening doors. The documented kiosk workflow supports check-in, approval, and badge printing as configured. The guide specifies supported printer models and minimum application versions; iPad is used to configure kiosk mode, while supported mobile apps can approve visitor check-in requests. An invitation alone is therefore not the whole check-in workflow.\n\nSource: [Ubiquiti Help Center — Configuring Visitor Schedules in UniFi Access](https://help.ui.com/hc/en-us/articles/29026499254935-Configuring-Visitor-Schedules-in-UniFi-Access).\n\n## Applicability\n\nApplies to UniFi Access visitor schedules and supported kiosk hardware/software. Select the approval steps authorized by the site’s visitor policy and confirm the supported printing and mobile-app prerequisites before rollout.\n\n## DSE recommendation\n\nDSE recommends deciding whether pre-arrival credentials should work before a visitor reaches reception. If check-in is required, document the approval owner, supported kiosk and printer, and a staffed fallback when the kiosk is unavailable. Limit visit locations and timing to the approved purpose. Tell the host and visitor what to expect before arrival and review how the approval record and printed badge will be handled under the site’s visitor policy.\n\n## Verification\n\nCreate an authorized test invitation and check the intended door before check-in, after approval, and after the visit window ends. Observe the actual badge and credential delivery if printing is used. Confirm the staffed fallback preserves the approved access decision instead of removing the check-in requirement simply to clear a queue.\n\n## Official reference\n\n[Ubiquiti Help Center — Configuring Visitor Schedules in UniFi Access](https://help.ui.com/hc/en-us/articles/29026499254935-Configuring-Visitor-Schedules-in-UniFi-Access). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/preserve-card-format-meaning-when-configuring-a-unifi-retrofit-hub/", "slug": "preserve-card-format-meaning-when-configuring-a-unifi-retrofit-hub", "url": "https://update.dsesecurity.com/updates/preserve-card-format-meaning-when-configuring-a-unifi-retrofit-hub/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/preserve-card-format-meaning-when-configuring-a-unifi-retrofit-hub.md", "json": "https://update.dsesecurity.com/api/v1/posts/preserve-card-format-meaning-when-configuring-a-unifi-retrofit-hub/" }, "title": "Preserve card-format meaning when configuring a UniFi Retrofit Hub", "summary": "Pilot the complete credential format and promised mobile features before approving a wiring-reuse migration.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:13+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 UA-Retrofit-Hub-2 and the compatible reader paths in the UniFi guide. Verify the actual installed reader and format; wiring reuse does not establish identical credential interpretation or feature support.", "dse_recommendation": "DSE recommends documenting the full credential format before replacing the controller.", "primary_source": { "name": "Ubiquiti Help Center — Configuring the UniFi Retrofit Hub in UniFi Access", "url": "https://help.ui.com/hc/en-us/articles/34338807702679-Configuring-the-UniFi-Retrofit-Hub-in-UniFi-Access", "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": "Pilot the complete credential format and promised mobile features before approving a wiring-reuse migration.
\nThe UniFi Retrofit Hub supports compatible third-party Wiegand readers and UniFi Retrofit Readers, with model-specific unlock methods. When configuring a Wiegand reader, the selected card format must match the format emitted by the reader. The guide distinguishes raw data, formats containing a facility code and card number, and alternatives that omit the facility code. It also states that Touch Pass and Mobile Unlock require Retrofit Readers; retaining a Wiegand reader does not supply those reader-dependent capabilities.
\nSource: Ubiquiti Help Center — Configuring the UniFi Retrofit Hub in UniFi Access.
\nApplies to UA-Retrofit-Hub-2 and the compatible reader paths in the UniFi guide. Verify the actual installed reader and format; wiring reuse does not establish identical credential interpretation or feature support.
\nDSE recommends documenting the full credential format before replacing the controller. Compare the reader’s emitted value with the intended identity representation and preserve facility-code meaning where the access design requires it. Pilot credentials from every relevant card population rather than one employee badge. List any expected mobile features against the actual reader type and resolve unsupported expectations before purchase. Have the access owner approve the migration mapping and retain the original configuration for rollback.
\nOn an isolated or approved pilot door, compare controlled cards that exercise the relevant facility and card-number fields. Verify each maps to the correct person and that an unassigned test card is denied. Test any promised mobile function on the specific reader path, and record format settings from both ends.
\nUbiquiti Help Center — Configuring the UniFi Retrofit Hub in UniFi Access. Reviewed October 15, 2026.
", "content_text": "Pilot the complete credential format and promised mobile features before approving a wiring-reuse migration.\nSource facts\nThe UniFi Retrofit Hub supports compatible third-party Wiegand readers and UniFi Retrofit Readers, with model-specific unlock methods. When configuring a Wiegand reader, the selected card format must match the format emitted by the reader. The guide distinguishes raw data, formats containing a facility code and card number, and alternatives that omit the facility code. It also states that Touch Pass and Mobile Unlock require Retrofit Readers; retaining a Wiegand reader does not supply those reader-dependent capabilities.\nSource: Ubiquiti Help Center — Configuring the UniFi Retrofit Hub in UniFi Access.\nApplicability\nApplies to UA-Retrofit-Hub-2 and the compatible reader paths in the UniFi guide. Verify the actual installed reader and format; wiring reuse does not establish identical credential interpretation or feature support.\nDSE recommendation\nDSE recommends documenting the full credential format before replacing the controller. Compare the reader’s emitted value with the intended identity representation and preserve facility-code meaning where the access design requires it. Pilot credentials from every relevant card population rather than one employee badge. List any expected mobile features against the actual reader type and resolve unsupported expectations before purchase. Have the access owner approve the migration mapping and retain the original configuration for rollback.\nVerification\nOn an isolated or approved pilot door, compare controlled cards that exercise the relevant facility and card-number fields. Verify each maps to the correct person and that an unassigned test card is denied. Test any promised mobile function on the specific reader path, and record format settings from both ends.\nOfficial reference\nUbiquiti Help Center — Configuring the UniFi Retrofit Hub in UniFi Access. Reviewed October 15, 2026.", "content_markdown": "Pilot the complete credential format and promised mobile features before approving a wiring-reuse migration.\n\n## Source facts\n\nThe UniFi Retrofit Hub supports compatible third-party Wiegand readers and UniFi Retrofit Readers, with model-specific unlock methods. When configuring a Wiegand reader, the selected card format must match the format emitted by the reader. The guide distinguishes raw data, formats containing a facility code and card number, and alternatives that omit the facility code. It also states that Touch Pass and Mobile Unlock require Retrofit Readers; retaining a Wiegand reader does not supply those reader-dependent capabilities.\n\nSource: [Ubiquiti Help Center — Configuring the UniFi Retrofit Hub in UniFi Access](https://help.ui.com/hc/en-us/articles/34338807702679-Configuring-the-UniFi-Retrofit-Hub-in-UniFi-Access).\n\n## Applicability\n\nApplies to UA-Retrofit-Hub-2 and the compatible reader paths in the UniFi guide. Verify the actual installed reader and format; wiring reuse does not establish identical credential interpretation or feature support.\n\n## DSE recommendation\n\nDSE recommends documenting the full credential format before replacing the controller. Compare the reader’s emitted value with the intended identity representation and preserve facility-code meaning where the access design requires it. Pilot credentials from every relevant card population rather than one employee badge. List any expected mobile features against the actual reader type and resolve unsupported expectations before purchase. Have the access owner approve the migration mapping and retain the original configuration for rollback.\n\n## Verification\n\nOn an isolated or approved pilot door, compare controlled cards that exercise the relevant facility and card-number fields. Verify each maps to the correct person and that an unassigned test card is denied. Test any promised mobile function on the specific reader path, and record format settings from both ends.\n\n## Official reference\n\n[Ubiquiti Help Center — Configuring the UniFi Retrofit Hub in UniFi Access](https://help.ui.com/hc/en-us/articles/34338807702679-Configuring-the-UniFi-Retrofit-Hub-in-UniFi-Access). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/understand-how-clearing-one-manual-unifi-emergency-door-affects-the-site-mode/", "slug": "understand-how-clearing-one-manual-unifi-emergency-door-affects-the-site-mode", "url": "https://update.dsesecurity.com/updates/understand-how-clearing-one-manual-unifi-emergency-door-affects-the-site-mode/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/understand-how-clearing-one-manual-unifi-emergency-door-affects-the-site-mode.md", "json": "https://update.dsesecurity.com/api/v1/posts/understand-how-clearing-one-manual-unifi-emergency-door-affects-the-site-mode/" }, "title": "Understand how clearing one manual UniFi emergency door affects the site mode", "summary": "Put the site-wide consequence of a manual clearing action directly in the approved restoration procedure.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:12+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 the emergency-state control behavior described for UniFi Access. The approved fire, egress, and incident procedures remain authoritative; this article does not design or certify a life-safety sequence.", "dse_recommendation": "DSE recommends placing the site-level clearing consequence directly in the incident runbook.", "primary_source": { "name": "Ubiquiti Help Center — Activating Emergency Mode in UniFi Access", "url": "https://help.ui.com/hc/en-us/articles/17784702059415-Activating-Emergency-Mode-in-UniFi-Access", "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": "Put the site-wide consequence of a manual clearing action directly in the approved restoration procedure.
\nUniFi Access permits manual emergency mode at site or individual-door scope. Its guide says that when a site emergency mode was activated manually, deactivating the mode for any door also deactivates the site-level mode. A fire-panel-triggered door is different: its emergency state cannot be cleared through the web app, mobile app, or reader Admin Mode. If site-wide propagation is enabled, other doors not directly triggered by the fire panel can still be treated separately as documented.
\nSource: Ubiquiti Help Center — Activating Emergency Mode in UniFi Access.
\nApplies to the emergency-state control behavior described for UniFi Access. The approved fire, egress, and incident procedures remain authoritative; this article does not design or certify a life-safety sequence.
\nDSE recommends placing the site-level clearing consequence directly in the incident runbook. Operators should identify whether the state came from manual activation or the fire interface before trying to restore one door. Assign a restoration coordinator and require a site-status check after any manual clearing action. Review the propagation option with the responsible safety and security owners and avoid experimenting with emergency controls during normal occupancy to discover their scope.
\nDuring a coordinated exercise with required safety personnel, observe site and door state for the approved manual activation and restoration sequence. Confirm operators recognize a fire-input state that software cannot clear. Record the configured scope and affected doors, and obtain the designated restoration approval before returning the system to ordinary operation.
\nUbiquiti Help Center — Activating Emergency Mode in UniFi Access. Reviewed October 15, 2026.
", "content_text": "Put the site-wide consequence of a manual clearing action directly in the approved restoration procedure.\nSource facts\nUniFi Access permits manual emergency mode at site or individual-door scope. Its guide says that when a site emergency mode was activated manually, deactivating the mode for any door also deactivates the site-level mode. A fire-panel-triggered door is different: its emergency state cannot be cleared through the web app, mobile app, or reader Admin Mode. If site-wide propagation is enabled, other doors not directly triggered by the fire panel can still be treated separately as documented.\nSource: Ubiquiti Help Center — Activating Emergency Mode in UniFi Access.\nApplicability\nApplies to the emergency-state control behavior described for UniFi Access. The approved fire, egress, and incident procedures remain authoritative; this article does not design or certify a life-safety sequence.\nDSE recommendation\nDSE recommends placing the site-level clearing consequence directly in the incident runbook. Operators should identify whether the state came from manual activation or the fire interface before trying to restore one door. Assign a restoration coordinator and require a site-status check after any manual clearing action. Review the propagation option with the responsible safety and security owners and avoid experimenting with emergency controls during normal occupancy to discover their scope.\nVerification\nDuring a coordinated exercise with required safety personnel, observe site and door state for the approved manual activation and restoration sequence. Confirm operators recognize a fire-input state that software cannot clear. Record the configured scope and affected doors, and obtain the designated restoration approval before returning the system to ordinary operation.\nOfficial reference\nUbiquiti Help Center — Activating Emergency Mode in UniFi Access. Reviewed October 15, 2026.", "content_markdown": "Put the site-wide consequence of a manual clearing action directly in the approved restoration procedure.\n\n## Source facts\n\nUniFi Access permits manual emergency mode at site or individual-door scope. Its guide says that when a site emergency mode was activated manually, deactivating the mode for any door also deactivates the site-level mode. A fire-panel-triggered door is different: its emergency state cannot be cleared through the web app, mobile app, or reader Admin Mode. If site-wide propagation is enabled, other doors not directly triggered by the fire panel can still be treated separately as documented.\n\nSource: [Ubiquiti Help Center — Activating Emergency Mode in UniFi Access](https://help.ui.com/hc/en-us/articles/17784702059415-Activating-Emergency-Mode-in-UniFi-Access).\n\n## Applicability\n\nApplies to the emergency-state control behavior described for UniFi Access. The approved fire, egress, and incident procedures remain authoritative; this article does not design or certify a life-safety sequence.\n\n## DSE recommendation\n\nDSE recommends placing the site-level clearing consequence directly in the incident runbook. Operators should identify whether the state came from manual activation or the fire interface before trying to restore one door. Assign a restoration coordinator and require a site-status check after any manual clearing action. Review the propagation option with the responsible safety and security owners and avoid experimenting with emergency controls during normal occupancy to discover their scope.\n\n## Verification\n\nDuring a coordinated exercise with required safety personnel, observe site and door state for the approved manual activation and restoration sequence. Confirm operators recognize a fire-input state that software cannot clear. Record the configured scope and affected doors, and obtain the designated restoration approval before returning the system to ordinary operation.\n\n## Official reference\n\n[Ubiquiti Help Center — Activating Emergency Mode in UniFi Access](https://help.ui.com/hc/en-us/articles/17784702059415-Activating-Emergency-Mode-in-UniFi-Access). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/set-the-elevator-hub-floor-selection-window-to-match-the-authorization-model/", "slug": "set-the-elevator-hub-floor-selection-window-to-match-the-authorization-model", "url": "https://update.dsesecurity.com/updates/set-the-elevator-hub-floor-selection-window-to-match-the-authorization-model/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/set-the-elevator-hub-floor-selection-window-to-match-the-authorization-model.md", "json": "https://update.dsesecurity.com/api/v1/posts/set-the-elevator-hub-floor-selection-window-to-match-the-authorization-model/" }, "title": "Set the Elevator Hub floor-selection window to match the authorization model", "summary": "Approve the floor authorization model and terminal map before choosing the usable floor-selection window.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:11+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 UA-Hub-Elevator authorization and floor-terminal configuration. Elevator modification requires the responsible elevator professionals; this article does not authorize changes to safety circuits or determine code compliance.", "dse_recommendation": "DSE recommends agreeing on the authorization model before choosing a trigger window.", "primary_source": { "name": "Ubiquiti Help Center — Configuring UniFi Access Elevator Hub", "url": "https://help.ui.com/hc/en-us/articles/20050307166231-Configuring-UniFi-Access-Elevator-Hub", "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 the floor authorization model and terminal map before choosing the usable floor-selection window.
\nUniFi’s Elevator Hub guide distinguishes controlling individual floors from controlling access to the elevator as a whole. Individual-floor operation uses floor-specific access policies; full-elevator operation permits authenticated users to request service and select floors more broadly. The floor-terminal Trigger Duration defines how long a user has to select a floor after authentication. The hub’s relay terminals are assigned floor names, and the guide calls for coordination with elevator technicians and specialized equipment for floor-level control.
\nSource: Ubiquiti Help Center — Configuring UniFi Access Elevator Hub.
\nApplies to UA-Hub-Elevator authorization and floor-terminal configuration. Elevator modification requires the responsible elevator professionals; this article does not authorize changes to safety circuits or determine code compliance.
\nDSE recommends agreeing on the authorization model before choosing a trigger window. Map each physical floor to its terminal and policy, identify public floors, and have the building owner approve what a successful credential should enable. Work with the elevator technician to select a usable timing window for the actual reader and button arrangement. Preserve a labeled terminal schedule and the acceptance criteria so later policy edits do not accidentally broaden access to every floor.
\nWith the elevator team and an approved test plan, compare a limited-floor credential with a broader credential. Observe allowed and disallowed floor selections before and after the configured window. Record the actual enabled buttons and floor mapping rather than inferring floor restrictions from the fact that the reader accepted a credential.
\nUbiquiti Help Center — Configuring UniFi Access Elevator Hub. Reviewed October 15, 2026.
", "content_text": "Approve the floor authorization model and terminal map before choosing the usable floor-selection window.\nSource facts\nUniFi’s Elevator Hub guide distinguishes controlling individual floors from controlling access to the elevator as a whole. Individual-floor operation uses floor-specific access policies; full-elevator operation permits authenticated users to request service and select floors more broadly. The floor-terminal Trigger Duration defines how long a user has to select a floor after authentication. The hub’s relay terminals are assigned floor names, and the guide calls for coordination with elevator technicians and specialized equipment for floor-level control.\nSource: Ubiquiti Help Center — Configuring UniFi Access Elevator Hub.\nApplicability\nApplies to UA-Hub-Elevator authorization and floor-terminal configuration. Elevator modification requires the responsible elevator professionals; this article does not authorize changes to safety circuits or determine code compliance.\nDSE recommendation\nDSE recommends agreeing on the authorization model before choosing a trigger window. Map each physical floor to its terminal and policy, identify public floors, and have the building owner approve what a successful credential should enable. Work with the elevator technician to select a usable timing window for the actual reader and button arrangement. Preserve a labeled terminal schedule and the acceptance criteria so later policy edits do not accidentally broaden access to every floor.\nVerification\nWith the elevator team and an approved test plan, compare a limited-floor credential with a broader credential. Observe allowed and disallowed floor selections before and after the configured window. Record the actual enabled buttons and floor mapping rather than inferring floor restrictions from the fact that the reader accepted a credential.\nOfficial reference\nUbiquiti Help Center — Configuring UniFi Access Elevator Hub. Reviewed October 15, 2026.", "content_markdown": "Approve the floor authorization model and terminal map before choosing the usable floor-selection window.\n\n## Source facts\n\nUniFi’s Elevator Hub guide distinguishes controlling individual floors from controlling access to the elevator as a whole. Individual-floor operation uses floor-specific access policies; full-elevator operation permits authenticated users to request service and select floors more broadly. The floor-terminal Trigger Duration defines how long a user has to select a floor after authentication. The hub’s relay terminals are assigned floor names, and the guide calls for coordination with elevator technicians and specialized equipment for floor-level control.\n\nSource: [Ubiquiti Help Center — Configuring UniFi Access Elevator Hub](https://help.ui.com/hc/en-us/articles/20050307166231-Configuring-UniFi-Access-Elevator-Hub).\n\n## Applicability\n\nApplies to UA-Hub-Elevator authorization and floor-terminal configuration. Elevator modification requires the responsible elevator professionals; this article does not authorize changes to safety circuits or determine code compliance.\n\n## DSE recommendation\n\nDSE recommends agreeing on the authorization model before choosing a trigger window. Map each physical floor to its terminal and policy, identify public floors, and have the building owner approve what a successful credential should enable. Work with the elevator technician to select a usable timing window for the actual reader and button arrangement. Preserve a labeled terminal schedule and the acceptance criteria so later policy edits do not accidentally broaden access to every floor.\n\n## Verification\n\nWith the elevator team and an approved test plan, compare a limited-floor credential with a broader credential. Observe allowed and disallowed floor selections before and after the configured window. Record the actual enabled buttons and floor mapping rather than inferring floor restrictions from the fact that the reader accepted a credential.\n\n## Official reference\n\n[Ubiquiti Help Center — Configuring UniFi Access Elevator Hub](https://help.ui.com/hc/en-us/articles/20050307166231-Configuring-UniFi-Access-Elevator-Hub). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/check-how-unifi-reader-admin-mode-differs-from-normal-two-step-entry/", "slug": "check-how-unifi-reader-admin-mode-differs-from-normal-two-step-entry", "url": "https://update.dsesecurity.com/updates/check-how-unifi-reader-admin-mode-differs-from-normal-two-step-entry/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-how-unifi-reader-admin-mode-differs-from-normal-two-step-entry.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-how-unifi-reader-admin-mode-differs-from-normal-two-step-entry/" }, "title": "Check how UniFi reader Admin Mode differs from normal two-step entry", "summary": "Review local administrator credentials alongside two-step entry so the documented Admin Mode boundary stays visible.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:10+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 283, "potentially_affected": "Applies to supported UniFi Access two-step readers and their documented Admin Mode behavior. This is a boundary in the product’s workflow, not a claim that every administrative action has identical authorization.", "dse_recommendation": "DSE recommends reviewing local administrator credentials whenever a site adopts two-step entry.", "primary_source": { "name": "Ubiquiti Help Center — Configuring Door Unlock Methods in UniFi Access", "url": "https://help.ui.com/hc/en-us/articles/17459303874327-Configuring-Door-Unlock-Methods-in-UniFi-Access", "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": "Review local administrator credentials alongside two-step entry so the documented Admin Mode boundary stays visible.
\nUniFi Access two-step entry can require two enabled methods or an additional designated approver within the configured time window. The guide separately states that this requirement applies to normal door-unlock workflows, not entry into Admin Mode on camera-equipped readers. Access admins can enter that mode with their assigned NFC card or PIN even when two-step entry is enabled. The feature also has specific application, console, hub, and reader firmware requirements rather than applying uniformly to every reader.
\nSource: Ubiquiti Help Center — Configuring Door Unlock Methods in UniFi Access.
\nApplies to supported UniFi Access two-step readers and their documented Admin Mode behavior. This is a boundary in the product’s workflow, not a claim that every administrative action has identical authorization.
\nDSE recommends reviewing local administrator credentials whenever a site adopts two-step entry. Document who can enter reader Admin Mode and distinguish that authority from the ordinary user’s two-method requirement. Confirm the supported hardware and firmware set before rollout, and decide whether the goal is two credentials from one person or approval by another person. Include these choices in staff training so the word two-step is not treated as a universal description of all reader interactions.
\nOn an approved reader, test an ordinary user’s configured entry sequence, an absent or late second step, and a designated administrator’s Admin Mode entry. Confirm the intended privilege boundaries without leaving an administrative session unattended. Record device versions and tested account types so results are not generalized to unsupported readers.
\nUbiquiti Help Center — Configuring Door Unlock Methods in UniFi Access. Reviewed October 15, 2026.
", "content_text": "Review local administrator credentials alongside two-step entry so the documented Admin Mode boundary stays visible.\nSource facts\nUniFi Access two-step entry can require two enabled methods or an additional designated approver within the configured time window. The guide separately states that this requirement applies to normal door-unlock workflows, not entry into Admin Mode on camera-equipped readers. Access admins can enter that mode with their assigned NFC card or PIN even when two-step entry is enabled. The feature also has specific application, console, hub, and reader firmware requirements rather than applying uniformly to every reader.\nSource: Ubiquiti Help Center — Configuring Door Unlock Methods in UniFi Access.\nApplicability\nApplies to supported UniFi Access two-step readers and their documented Admin Mode behavior. This is a boundary in the product’s workflow, not a claim that every administrative action has identical authorization.\nDSE recommendation\nDSE recommends reviewing local administrator credentials whenever a site adopts two-step entry. Document who can enter reader Admin Mode and distinguish that authority from the ordinary user’s two-method requirement. Confirm the supported hardware and firmware set before rollout, and decide whether the goal is two credentials from one person or approval by another person. Include these choices in staff training so the word two-step is not treated as a universal description of all reader interactions.\nVerification\nOn an approved reader, test an ordinary user’s configured entry sequence, an absent or late second step, and a designated administrator’s Admin Mode entry. Confirm the intended privilege boundaries without leaving an administrative session unattended. Record device versions and tested account types so results are not generalized to unsupported readers.\nOfficial reference\nUbiquiti Help Center — Configuring Door Unlock Methods in UniFi Access. Reviewed October 15, 2026.", "content_markdown": "Review local administrator credentials alongside two-step entry so the documented Admin Mode boundary stays visible.\n\n## Source facts\n\nUniFi Access two-step entry can require two enabled methods or an additional designated approver within the configured time window. The guide separately states that this requirement applies to normal door-unlock workflows, not entry into Admin Mode on camera-equipped readers. Access admins can enter that mode with their assigned NFC card or PIN even when two-step entry is enabled. The feature also has specific application, console, hub, and reader firmware requirements rather than applying uniformly to every reader.\n\nSource: [Ubiquiti Help Center — Configuring Door Unlock Methods in UniFi Access](https://help.ui.com/hc/en-us/articles/17459303874327-Configuring-Door-Unlock-Methods-in-UniFi-Access).\n\n## Applicability\n\nApplies to supported UniFi Access two-step readers and their documented Admin Mode behavior. This is a boundary in the product’s workflow, not a claim that every administrative action has identical authorization.\n\n## DSE recommendation\n\nDSE recommends reviewing local administrator credentials whenever a site adopts two-step entry. Document who can enter reader Admin Mode and distinguish that authority from the ordinary user’s two-method requirement. Confirm the supported hardware and firmware set before rollout, and decide whether the goal is two credentials from one person or approval by another person. Include these choices in staff training so the word two-step is not treated as a universal description of all reader interactions.\n\n## Verification\n\nOn an approved reader, test an ordinary user’s configured entry sequence, an absent or late second step, and a designated administrator’s Admin Mode entry. Confirm the intended privilege boundaries without leaving an administrative session unattended. Record device versions and tested account types so results are not generalized to unsupported readers.\n\n## Official reference\n\n[Ubiquiti Help Center — Configuring Door Unlock Methods in UniFi Access](https://help.ui.com/hc/en-us/articles/17459303874327-Configuring-Door-Unlock-Methods-in-UniFi-Access). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/distinguish-touch-pass-unbinding-from-suspension-and-reassignment/", "slug": "distinguish-touch-pass-unbinding-from-suspension-and-reassignment", "url": "https://update.dsesecurity.com/updates/distinguish-touch-pass-unbinding-from-suspension-and-reassignment/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/distinguish-touch-pass-unbinding-from-suspension-and-reassignment.md", "json": "https://update.dsesecurity.com/api/v1/posts/distinguish-touch-pass-unbinding-from-suspension-and-reassignment/" }, "title": "Distinguish Touch Pass unbinding from suspension and reassignment", "summary": "Choose the pass action according to device replacement, temporary suspension, staff reassignment, or console migration.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:09+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 277, "potentially_affected": "Applies to the Touch Pass lifecycle documented in UniFi Access, including supported wallet devices and consoles. This article does not assume that unbinding a phone revokes every credential the person holds.", "dse_recommendation": "DSE recommends selecting the action according to the actual business event.", "primary_source": { "name": "Ubiquiti Help Center — Configuring Touch Pass in UniFi Access", "url": "https://help.ui.com/hc/en-us/articles/27130425853079-Configuring-Touch-Pass-in-UniFi-Access", "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": "Choose the pass action according to device replacement, temporary suspension, staff reassignment, or console migration.
\nUniFi Touch Pass management distinguishes unbinding, suspension, and reassignment. Unbinding removes the pass from the current device but keeps it owned by the same user and associated iCloud or Google account. It does not return the pass to a pool for another user; the guide directs administrators to Technical Support for that transfer. Suspension temporarily disables door unlocking, while Resume reactivates the pass. Restoring passes onto another console removes them from the original console and requires reassignment.
\nSource: Ubiquiti Help Center — Configuring Touch Pass in UniFi Access.
\nApplies to the Touch Pass lifecycle documented in UniFi Access, including supported wallet devices and consoles. This article does not assume that unbinding a phone revokes every credential the person holds.
\nDSE recommends selecting the action according to the actual business event. Distinguish a replacement phone, temporary suspension, staff departure, and console replacement in the support procedure. Check other credentials separately when access must end. Keep the wallet-account ownership decision with the user and use the vendor-supported reassignment path instead of repeatedly unbinding the device. During console migration, coordinate pass restoration with user communication and a fallback entry method approved by the access owner.
\nUse an approved test pass to confirm the old device no longer works after unbinding and that the same owner can activate the intended replacement. For a suspension test, verify denial and controlled resumption. Review the pass’s owner and console association after restoration without capturing wallet secrets or private account data.
\nUbiquiti Help Center — Configuring Touch Pass in UniFi Access. Reviewed October 15, 2026.
", "content_text": "Choose the pass action according to device replacement, temporary suspension, staff reassignment, or console migration.\nSource facts\nUniFi Touch Pass management distinguishes unbinding, suspension, and reassignment. Unbinding removes the pass from the current device but keeps it owned by the same user and associated iCloud or Google account. It does not return the pass to a pool for another user; the guide directs administrators to Technical Support for that transfer. Suspension temporarily disables door unlocking, while Resume reactivates the pass. Restoring passes onto another console removes them from the original console and requires reassignment.\nSource: Ubiquiti Help Center — Configuring Touch Pass in UniFi Access.\nApplicability\nApplies to the Touch Pass lifecycle documented in UniFi Access, including supported wallet devices and consoles. This article does not assume that unbinding a phone revokes every credential the person holds.\nDSE recommendation\nDSE recommends selecting the action according to the actual business event. Distinguish a replacement phone, temporary suspension, staff departure, and console replacement in the support procedure. Check other credentials separately when access must end. Keep the wallet-account ownership decision with the user and use the vendor-supported reassignment path instead of repeatedly unbinding the device. During console migration, coordinate pass restoration with user communication and a fallback entry method approved by the access owner.\nVerification\nUse an approved test pass to confirm the old device no longer works after unbinding and that the same owner can activate the intended replacement. For a suspension test, verify denial and controlled resumption. Review the pass’s owner and console association after restoration without capturing wallet secrets or private account data.\nOfficial reference\nUbiquiti Help Center — Configuring Touch Pass in UniFi Access. Reviewed October 15, 2026.", "content_markdown": "Choose the pass action according to device replacement, temporary suspension, staff reassignment, or console migration.\n\n## Source facts\n\nUniFi Touch Pass management distinguishes unbinding, suspension, and reassignment. Unbinding removes the pass from the current device but keeps it owned by the same user and associated iCloud or Google account. It does not return the pass to a pool for another user; the guide directs administrators to Technical Support for that transfer. Suspension temporarily disables door unlocking, while Resume reactivates the pass. Restoring passes onto another console removes them from the original console and requires reassignment.\n\nSource: [Ubiquiti Help Center — Configuring Touch Pass in UniFi Access](https://help.ui.com/hc/en-us/articles/27130425853079-Configuring-Touch-Pass-in-UniFi-Access).\n\n## Applicability\n\nApplies to the Touch Pass lifecycle documented in UniFi Access, including supported wallet devices and consoles. This article does not assume that unbinding a phone revokes every credential the person holds.\n\n## DSE recommendation\n\nDSE recommends selecting the action according to the actual business event. Distinguish a replacement phone, temporary suspension, staff departure, and console replacement in the support procedure. Check other credentials separately when access must end. Keep the wallet-account ownership decision with the user and use the vendor-supported reassignment path instead of repeatedly unbinding the device. During console migration, coordinate pass restoration with user communication and a fallback entry method approved by the access owner.\n\n## Verification\n\nUse an approved test pass to confirm the old device no longer works after unbinding and that the same owner can activate the intended replacement. For a suspension test, verify denial and controlled resumption. Review the pass’s owner and console association after restoration without capturing wallet secrets or private account data.\n\n## Official reference\n\n[Ubiquiti Help Center — Configuring Touch Pass in UniFi Access](https://help.ui.com/hc/en-us/articles/27130425853079-Configuring-Touch-Pass-in-UniFi-Access). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/verify-the-td63-controller-connection-required-for-keypad-unlocking/", "slug": "verify-the-td63-controller-connection-required-for-keypad-unlocking", "url": "https://update.dsesecurity.com/updates/verify-the-td63-controller-connection-required-for-keypad-unlocking/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/verify-the-td63-controller-connection-required-for-keypad-unlocking.md", "json": "https://update.dsesecurity.com/api/v1/posts/verify-the-td63-controller-connection-required-for-keypad-unlocking/" }, "title": "Verify the TD63 controller connection required for keypad unlocking", "summary": "Check the door mode and required controller connection before replacing valid keypad credentials during troubleshooting.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:08+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 TD63 and the door modes described in the second-generation intercom guide. A working IP connection or intercom call alone does not establish the required keypad-unlock wiring path.", "dse_recommendation": "DSE recommends confirming the intended door mode and controller relationship during design review.", "primary_source": { "name": "Verkada Help — Configure Second-Generation Video Intercoms", "url": "https://help.verkada.com/intercom/configuration/wire-a-video-intercom/configure-second-generation-video-intercoms", "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": "Check the door mode and required controller connection before replacing valid keypad credentials during troubleshooting.
\nVerkada’s second-generation intercom guide limits TD63 keypad unlocking to two door modes: a door directly connected to the intercom or a door paired to a Verkada controller. For the paired-controller mode, the intercom’s RS485 output must also be hardwired to that controller. The guide distinguishes where unlock settings are managed: directly connected and third-party-controller modes expose the intercom unlock menu, while a paired Verkada controller owns those settings. Keypad entry codes are submitted with the pound key.
\nSource: Verkada Help — Configure Second-Generation Video Intercoms.
\nApplies to the TD63 and the door modes described in the second-generation intercom guide. A working IP connection or intercom call alone does not establish the required keypad-unlock wiring path.
\nDSE recommends confirming the intended door mode and controller relationship during design review. Have a qualified installer document the RS485 connection where the paired-controller workflow requires it, using the manufacturer’s wiring instructions. Give service staff a clear record of which device owns unlock configuration. If calls work but keypad entry does not, check that architecture before changing valid visitor codes or expanding access permissions. Coordinate any wiring work with the approved door-control maintenance process.
\nAt the pilot entrance, inspect the configured door mode and documented controller connection, then test an authorized temporary code followed by the required submission key. Verify the intended door and event record. Include an invalid controlled code as a negative case and confirm ordinary approved entry still works after the change.
\nVerkada Help — Configure Second-Generation Video Intercoms. Reviewed October 15, 2026.
", "content_text": "Check the door mode and required controller connection before replacing valid keypad credentials during troubleshooting.\nSource facts\nVerkada’s second-generation intercom guide limits TD63 keypad unlocking to two door modes: a door directly connected to the intercom or a door paired to a Verkada controller. For the paired-controller mode, the intercom’s RS485 output must also be hardwired to that controller. The guide distinguishes where unlock settings are managed: directly connected and third-party-controller modes expose the intercom unlock menu, while a paired Verkada controller owns those settings. Keypad entry codes are submitted with the pound key.\nSource: Verkada Help — Configure Second-Generation Video Intercoms.\nApplicability\nApplies to the TD63 and the door modes described in the second-generation intercom guide. A working IP connection or intercom call alone does not establish the required keypad-unlock wiring path.\nDSE recommendation\nDSE recommends confirming the intended door mode and controller relationship during design review. Have a qualified installer document the RS485 connection where the paired-controller workflow requires it, using the manufacturer’s wiring instructions. Give service staff a clear record of which device owns unlock configuration. If calls work but keypad entry does not, check that architecture before changing valid visitor codes or expanding access permissions. Coordinate any wiring work with the approved door-control maintenance process.\nVerification\nAt the pilot entrance, inspect the configured door mode and documented controller connection, then test an authorized temporary code followed by the required submission key. Verify the intended door and event record. Include an invalid controlled code as a negative case and confirm ordinary approved entry still works after the change.\nOfficial reference\nVerkada Help — Configure Second-Generation Video Intercoms. Reviewed October 15, 2026.", "content_markdown": "Check the door mode and required controller connection before replacing valid keypad credentials during troubleshooting.\n\n## Source facts\n\nVerkada’s second-generation intercom guide limits TD63 keypad unlocking to two door modes: a door directly connected to the intercom or a door paired to a Verkada controller. For the paired-controller mode, the intercom’s RS485 output must also be hardwired to that controller. The guide distinguishes where unlock settings are managed: directly connected and third-party-controller modes expose the intercom unlock menu, while a paired Verkada controller owns those settings. Keypad entry codes are submitted with the pound key.\n\nSource: [Verkada Help — Configure Second-Generation Video Intercoms](https://help.verkada.com/intercom/configuration/wire-a-video-intercom/configure-second-generation-video-intercoms).\n\n## Applicability\n\nApplies to the TD63 and the door modes described in the second-generation intercom guide. A working IP connection or intercom call alone does not establish the required keypad-unlock wiring path.\n\n## DSE recommendation\n\nDSE recommends confirming the intended door mode and controller relationship during design review. Have a qualified installer document the RS485 connection where the paired-controller workflow requires it, using the manufacturer’s wiring instructions. Give service staff a clear record of which device owns unlock configuration. If calls work but keypad entry does not, check that architecture before changing valid visitor codes or expanding access permissions. Coordinate any wiring work with the approved door-control maintenance process.\n\n## Verification\n\nAt the pilot entrance, inspect the configured door mode and documented controller connection, then test an authorized temporary code followed by the required submission key. Verify the intended door and event record. Include an invalid controlled code as a negative case and confirm ordinary approved entry still works after the change.\n\n## Official reference\n\n[Verkada Help — Configure Second-Generation Video Intercoms](https://help.verkada.com/intercom/configuration/wire-a-video-intercom/configure-second-generation-video-intercoms). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/match-verkada-alarm-arming-and-disarming-to-supported-access-methods/", "slug": "match-verkada-alarm-arming-and-disarming-to-supported-access-methods", "url": "https://update.dsesecurity.com/updates/match-verkada-alarm-arming-and-disarming-to-supported-access-methods/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/match-verkada-alarm-arming-and-disarming-to-supported-access-methods.md", "json": "https://update.dsesecurity.com/api/v1/posts/match-verkada-alarm-arming-and-disarming-to-supported-access-methods/" }, "title": "Match Verkada alarm arming and disarming to supported access methods", "summary": "Test the alarm effect of every intended access method instead of equating a successful door unlock with disarming.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:07+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 268, "potentially_affected": "Applies to New Alarms, not the separate Classic Alarms product. Confirm the actual partition type and supported method list before adding an access-controlled entrance to an alarm workflow.", "dse_recommendation": "DSE recommends creating a method-by-partition acceptance table with the alarm owner.", "primary_source": { "name": "Verkada Help — Configure New Alarms Site Settings", "url": "https://help.verkada.com/new-alarms/configuration/alarm-sites/configure-new-alarms-site-settings", "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": "Test the alarm effect of every intended access method instead of equating a successful door unlock with disarming.
\nVerkada New Alarms can use selected access-controlled doors to arm and disarm associated partitions. The supported methods differ: the guide allows Bluetooth unlock to disarm but not to perform double-badge arming, and it excludes remote and nearby unlock from supported disarming events. Selected doors must be in the same site as the alarm site. Camera-partition actions use the cloud, while sensor partitions with an alarm panel use local peer-to-peer communication for the documented disarm interaction.
\nSource: Verkada Help — Configure New Alarms Site Settings.
\nApplies to New Alarms, not the separate Classic Alarms product. Confirm the actual partition type and supported method list before adding an access-controlled entrance to an alarm workflow.
\nDSE recommends creating a method-by-partition acceptance table with the alarm owner. Staff should know whether presenting a badge, using Bluetooth, or pressing remote unlock has the expected alarm effect. Identify entry and exit procedures for employees and cleaners and preserve any panic-related protection in the approved alarm design. Test under a scheduled maintenance arrangement with monitoring personnel as required; do not assume a successful door unlock proves a partition disarmed.
\nUse the approved alarm test process to check each intended credential method and inspect the actual partition state. Include a remote unlock as a negative case if staff might expect it to disarm. Record site, partition type, method, reader feedback, and state without generating an uncoordinated dispatch or leaving protection unintentionally disabled.
\nVerkada Help — Configure New Alarms Site Settings. Reviewed October 15, 2026.
", "content_text": "Test the alarm effect of every intended access method instead of equating a successful door unlock with disarming.\nSource facts\nVerkada New Alarms can use selected access-controlled doors to arm and disarm associated partitions. The supported methods differ: the guide allows Bluetooth unlock to disarm but not to perform double-badge arming, and it excludes remote and nearby unlock from supported disarming events. Selected doors must be in the same site as the alarm site. Camera-partition actions use the cloud, while sensor partitions with an alarm panel use local peer-to-peer communication for the documented disarm interaction.\nSource: Verkada Help — Configure New Alarms Site Settings.\nApplicability\nApplies to New Alarms, not the separate Classic Alarms product. Confirm the actual partition type and supported method list before adding an access-controlled entrance to an alarm workflow.\nDSE recommendation\nDSE recommends creating a method-by-partition acceptance table with the alarm owner. Staff should know whether presenting a badge, using Bluetooth, or pressing remote unlock has the expected alarm effect. Identify entry and exit procedures for employees and cleaners and preserve any panic-related protection in the approved alarm design. Test under a scheduled maintenance arrangement with monitoring personnel as required; do not assume a successful door unlock proves a partition disarmed.\nVerification\nUse the approved alarm test process to check each intended credential method and inspect the actual partition state. Include a remote unlock as a negative case if staff might expect it to disarm. Record site, partition type, method, reader feedback, and state without generating an uncoordinated dispatch or leaving protection unintentionally disabled.\nOfficial reference\nVerkada Help — Configure New Alarms Site Settings. Reviewed October 15, 2026.", "content_markdown": "Test the alarm effect of every intended access method instead of equating a successful door unlock with disarming.\n\n## Source facts\n\nVerkada New Alarms can use selected access-controlled doors to arm and disarm associated partitions. The supported methods differ: the guide allows Bluetooth unlock to disarm but not to perform double-badge arming, and it excludes remote and nearby unlock from supported disarming events. Selected doors must be in the same site as the alarm site. Camera-partition actions use the cloud, while sensor partitions with an alarm panel use local peer-to-peer communication for the documented disarm interaction.\n\nSource: [Verkada Help — Configure New Alarms Site Settings](https://help.verkada.com/new-alarms/configuration/alarm-sites/configure-new-alarms-site-settings).\n\n## Applicability\n\nApplies to New Alarms, not the separate Classic Alarms product. Confirm the actual partition type and supported method list before adding an access-controlled entrance to an alarm workflow.\n\n## DSE recommendation\n\nDSE recommends creating a method-by-partition acceptance table with the alarm owner. Staff should know whether presenting a badge, using Bluetooth, or pressing remote unlock has the expected alarm effect. Identify entry and exit procedures for employees and cleaners and preserve any panic-related protection in the approved alarm design. Test under a scheduled maintenance arrangement with monitoring personnel as required; do not assume a successful door unlock proves a partition disarmed.\n\n## Verification\n\nUse the approved alarm test process to check each intended credential method and inspect the actual partition state. Include a remote unlock as a negative case if staff might expect it to disarm. Record site, partition type, method, reader feedback, and state without generating an uncoordinated dispatch or leaving protection unintentionally disabled.\n\n## Official reference\n\n[Verkada Help — Configure New Alarms Site Settings](https://help.verkada.com/new-alarms/configuration/alarm-sites/configure-new-alarms-site-settings). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/check-persona-mode-and-exception-limits-before-migrating-in120-or-in220-locks/", "slug": "check-persona-mode-and-exception-limits-before-migrating-in120-or-in220-locks", "url": "https://update.dsesecurity.com/updates/check-persona-mode-and-exception-limits-before-migrating-in120-or-in220-locks/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/check-persona-mode-and-exception-limits-before-migrating-in120-or-in220-locks.md", "json": "https://update.dsesecurity.com/api/v1/posts/check-persona-mode-and-exception-limits-before-migrating-in120-or-in220-locks/" }, "title": "Check Persona Mode and exception limits before migrating IN120 or IN220 locks", "summary": "Resolve unsupported exception workflows before migrating these locks, and preserve the configuration needed for reclaim.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:06+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 276, "potentially_affected": "Applies to ASSA ABLOY IN120 and IN220 locks integrated through the documented Verkada DSR path. Do not apply capabilities from wired doors or other wireless lock families to these models.", "dse_recommendation": "DSE recommends checking the lock mode and supported exception behavior before approving a migration design.", "primary_source": { "name": "Verkada Help — Assa Abloy IN120/IN220 Setup", "url": "https://help.verkada.com/access-control/installation/wiring-best-practices-for-third-party-wireless-locks/assa-abloy-in120in220-setup", "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": "Resolve unsupported exception workflows before migrating these locks, and preserve the configuration needed for reclaim.
\nVerkada’s IN120/IN220 integration uses an ASSA ABLOY Door Service Router and Lock Configuration Tool. The guide says LCT does not need to run on the same Windows computer as DSR. It requires Persona Mode for full functionality and warns that features such as Double Badge may otherwise behave incorrectly. The documented integration does not support door exceptions on these models. Moving a door to another site requires removing it from the current site and reclaiming it through the DSR workflow.
\nSource: Verkada Help — Assa Abloy IN120/IN220 Setup.
\nApplies to ASSA ABLOY IN120 and IN220 locks integrated through the documented Verkada DSR path. Do not apply capabilities from wired doors or other wireless lock families to these models.
\nDSE recommends checking the lock mode and supported exception behavior before approving a migration design. List any holiday, temporary-access, or event workflow that depends on an exception and resolve unsupported requirements before cutover. Keep the DSR and LCT ownership documented even when they run on separate computers. Schedule site moves as coordinated reclaims and preserve the original site and lock configuration for troubleshooting rather than assuming the door can simply be dragged between sites.
\nOn an approved pilot lock, confirm Persona Mode and exercise the required supported operations. Inspect whether the project relies on an unsupported exception and document the chosen alternative with the owner. For a site move, verify DSR communication and the destination assignment before treating the door as restored to service.
\nVerkada Help — Assa Abloy IN120/IN220 Setup. Reviewed October 15, 2026.
", "content_text": "Resolve unsupported exception workflows before migrating these locks, and preserve the configuration needed for reclaim.\nSource facts\nVerkada’s IN120/IN220 integration uses an ASSA ABLOY Door Service Router and Lock Configuration Tool. The guide says LCT does not need to run on the same Windows computer as DSR. It requires Persona Mode for full functionality and warns that features such as Double Badge may otherwise behave incorrectly. The documented integration does not support door exceptions on these models. Moving a door to another site requires removing it from the current site and reclaiming it through the DSR workflow.\nSource: Verkada Help — Assa Abloy IN120/IN220 Setup.\nApplicability\nApplies to ASSA ABLOY IN120 and IN220 locks integrated through the documented Verkada DSR path. Do not apply capabilities from wired doors or other wireless lock families to these models.\nDSE recommendation\nDSE recommends checking the lock mode and supported exception behavior before approving a migration design. List any holiday, temporary-access, or event workflow that depends on an exception and resolve unsupported requirements before cutover. Keep the DSR and LCT ownership documented even when they run on separate computers. Schedule site moves as coordinated reclaims and preserve the original site and lock configuration for troubleshooting rather than assuming the door can simply be dragged between sites.\nVerification\nOn an approved pilot lock, confirm Persona Mode and exercise the required supported operations. Inspect whether the project relies on an unsupported exception and document the chosen alternative with the owner. For a site move, verify DSR communication and the destination assignment before treating the door as restored to service.\nOfficial reference\nVerkada Help — Assa Abloy IN120/IN220 Setup. Reviewed October 15, 2026.", "content_markdown": "Resolve unsupported exception workflows before migrating these locks, and preserve the configuration needed for reclaim.\n\n## Source facts\n\nVerkada’s IN120/IN220 integration uses an ASSA ABLOY Door Service Router and Lock Configuration Tool. The guide says LCT does not need to run on the same Windows computer as DSR. It requires Persona Mode for full functionality and warns that features such as Double Badge may otherwise behave incorrectly. The documented integration does not support door exceptions on these models. Moving a door to another site requires removing it from the current site and reclaiming it through the DSR workflow.\n\nSource: [Verkada Help — Assa Abloy IN120/IN220 Setup](https://help.verkada.com/access-control/installation/wiring-best-practices-for-third-party-wireless-locks/assa-abloy-in120in220-setup).\n\n## Applicability\n\nApplies to ASSA ABLOY IN120 and IN220 locks integrated through the documented Verkada DSR path. Do not apply capabilities from wired doors or other wireless lock families to these models.\n\n## DSE recommendation\n\nDSE recommends checking the lock mode and supported exception behavior before approving a migration design. List any holiday, temporary-access, or event workflow that depends on an exception and resolve unsupported requirements before cutover. Keep the DSR and LCT ownership documented even when they run on separate computers. Schedule site moves as coordinated reclaims and preserve the original site and lock configuration for troubleshooting rather than assuming the door can simply be dragged between sites.\n\n## Verification\n\nOn an approved pilot lock, confirm Persona Mode and exercise the required supported operations. Inspect whether the project relies on an unsupported exception and document the chosen alternative with the owner. For a site move, verify DSR communication and the destination assignment before treating the door as restored to service.\n\n## Official reference\n\n[Verkada Help — Assa Abloy IN120/IN220 Setup](https://help.verkada.com/access-control/installation/wiring-best-practices-for-third-party-wireless-locks/assa-abloy-in120in220-setup). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/proof-badge-data-and-browser-print-dimensions-before-a-bulk-print-run/", "slug": "proof-badge-data-and-browser-print-dimensions-before-a-bulk-print-run", "url": "https://update.dsesecurity.com/updates/proof-badge-data-and-browser-print-dimensions-before-a-bulk-print-run/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/proof-badge-data-and-browser-print-dimensions-before-a-bulk-print-run.md", "json": "https://update.dsesecurity.com/api/v1/posts/proof-badge-data-and-browser-print-dimensions-before-a-bulk-print-run/" }, "title": "Proof badge data and browser print dimensions before a bulk print run", "summary": "Proof data ownership, missing-field handling, and actual print alignment before issuing a large badge run.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:05+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 Access badge layout and browser printing. A visually printed badge is distinct from the credential’s encoded value and assigned door permissions, which require separate administration.", "dse_recommendation": "DSE recommends proofing a representative badge before a bulk run.", "primary_source": { "name": "Verkada Help — Print Access Control Badges", "url": "https://help.verkada.com/access-control/users-and-credentials/add-a-user-to-the-verkada-access-system/print-access-control-badges", "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": "Proof data ownership, missing-field handling, and actual print alignment before issuing a large badge run.
\nVerkada badge templates can use supported user fields such as name, title, department, and company. User data can be maintained manually, imported by CSV, or synchronized through SCIM. Template management requires the documented Access System Admin role. Printing uses the workstation’s installed printer driver and browser print preview; the guide calls for matching badge dimensions and zero margins. Bulk printing warns when required fields are missing but offers a Print Anyway override, so the warning alone does not prevent incomplete badges.
\nSource: Verkada Help — Print Access Control Badges.
\nApplies to Verkada Access badge layout and browser printing. A visually printed badge is distinct from the credential’s encoded value and assigned door permissions, which require separate administration.
\nDSE recommends proofing a representative badge before a bulk run. Check long names, missing titles, photos, and the approved organizational branding using controlled test records. Confirm whether SCIM or another source owns each field before making a manual correction that could be overwritten. Restrict use of the missing-data override to an approved exception and reconcile every printed badge with its intended recipient. Store sample files according to the organization’s personal-data handling rules.
\nPrint a controlled sample using the actual printer, stock, and duplex settings, then inspect alignment and legibility. Confirm missing-field warnings appear on a deliberate test record and stop before bulk printing unresolved records. Compare the final recipient list with the print selection and separately verify credential assignment where required.
\nVerkada Help — Print Access Control Badges. Reviewed October 15, 2026.
", "content_text": "Proof data ownership, missing-field handling, and actual print alignment before issuing a large badge run.\nSource facts\nVerkada badge templates can use supported user fields such as name, title, department, and company. User data can be maintained manually, imported by CSV, or synchronized through SCIM. Template management requires the documented Access System Admin role. Printing uses the workstation’s installed printer driver and browser print preview; the guide calls for matching badge dimensions and zero margins. Bulk printing warns when required fields are missing but offers a Print Anyway override, so the warning alone does not prevent incomplete badges.\nSource: Verkada Help — Print Access Control Badges.\nApplicability\nApplies to Verkada Access badge layout and browser printing. A visually printed badge is distinct from the credential’s encoded value and assigned door permissions, which require separate administration.\nDSE recommendation\nDSE recommends proofing a representative badge before a bulk run. Check long names, missing titles, photos, and the approved organizational branding using controlled test records. Confirm whether SCIM or another source owns each field before making a manual correction that could be overwritten. Restrict use of the missing-data override to an approved exception and reconcile every printed badge with its intended recipient. Store sample files according to the organization’s personal-data handling rules.\nVerification\nPrint a controlled sample using the actual printer, stock, and duplex settings, then inspect alignment and legibility. Confirm missing-field warnings appear on a deliberate test record and stop before bulk printing unresolved records. Compare the final recipient list with the print selection and separately verify credential assignment where required.\nOfficial reference\nVerkada Help — Print Access Control Badges. Reviewed October 15, 2026.", "content_markdown": "Proof data ownership, missing-field handling, and actual print alignment before issuing a large badge run.\n\n## Source facts\n\nVerkada badge templates can use supported user fields such as name, title, department, and company. User data can be maintained manually, imported by CSV, or synchronized through SCIM. Template management requires the documented Access System Admin role. Printing uses the workstation’s installed printer driver and browser print preview; the guide calls for matching badge dimensions and zero margins. Bulk printing warns when required fields are missing but offers a Print Anyway override, so the warning alone does not prevent incomplete badges.\n\nSource: [Verkada Help — Print Access Control Badges](https://help.verkada.com/access-control/users-and-credentials/add-a-user-to-the-verkada-access-system/print-access-control-badges).\n\n## Applicability\n\nApplies to Verkada Access badge layout and browser printing. A visually printed badge is distinct from the credential’s encoded value and assigned door permissions, which require separate administration.\n\n## DSE recommendation\n\nDSE recommends proofing a representative badge before a bulk run. Check long names, missing titles, photos, and the approved organizational branding using controlled test records. Confirm whether SCIM or another source owns each field before making a manual correction that could be overwritten. Restrict use of the missing-data override to an approved exception and reconcile every printed badge with its intended recipient. Store sample files according to the organization’s personal-data handling rules.\n\n## Verification\n\nPrint a controlled sample using the actual printer, stock, and duplex settings, then inspect alignment and legibility. Confirm missing-field warnings appear on a deliberate test record and stop before bulk printing unresolved records. Compare the final recipient list with the print selection and separately verify credential assignment where required.\n\n## Official reference\n\n[Verkada Help — Print Access Control Badges](https://help.verkada.com/access-control/users-and-credentials/add-a-user-to-the-verkada-access-system/print-access-control-badges). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/distinguish-an-al54-lost-hub-indication-from-a-rejected-credential/", "slug": "distinguish-an-al54-lost-hub-indication-from-a-rejected-credential", "url": "https://update.dsesecurity.com/updates/distinguish-an-al54-lost-hub-indication-from-a-rejected-credential/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/distinguish-an-al54-lost-hub-indication-from-a-rejected-credential.md", "json": "https://update.dsesecurity.com/api/v1/posts/distinguish-an-al54-lost-hub-indication-from-a-rejected-credential/" }, "title": "Distinguish an AL54 lost-hub indication from a rejected credential", "summary": "Ask which AL54 indicator flashed and during which action before treating the report as a credential denial.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:04+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 276, "potentially_affected": "Applies specifically to the AL54 LED pattern guide. Interpret colors with the observed action and location on the lock; these meanings are not a general color standard for other readers.", "dse_recommendation": "DSE recommends training the service desk to ask which LED flashed, where it was, and what the user was doing.", "primary_source": { "name": "Verkada Help — Verkada Wireless Lock LED Patterns", "url": "https://help.verkada.com/access-control/installation/verkada-wireless-lock-command-setup/verkada-wireless-lock-led-patterns", "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": "Ask which AL54 indicator flashed and during which action before treating the report as a credential denial.
\nThe Verkada AL54 wireless lock uses distinct exterior LED indications for granted access, denied access, and a lost connection during a credential scan. The guide describes green for an accepted credential, brief red for denial, and brief white when a scan occurs while the hub connection is lost. Interior LEDs provide separate connection and persistent lock-state indications. Privacy Mode also differs from ordinary access control: the guide describes access being restricted to designated override groups while that state is active.
\nSource: Verkada Help — Verkada Wireless Lock LED Patterns.
\nApplies specifically to the AL54 LED pattern guide. Interpret colors with the observed action and location on the lock; these meanings are not a general color standard for other readers.
\nDSE recommends training the service desk to ask which LED flashed, where it was, and what the user was doing. Route a lost-hub indication toward connectivity checks instead of immediately replacing a credential or expanding access permissions. Keep the model-specific pattern guide with the maintenance record and identify who may use privacy overrides. Avoid changing a room’s privacy configuration merely to make a reported red indication disappear before its cause is understood.
\nDuring an approved service test, compare a known permitted credential and a deliberately excluded test credential, observing the exterior indicator and event record. If investigating connectivity, correlate the time with hub status without creating an unscheduled outage. Record the actual pattern and outcome rather than a user’s color description alone.
\nVerkada Help — Verkada Wireless Lock LED Patterns. Reviewed October 15, 2026.
", "content_text": "Ask which AL54 indicator flashed and during which action before treating the report as a credential denial.\nSource facts\nThe Verkada AL54 wireless lock uses distinct exterior LED indications for granted access, denied access, and a lost connection during a credential scan. The guide describes green for an accepted credential, brief red for denial, and brief white when a scan occurs while the hub connection is lost. Interior LEDs provide separate connection and persistent lock-state indications. Privacy Mode also differs from ordinary access control: the guide describes access being restricted to designated override groups while that state is active.\nSource: Verkada Help — Verkada Wireless Lock LED Patterns.\nApplicability\nApplies specifically to the AL54 LED pattern guide. Interpret colors with the observed action and location on the lock; these meanings are not a general color standard for other readers.\nDSE recommendation\nDSE recommends training the service desk to ask which LED flashed, where it was, and what the user was doing. Route a lost-hub indication toward connectivity checks instead of immediately replacing a credential or expanding access permissions. Keep the model-specific pattern guide with the maintenance record and identify who may use privacy overrides. Avoid changing a room’s privacy configuration merely to make a reported red indication disappear before its cause is understood.\nVerification\nDuring an approved service test, compare a known permitted credential and a deliberately excluded test credential, observing the exterior indicator and event record. If investigating connectivity, correlate the time with hub status without creating an unscheduled outage. Record the actual pattern and outcome rather than a user’s color description alone.\nOfficial reference\nVerkada Help — Verkada Wireless Lock LED Patterns. Reviewed October 15, 2026.", "content_markdown": "Ask which AL54 indicator flashed and during which action before treating the report as a credential denial.\n\n## Source facts\n\nThe Verkada AL54 wireless lock uses distinct exterior LED indications for granted access, denied access, and a lost connection during a credential scan. The guide describes green for an accepted credential, brief red for denial, and brief white when a scan occurs while the hub connection is lost. Interior LEDs provide separate connection and persistent lock-state indications. Privacy Mode also differs from ordinary access control: the guide describes access being restricted to designated override groups while that state is active.\n\nSource: [Verkada Help — Verkada Wireless Lock LED Patterns](https://help.verkada.com/access-control/installation/verkada-wireless-lock-command-setup/verkada-wireless-lock-led-patterns).\n\n## Applicability\n\nApplies specifically to the AL54 LED pattern guide. Interpret colors with the observed action and location on the lock; these meanings are not a general color standard for other readers.\n\n## DSE recommendation\n\nDSE recommends training the service desk to ask which LED flashed, where it was, and what the user was doing. Route a lost-hub indication toward connectivity checks instead of immediately replacing a credential or expanding access permissions. Keep the model-specific pattern guide with the maintenance record and identify who may use privacy overrides. Avoid changing a room’s privacy configuration merely to make a reported red indication disappear before its cause is understood.\n\n## Verification\n\nDuring an approved service test, compare a known permitted credential and a deliberately excluded test credential, observing the exterior indicator and event record. If investigating connectivity, correlate the time with hub status without creating an unscheduled outage. Record the actual pattern and outcome rather than a user’s color description alone.\n\n## Official reference\n\n[Verkada Help — Verkada Wireless Lock LED Patterns](https://help.verkada.com/access-control/installation/verkada-wireless-lock-command-setup/verkada-wireless-lock-led-patterns). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/control-who-can-use-double-badge-to-create-an-extended-unlock-override/", "slug": "control-who-can-use-double-badge-to-create-an-extended-unlock-override", "url": "https://update.dsesecurity.com/updates/control-who-can-use-double-badge-to-create-an-extended-unlock-override/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/control-who-can-use-double-badge-to-create-an-extended-unlock-override.md", "json": "https://update.dsesecurity.com/api/v1/posts/control-who-can-use-double-badge-to-create-an-extended-unlock-override/" }, "title": "Control who can use Double Badge to create an extended unlock override", "summary": "Approve extended-unlock authority separately from ordinary entry and identify who verifies return to the schedule.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:03+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 Verkada’s Double Badge schedule override and the supported reader/lock paths listed in its guide. This concerns an extended unlocked state, which is different from an ordinary timed entry.", "dse_recommendation": "DSE recommends approving override authority separately from routine door access.", "primary_source": { "name": "Verkada Help — Double Badge to Override Schedule", "url": "https://help.verkada.com/en/articles/8733506-double-badge-to-override-a-door-s-schedule", "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 extended-unlock authority separately from ordinary entry and identify who verifies return to the schedule.
\nVerkada Double Badge lets an authorized person change an access-controlled door to an unlocked override by presenting a credential twice within five seconds. A second Double Badge removes that override. If nobody removes it, the override also clears when the schedule moves to a new time window or at midnight. The feature can be limited to selected groups that already have door access. It affects only the door used, and Pass Bluetooth or remote unlock does not perform Double Badge.
\nSource: Verkada Help — Double Badge to Override Schedule.
\nApplies to Verkada’s Double Badge schedule override and the supported reader/lock paths listed in its guide. This concerns an extended unlocked state, which is different from an ordinary timed entry.
\nDSE recommends approving override authority separately from routine door access. Identify who may open the door for an event, who confirms it has returned to the scheduled state, and which schedule boundary ends the exception automatically. Train staff on the actual reader feedback and avoid assuming a second nearby door follows the first. Use groups with an accountable owner and review membership before events rather than giving everyone an undocumented extended-unlock capability.
\nAt an approved test door, verify a permitted credential creates and removes the override and an ordinary excluded credential cannot create it. Observe the next relevant schedule boundary and check that the door returns as intended. Record each tested door; do not infer that a shared schedule creates a shared override.
\nVerkada Help — Double Badge to Override Schedule. Reviewed October 15, 2026.
", "content_text": "Approve extended-unlock authority separately from ordinary entry and identify who verifies return to the schedule.\nSource facts\nVerkada Double Badge lets an authorized person change an access-controlled door to an unlocked override by presenting a credential twice within five seconds. A second Double Badge removes that override. If nobody removes it, the override also clears when the schedule moves to a new time window or at midnight. The feature can be limited to selected groups that already have door access. It affects only the door used, and Pass Bluetooth or remote unlock does not perform Double Badge.\nSource: Verkada Help — Double Badge to Override Schedule.\nApplicability\nApplies to Verkada’s Double Badge schedule override and the supported reader/lock paths listed in its guide. This concerns an extended unlocked state, which is different from an ordinary timed entry.\nDSE recommendation\nDSE recommends approving override authority separately from routine door access. Identify who may open the door for an event, who confirms it has returned to the scheduled state, and which schedule boundary ends the exception automatically. Train staff on the actual reader feedback and avoid assuming a second nearby door follows the first. Use groups with an accountable owner and review membership before events rather than giving everyone an undocumented extended-unlock capability.\nVerification\nAt an approved test door, verify a permitted credential creates and removes the override and an ordinary excluded credential cannot create it. Observe the next relevant schedule boundary and check that the door returns as intended. Record each tested door; do not infer that a shared schedule creates a shared override.\nOfficial reference\nVerkada Help — Double Badge to Override Schedule. Reviewed October 15, 2026.", "content_markdown": "Approve extended-unlock authority separately from ordinary entry and identify who verifies return to the schedule.\n\n## Source facts\n\nVerkada Double Badge lets an authorized person change an access-controlled door to an unlocked override by presenting a credential twice within five seconds. A second Double Badge removes that override. If nobody removes it, the override also clears when the schedule moves to a new time window or at midnight. The feature can be limited to selected groups that already have door access. It affects only the door used, and Pass Bluetooth or remote unlock does not perform Double Badge.\n\nSource: [Verkada Help — Double Badge to Override Schedule](https://help.verkada.com/en/articles/8733506-double-badge-to-override-a-door-s-schedule).\n\n## Applicability\n\nApplies to Verkada’s Double Badge schedule override and the supported reader/lock paths listed in its guide. This concerns an extended unlocked state, which is different from an ordinary timed entry.\n\n## DSE recommendation\n\nDSE recommends approving override authority separately from routine door access. Identify who may open the door for an event, who confirms it has returned to the scheduled state, and which schedule boundary ends the exception automatically. Train staff on the actual reader feedback and avoid assuming a second nearby door follows the first. Use groups with an accountable owner and review membership before events rather than giving everyone an undocumented extended-unlock capability.\n\n## Verification\n\nAt an approved test door, verify a permitted credential creates and removes the override and an ordinary excluded credential cannot create it. Observe the next relevant schedule boundary and check that the door returns as intended. Record each tested door; do not infer that a shared schedule creates a shared override.\n\n## Official reference\n\n[Verkada Help — Double Badge to Override Schedule](https://help.verkada.com/en/articles/8733506-double-badge-to-override-a-door-s-schedule). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/separate-visit-validity-dates-from-check-in-status-in-verkada-roll-call/", "slug": "separate-visit-validity-dates-from-check-in-status-in-verkada-roll-call", "url": "https://update.dsesecurity.com/updates/separate-visit-validity-dates-from-check-in-status-in-verkada-roll-call/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/separate-visit-validity-dates-from-check-in-status-in-verkada-roll-call.md", "json": "https://update.dsesecurity.com/api/v1/posts/separate-visit-validity-dates-from-check-in-status-in-verkada-roll-call/" }, "title": "Separate visit validity dates from check-in status in Verkada roll call", "summary": "Define the software roster around recorded arrivals and departures, then document its limits against physical presence.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:02+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 281, "potentially_affected": "Applies to Verkada Guest and Access visit data as described in the Visit Access Type guide. A software roster reflects configured visits and staff actions; this article does not certify physical presence.", "dse_recommendation": "DSE recommends reconciling the visitor roster definition before using it in an exercise.", "primary_source": { "name": "Verkada Help — Visitor Access & Visit Access Type", "url": "https://help.verkada.com/access-control/users-and-credentials/add-a-user-to-the-verkada-access-system/visitor-access-visit-access-type", "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": "Define the software roster around recorded arrivals and departures, then document its limits against physical presence.
\nVerkada Visit Access Types define allowed schedules, sites, doors, maximum duration, credentials, and roll-call inclusion. A visit’s start and end dates describe its temporary door-access period, while check-in and check-out describe when the person is considered on site for roll call. The guide says visitors become eligible for the associated active roll call at check-in and are removed at check-out. A visitor can have only one active visit, and visitors can be included in roll call without having door access.
\nSource: Verkada Help — Visitor Access & Visit Access Type.
\nApplies to Verkada Guest and Access visit data as described in the Visit Access Type guide. A software roster reflects configured visits and staff actions; this article does not certify physical presence.
\nDSE recommends reconciling the visitor roster definition before using it in an exercise. Identify which visit types include roll call, which sites receive those visitors, and who records arrival and departure. Do not substitute an invitation’s validity window for a confirmed arrival. Include escorted visitors who do not need door credentials when designing the roster. Agree how reception will correct an incomplete check-in or checkout and communicate that correction to the exercise coordinator.
\nUse controlled test visits representing not-yet-arrived, checked-in, and checked-out visitors, including one with no door access. Inspect the associated roll-call roster at each stage. Compare the software result with an observer’s record and document known omissions so a roster is not treated as proof that an unrecorded person is absent.
\nVerkada Help — Visitor Access & Visit Access Type. Reviewed October 15, 2026.
", "content_text": "Define the software roster around recorded arrivals and departures, then document its limits against physical presence.\nSource facts\nVerkada Visit Access Types define allowed schedules, sites, doors, maximum duration, credentials, and roll-call inclusion. A visit’s start and end dates describe its temporary door-access period, while check-in and check-out describe when the person is considered on site for roll call. The guide says visitors become eligible for the associated active roll call at check-in and are removed at check-out. A visitor can have only one active visit, and visitors can be included in roll call without having door access.\nSource: Verkada Help — Visitor Access & Visit Access Type.\nApplicability\nApplies to Verkada Guest and Access visit data as described in the Visit Access Type guide. A software roster reflects configured visits and staff actions; this article does not certify physical presence.\nDSE recommendation\nDSE recommends reconciling the visitor roster definition before using it in an exercise. Identify which visit types include roll call, which sites receive those visitors, and who records arrival and departure. Do not substitute an invitation’s validity window for a confirmed arrival. Include escorted visitors who do not need door credentials when designing the roster. Agree how reception will correct an incomplete check-in or checkout and communicate that correction to the exercise coordinator.\nVerification\nUse controlled test visits representing not-yet-arrived, checked-in, and checked-out visitors, including one with no door access. Inspect the associated roll-call roster at each stage. Compare the software result with an observer’s record and document known omissions so a roster is not treated as proof that an unrecorded person is absent.\nOfficial reference\nVerkada Help — Visitor Access & Visit Access Type. Reviewed October 15, 2026.", "content_markdown": "Define the software roster around recorded arrivals and departures, then document its limits against physical presence.\n\n## Source facts\n\nVerkada Visit Access Types define allowed schedules, sites, doors, maximum duration, credentials, and roll-call inclusion. A visit’s start and end dates describe its temporary door-access period, while check-in and check-out describe when the person is considered on site for roll call. The guide says visitors become eligible for the associated active roll call at check-in and are removed at check-out. A visitor can have only one active visit, and visitors can be included in roll call without having door access.\n\nSource: [Verkada Help — Visitor Access & Visit Access Type](https://help.verkada.com/access-control/users-and-credentials/add-a-user-to-the-verkada-access-system/visitor-access-visit-access-type).\n\n## Applicability\n\nApplies to Verkada Guest and Access visit data as described in the Visit Access Type guide. A software roster reflects configured visits and staff actions; this article does not certify physical presence.\n\n## DSE recommendation\n\nDSE recommends reconciling the visitor roster definition before using it in an exercise. Identify which visit types include roll call, which sites receive those visitors, and who records arrival and departure. Do not substitute an invitation’s validity window for a confirmed arrival. Include escorted visitors who do not need door credentials when designing the roster. Agree how reception will correct an incomplete check-in or checkout and communicate that correction to the exercise coordinator.\n\n## Verification\n\nUse controlled test visits representing not-yet-arrived, checked-in, and checked-out visitors, including one with no door access. Inspect the associated roll-call roster at each stage. Compare the software result with an observer’s record and document known omissions so a roster is not treated as proof that an unrecorded person is absent.\n\n## Official reference\n\n[Verkada Help — Visitor Access & Visit Access Type](https://help.verkada.com/access-control/users-and-credentials/add-a-user-to-the-verkada-access-system/visitor-access-visit-access-type). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/add-the-guest-contact-information-step-before-relying-on-qr-door-invitations/", "slug": "add-the-guest-contact-information-step-before-relying-on-qr-door-invitations", "url": "https://update.dsesecurity.com/updates/add-the-guest-contact-information-step-before-relying-on-qr-door-invitations/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/add-the-guest-contact-information-step-before-relying-on-qr-door-invitations.md", "json": "https://update.dsesecurity.com/api/v1/posts/add-the-guest-contact-information-step-before-relying-on-qr-door-invitations/" }, "title": "Add the Guest contact-information step before relying on QR door invitations", "summary": "Check the site-specific Guest Type and contact step before diagnosing a missing visitor QR code as reader failure.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:01+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 site-specific Verkada Guest door-access configuration. This article addresses invitation delivery prerequisites, not a claim that an email invitation itself authorizes every door or replaces local visitor approval.", "dse_recommendation": "DSE recommends tracing the complete credential-delivery path when a guest reports that a QR code never arrived.", "primary_source": { "name": "Verkada Help — Door Access for Guests", "url": "https://help.verkada.com/guest/configuration/door-access-for-guests", "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": "Check the site-specific Guest Type and contact step before diagnosing a missing visitor QR code as reader failure.
\nVerkada Guest links a Guest Type to a Visit Access Type to issue visitor door permissions. The guide requires a Contact Info step for delivering QR codes, entry codes, or unlock links. QR codes are viewed through the visitor’s post-sign-in link and require a supported intercom or reader path. The site can restrict door access to invited visitors. Global Guest Types cannot be assigned Visit Access Types, so they cannot provision this door access or include visitors in roll call through that integration.
\nSource: Verkada Help — Door Access for Guests.
\nApplies to site-specific Verkada Guest door-access configuration. This article addresses invitation delivery prerequisites, not a claim that an email invitation itself authorizes every door or replaces local visitor approval.
\nDSE recommends tracing the complete credential-delivery path when a guest reports that a QR code never arrived. Confirm the Guest Type is site-specific, the contact step is present, and the intended Visit Access Type is linked before replacing readers or resending unrelated messages. Have the host approve which visitors may receive door access and whether invitation-only restrictions are needed. Keep visitor-facing instructions consistent with the actual supported credential and entrance.
\nCreate an approved test visit using a controlled contact address, complete sign-in, and inspect the delivered credential link. Test the intended reader and an unauthorized door. Confirm that a visitor who does not satisfy the configured invitation restriction receives no unintended door access, and record the tested Guest Type.
\nVerkada Help — Door Access for Guests. Reviewed October 15, 2026.
", "content_text": "Check the site-specific Guest Type and contact step before diagnosing a missing visitor QR code as reader failure.\nSource facts\nVerkada Guest links a Guest Type to a Visit Access Type to issue visitor door permissions. The guide requires a Contact Info step for delivering QR codes, entry codes, or unlock links. QR codes are viewed through the visitor’s post-sign-in link and require a supported intercom or reader path. The site can restrict door access to invited visitors. Global Guest Types cannot be assigned Visit Access Types, so they cannot provision this door access or include visitors in roll call through that integration.\nSource: Verkada Help — Door Access for Guests.\nApplicability\nApplies to site-specific Verkada Guest door-access configuration. This article addresses invitation delivery prerequisites, not a claim that an email invitation itself authorizes every door or replaces local visitor approval.\nDSE recommendation\nDSE recommends tracing the complete credential-delivery path when a guest reports that a QR code never arrived. Confirm the Guest Type is site-specific, the contact step is present, and the intended Visit Access Type is linked before replacing readers or resending unrelated messages. Have the host approve which visitors may receive door access and whether invitation-only restrictions are needed. Keep visitor-facing instructions consistent with the actual supported credential and entrance.\nVerification\nCreate an approved test visit using a controlled contact address, complete sign-in, and inspect the delivered credential link. Test the intended reader and an unauthorized door. Confirm that a visitor who does not satisfy the configured invitation restriction receives no unintended door access, and record the tested Guest Type.\nOfficial reference\nVerkada Help — Door Access for Guests. Reviewed October 15, 2026.", "content_markdown": "Check the site-specific Guest Type and contact step before diagnosing a missing visitor QR code as reader failure.\n\n## Source facts\n\nVerkada Guest links a Guest Type to a Visit Access Type to issue visitor door permissions. The guide requires a Contact Info step for delivering QR codes, entry codes, or unlock links. QR codes are viewed through the visitor’s post-sign-in link and require a supported intercom or reader path. The site can restrict door access to invited visitors. Global Guest Types cannot be assigned Visit Access Types, so they cannot provision this door access or include visitors in roll call through that integration.\n\nSource: [Verkada Help — Door Access for Guests](https://help.verkada.com/guest/configuration/door-access-for-guests).\n\n## Applicability\n\nApplies to site-specific Verkada Guest door-access configuration. This article addresses invitation delivery prerequisites, not a claim that an email invitation itself authorizes every door or replaces local visitor approval.\n\n## DSE recommendation\n\nDSE recommends tracing the complete credential-delivery path when a guest reports that a QR code never arrived. Confirm the Guest Type is site-specific, the contact step is present, and the intended Visit Access Type is linked before replacing readers or resending unrelated messages. Have the host approve which visitors may receive door access and whether invitation-only restrictions are needed. Keep visitor-facing instructions consistent with the actual supported credential and entrance.\n\n## Verification\n\nCreate an approved test visit using a controlled contact address, complete sign-in, and inspect the delivered credential link. Test the intended reader and an unauthorized door. Confirm that a visitor who does not satisfy the configured invitation restriction receives no unintended door access, and record the tested Guest Type.\n\n## Official reference\n\n[Verkada Help — Door Access for Guests](https://help.verkada.com/guest/configuration/door-access-for-guests). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/revoke-a-visitor-credential-without-incorrectly-checking-the-visitor-out/", "slug": "revoke-a-visitor-credential-without-incorrectly-checking-the-visitor-out", "url": "https://update.dsesecurity.com/updates/revoke-a-visitor-credential-without-incorrectly-checking-the-visitor-out/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/revoke-a-visitor-credential-without-incorrectly-checking-the-visitor-out.md", "json": "https://update.dsesecurity.com/api/v1/posts/revoke-a-visitor-credential-without-incorrectly-checking-the-visitor-out/" }, "title": "Revoke a visitor credential without incorrectly checking the visitor out", "summary": "Make reception choose deliberately between ending independent door access and recording a visitor’s departure.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:00+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 visitor-door management from Verkada Guest. Staff should distinguish whether the person remains on site from whether the credential should still open doors; no actual visitor status is assumed here.", "dse_recommendation": "DSE recommends making the reception procedure offer two explicit outcomes: remove entry authority or close the visit.", "primary_source": { "name": "Verkada Help — Manage Visitor Door Access from Guest", "url": "https://help.verkada.com/guest/configuration/door-access-for-guests/manage-visitor-access-control-privileges", "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 reception choose deliberately between ending independent door access and recording a visitor’s departure.
\nVerkada Guest can revoke a visitor’s door access while leaving that visit signed in. The alternative Sign out action changes the visit status as well as ending access. The guide describes automatic access boundaries, including door/access schedules, maximum visit duration, event end, and the site’s automatic sign-out time. A keycard becomes available for another visitor after the documented sign-out or revocation conditions; one keycard can be active for only one visitor at a time.
\nSource: Verkada Help — Manage Visitor Door Access from Guest.
\nApplies to visitor-door management from Verkada Guest. Staff should distinguish whether the person remains on site from whether the credential should still open doors; no actual visitor status is assumed here.
\nDSE recommends making the reception procedure offer two explicit outcomes: remove entry authority or close the visit. If a visitor remains under escort but no longer needs independent access, select the outcome that reflects that situation instead of falsely recording departure. Recover physical cards according to site procedure and verify the current assignment before reuse. Document who requested a revocation and ensure reception and the host share the same understanding of the visitor’s status.
\nWith an approved test visit, revoke access and confirm the visit remains signed in while its credential no longer opens the test door. Then sign out and verify the expected status change and card availability. Reassign only a controlled test card and confirm it has a single active visitor owner.
\nVerkada Help — Manage Visitor Door Access from Guest. Reviewed October 15, 2026.
", "content_text": "Make reception choose deliberately between ending independent door access and recording a visitor’s departure.\nSource facts\nVerkada Guest can revoke a visitor’s door access while leaving that visit signed in. The alternative Sign out action changes the visit status as well as ending access. The guide describes automatic access boundaries, including door/access schedules, maximum visit duration, event end, and the site’s automatic sign-out time. A keycard becomes available for another visitor after the documented sign-out or revocation conditions; one keycard can be active for only one visitor at a time.\nSource: Verkada Help — Manage Visitor Door Access from Guest.\nApplicability\nApplies to visitor-door management from Verkada Guest. Staff should distinguish whether the person remains on site from whether the credential should still open doors; no actual visitor status is assumed here.\nDSE recommendation\nDSE recommends making the reception procedure offer two explicit outcomes: remove entry authority or close the visit. If a visitor remains under escort but no longer needs independent access, select the outcome that reflects that situation instead of falsely recording departure. Recover physical cards according to site procedure and verify the current assignment before reuse. Document who requested a revocation and ensure reception and the host share the same understanding of the visitor’s status.\nVerification\nWith an approved test visit, revoke access and confirm the visit remains signed in while its credential no longer opens the test door. Then sign out and verify the expected status change and card availability. Reassign only a controlled test card and confirm it has a single active visitor owner.\nOfficial reference\nVerkada Help — Manage Visitor Door Access from Guest. Reviewed October 15, 2026.", "content_markdown": "Make reception choose deliberately between ending independent door access and recording a visitor’s departure.\n\n## Source facts\n\nVerkada Guest can revoke a visitor’s door access while leaving that visit signed in. The alternative Sign out action changes the visit status as well as ending access. The guide describes automatic access boundaries, including door/access schedules, maximum visit duration, event end, and the site’s automatic sign-out time. A keycard becomes available for another visitor after the documented sign-out or revocation conditions; one keycard can be active for only one visitor at a time.\n\nSource: [Verkada Help — Manage Visitor Door Access from Guest](https://help.verkada.com/guest/configuration/door-access-for-guests/manage-visitor-access-control-privileges).\n\n## Applicability\n\nApplies to visitor-door management from Verkada Guest. Staff should distinguish whether the person remains on site from whether the credential should still open doors; no actual visitor status is assumed here.\n\n## DSE recommendation\n\nDSE recommends making the reception procedure offer two explicit outcomes: remove entry authority or close the visit. If a visitor remains under escort but no longer needs independent access, select the outcome that reflects that situation instead of falsely recording departure. Recover physical cards according to site procedure and verify the current assignment before reuse. Document who requested a revocation and ensure reception and the host share the same understanding of the visitor’s status.\n\n## Verification\n\nWith an approved test visit, revoke access and confirm the visit remains signed in while its credential no longer opens the test door. Then sign out and verify the expected status change and card availability. Reassign only a controlled test card and confirm it has a single active visitor owner.\n\n## Official reference\n\n[Verkada Help — Manage Visitor Door Access from Guest](https://help.verkada.com/guest/configuration/door-access-for-guests/manage-visitor-access-control-privileges). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/reserve-a-verkada-intercom-address-through-dhcp-and-verify-its-calling-endpoints/", "slug": "reserve-a-verkada-intercom-address-through-dhcp-and-verify-its-calling-endpoints", "url": "https://update.dsesecurity.com/updates/reserve-a-verkada-intercom-address-through-dhcp-and-verify-its-calling-endpoints/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/reserve-a-verkada-intercom-address-through-dhcp-and-verify-its-calling-endpoints.md", "json": "https://update.dsesecurity.com/api/v1/posts/reserve-a-verkada-intercom-address-through-dhcp-and-verify-its-calling-endpoints/" }, "title": "Reserve a Verkada intercom address through DHCP and verify its calling endpoints", "summary": "Use the vendor’s regional endpoint categories to distinguish an addressing problem from a calling-function failure.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:59+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 265, "potentially_affected": "Applies to Verkada intercom and Desk Station network requirements. Use the current endpoint table for the organization’s region; this article deliberately does not reproduce a static firewall allowlist that can become stale.", "dse_recommendation": "DSE recommends reserving the address through the managed DHCP service and recording the MAC-to-device mapping in inventory.", "primary_source": { "name": "Verkada Help — Intercom Network Settings", "url": "https://help.verkada.com/intercom/getting-started/intercom-network-settings", "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": "Use the vendor’s regional endpoint categories to distinguish an addressing problem from a calling-function failure.
\nVerkada intercoms use DHCP for addressing and network configuration. When a fixed address is needed, the vendor’s network guide directs administrators to create a DHCP reservation using the device MAC address. Intercoms use the DNS server supplied by DHCP, and the guide says DNS over HTTPS is not supported. Its firewall reference distinguishes general device communication, calling, access control, backup, and Desk Station endpoints, with region-specific requirements rather than one generic connectivity test.
\nSource: Verkada Help — Intercom Network Settings.
\nApplies to Verkada intercom and Desk Station network requirements. Use the current endpoint table for the organization’s region; this article deliberately does not reproduce a static firewall allowlist that can become stale.
\nDSE recommends reserving the address through the managed DHCP service and recording the MAC-to-device mapping in inventory. Diagnose a failure by function: online status, ringing, speech, unlocking, and backup can have different dependencies. Have the network owner review the applicable regional table and scope rules to the required devices. Do not substitute a successful ping for an end-to-end calling check or broadly expose the device subnet to resolve one missing endpoint.
\nVerify the lease, reservation, DNS response path, and required regional destinations from the intended network. Place an approved test call and check media and door control separately. Record which function failed and the applicable endpoint category so Support receives a useful failure description rather than only an online/offline label.
\nVerkada Help — Intercom Network Settings. Reviewed October 15, 2026.
", "content_text": "Use the vendor’s regional endpoint categories to distinguish an addressing problem from a calling-function failure.\nSource facts\nVerkada intercoms use DHCP for addressing and network configuration. When a fixed address is needed, the vendor’s network guide directs administrators to create a DHCP reservation using the device MAC address. Intercoms use the DNS server supplied by DHCP, and the guide says DNS over HTTPS is not supported. Its firewall reference distinguishes general device communication, calling, access control, backup, and Desk Station endpoints, with region-specific requirements rather than one generic connectivity test.\nSource: Verkada Help — Intercom Network Settings.\nApplicability\nApplies to Verkada intercom and Desk Station network requirements. Use the current endpoint table for the organization’s region; this article deliberately does not reproduce a static firewall allowlist that can become stale.\nDSE recommendation\nDSE recommends reserving the address through the managed DHCP service and recording the MAC-to-device mapping in inventory. Diagnose a failure by function: online status, ringing, speech, unlocking, and backup can have different dependencies. Have the network owner review the applicable regional table and scope rules to the required devices. Do not substitute a successful ping for an end-to-end calling check or broadly expose the device subnet to resolve one missing endpoint.\nVerification\nVerify the lease, reservation, DNS response path, and required regional destinations from the intended network. Place an approved test call and check media and door control separately. Record which function failed and the applicable endpoint category so Support receives a useful failure description rather than only an online/offline label.\nOfficial reference\nVerkada Help — Intercom Network Settings. Reviewed October 15, 2026.", "content_markdown": "Use the vendor’s regional endpoint categories to distinguish an addressing problem from a calling-function failure.\n\n## Source facts\n\nVerkada intercoms use DHCP for addressing and network configuration. When a fixed address is needed, the vendor’s network guide directs administrators to create a DHCP reservation using the device MAC address. Intercoms use the DNS server supplied by DHCP, and the guide says DNS over HTTPS is not supported. Its firewall reference distinguishes general device communication, calling, access control, backup, and Desk Station endpoints, with region-specific requirements rather than one generic connectivity test.\n\nSource: [Verkada Help — Intercom Network Settings](https://help.verkada.com/intercom/getting-started/intercom-network-settings).\n\n## Applicability\n\nApplies to Verkada intercom and Desk Station network requirements. Use the current endpoint table for the organization’s region; this article deliberately does not reproduce a static firewall allowlist that can become stale.\n\n## DSE recommendation\n\nDSE recommends reserving the address through the managed DHCP service and recording the MAC-to-device mapping in inventory. Diagnose a failure by function: online status, ringing, speech, unlocking, and backup can have different dependencies. Have the network owner review the applicable regional table and scope rules to the required devices. Do not substitute a successful ping for an end-to-end calling check or broadly expose the device subnet to resolve one missing endpoint.\n\n## Verification\n\nVerify the lease, reservation, DNS response path, and required regional destinations from the intended network. Place an approved test call and check media and door control separately. Record which function failed and the applicable endpoint category so Support receives a useful failure description rather than only an online/offline label.\n\n## Official reference\n\n[Verkada Help — Intercom Network Settings](https://help.verkada.com/intercom/getting-started/intercom-network-settings). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/review-intercom-receiver-authority-even-when-no-command-user-is-assigned/", "slug": "review-intercom-receiver-authority-even-when-no-command-user-is-assigned", "url": "https://update.dsesecurity.com/updates/review-intercom-receiver-authority-even-when-no-command-user-is-assigned/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/review-intercom-receiver-authority-even-when-no-command-user-is-assigned.md", "json": "https://update.dsesecurity.com/api/v1/posts/review-intercom-receiver-authority-even-when-no-command-user-is-assigned/" }, "title": "Review intercom receiver authority even when no Command user is assigned", "summary": "Include tablets and telephone receivers in the access review even when they have no named Command account.", "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": "access-control", "name": "Access Control", "url": "https://update.dsesecurity.com/topic/access-control/" } ], "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:58+00:00", "modified_at": "2026-10-15T13:36:14+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 276, "potentially_affected": "Applies to the receiver permissions documented for Verkada Intercom. Confirm the current role matrix and device configuration; this does not assign permissions or state that every receiver is a named employee.", "dse_recommendation": "DSE recommends inventorying receivers alongside user accounts during an entrance-access review.", "primary_source": { "name": "Verkada Help — Roles and Permissions for Intercom", "url": "https://help.verkada.com/intercom/getting-started/roles-and-permissions-for-intercom", "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": "Include tablets and telephone receivers in the access review even when they have no named Command account.
\nVerkada intercom authority depends both on site roles and on receiver configuration. The guide says a user must be configured as a receiver to receive calls. Desk Stations and SIP phones are receivers that are not tied to a Command user and cannot be assigned site roles. Receiver authority includes viewing live intercom video outside calls, unlocking during and outside calls, and talk-down. Reviewing only the organization’s list of named user roles therefore misses a separately configured path to intercom functions.
\nSource: Verkada Help — Roles and Permissions for Intercom.
\nApplies to the receiver permissions documented for Verkada Intercom. Confirm the current role matrix and device configuration; this does not assign permissions or state that every receiver is a named employee.
\nDSE recommends inventorying receivers alongside user accounts during an entrance-access review. Map each tablet, extension, and personal receiver to an accountable owner and approved physical or telephone location. Check whether continuous viewing and out-of-call unlocking are appropriate for that endpoint. Remove stale receiver destinations when a desk, phone extension, or employee role changes, and validate the intended fallback call flow afterward. Treat receiver configuration as an access decision requiring an owner.
\nCompare the receiver list with the approved endpoint inventory and test one authorized receiver’s available functions outside a call. Verify that a removed disposable receiver no longer receives test calls. Record any authority that cannot be expressed through a site-role assignment so future reviews do not silently omit it.
\nVerkada Help — Roles and Permissions for Intercom. Reviewed October 15, 2026.
", "content_text": "Include tablets and telephone receivers in the access review even when they have no named Command account.\nSource facts\nVerkada intercom authority depends both on site roles and on receiver configuration. The guide says a user must be configured as a receiver to receive calls. Desk Stations and SIP phones are receivers that are not tied to a Command user and cannot be assigned site roles. Receiver authority includes viewing live intercom video outside calls, unlocking during and outside calls, and talk-down. Reviewing only the organization’s list of named user roles therefore misses a separately configured path to intercom functions.\nSource: Verkada Help — Roles and Permissions for Intercom.\nApplicability\nApplies to the receiver permissions documented for Verkada Intercom. Confirm the current role matrix and device configuration; this does not assign permissions or state that every receiver is a named employee.\nDSE recommendation\nDSE recommends inventorying receivers alongside user accounts during an entrance-access review. Map each tablet, extension, and personal receiver to an accountable owner and approved physical or telephone location. Check whether continuous viewing and out-of-call unlocking are appropriate for that endpoint. Remove stale receiver destinations when a desk, phone extension, or employee role changes, and validate the intended fallback call flow afterward. Treat receiver configuration as an access decision requiring an owner.\nVerification\nCompare the receiver list with the approved endpoint inventory and test one authorized receiver’s available functions outside a call. Verify that a removed disposable receiver no longer receives test calls. Record any authority that cannot be expressed through a site-role assignment so future reviews do not silently omit it.\nOfficial reference\nVerkada Help — Roles and Permissions for Intercom. Reviewed October 15, 2026.", "content_markdown": "Include tablets and telephone receivers in the access review even when they have no named Command account.\n\n## Source facts\n\nVerkada intercom authority depends both on site roles and on receiver configuration. The guide says a user must be configured as a receiver to receive calls. Desk Stations and SIP phones are receivers that are not tied to a Command user and cannot be assigned site roles. Receiver authority includes viewing live intercom video outside calls, unlocking during and outside calls, and talk-down. Reviewing only the organization’s list of named user roles therefore misses a separately configured path to intercom functions.\n\nSource: [Verkada Help — Roles and Permissions for Intercom](https://help.verkada.com/intercom/getting-started/roles-and-permissions-for-intercom).\n\n## Applicability\n\nApplies to the receiver permissions documented for Verkada Intercom. Confirm the current role matrix and device configuration; this does not assign permissions or state that every receiver is a named employee.\n\n## DSE recommendation\n\nDSE recommends inventorying receivers alongside user accounts during an entrance-access review. Map each tablet, extension, and personal receiver to an accountable owner and approved physical or telephone location. Check whether continuous viewing and out-of-call unlocking are appropriate for that endpoint. Remove stale receiver destinations when a desk, phone extension, or employee role changes, and validate the intended fallback call flow afterward. Treat receiver configuration as an access decision requiring an owner.\n\n## Verification\n\nCompare the receiver list with the approved endpoint inventory and test one authorized receiver’s available functions outside a call. Verify that a removed disposable receiver no longer receives test calls. Record any authority that cannot be expressed through a site-role assignment so future reviews do not silently omit it.\n\n## Official reference\n\n[Verkada Help — Roles and Permissions for Intercom](https://help.verkada.com/intercom/getting-started/roles-and-permissions-for-intercom). Reviewed October 15, 2026." } ] }