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/unifi-ppsk-wpa2-six-ghz-vlan-design/", "slug": "unifi-ppsk-wpa2-six-ghz-vlan-design", "url": "https://update.dsesecurity.com/updates/unifi-ppsk-wpa2-six-ghz-vlan-design/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/unifi-ppsk-wpa2-six-ghz-vlan-design.md", "json": "https://update.dsesecurity.com/api/v1/posts/unifi-ppsk-wpa2-six-ghz-vlan-design/" }, "title": "Check the 6 GHz requirement before choosing UniFi PPSK for one-SSID VLAN assignment", "summary": "UniFi PPSK maps passwords to VLANs, but its WPA2 requirement excludes 6 GHz operation.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:34:01+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 271, "potentially_affected": "This applies to UniFi Network PPSK and the documented RADIUS alternative. Confirm the access-point, client, software, and radio requirements before choosing an authentication design for a production SSID.", "dse_recommendation": "DSE recommends deciding the required client population and radio bands before using PPSK to simplify SSID management.", "primary_source": { "name": "Ubiquiti — PPSK and RADIUS VLANs", "url": "https://help.ui.com/hc/en-us/articles/29887064407319-Using-PPSK-RADIUS-for-Multiple-VLANs-On-an-SSID-in-UniFi-Network", "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": "UniFi PPSK maps passwords to VLANs, but its WPA2 requirement excludes 6 GHz operation.
\nUbiquiti documents UniFi Network PPSK as using different shared passwords on one SSID to determine a client’s VLAN. Individual usernames are not required for that method. The documented PPSK option is WPA2-only and therefore does not work on 6 GHz bands. RADIUS-assigned VLANs are a separate approach using user profiles and enterprise-capable authentication. For a client moving between PPSK VLANs, Ubiquiti describes forgetting the saved network and reconnecting with the appropriate new password. The VLANs must already be configured.
\nSource: Ubiquiti — PPSK and RADIUS VLANs.
\nThis applies to UniFi Network PPSK and the documented RADIUS alternative. Confirm the access-point, client, software, and radio requirements before choosing an authentication design for a production SSID.
\nDSE recommends deciding the required client population and radio bands before using PPSK to simplify SSID management. Document which password maps to which VLAN and who may distribute it. If 6 GHz is a requirement, review a supported alternative rather than assuming the PPSK network will use every radio. Keep the downstream VLAN access policy in the network design; choosing a VLAN by password is only one part of that policy. Provide support instructions for removing a saved password when a device legitimately changes VLAN.
\nUse test clients representative of the intended device classes. Verify their actual radio band, assigned VLAN, address, and permitted destinations for each test key. Exercise the documented saved-network change when moving between keys, and confirm that the design meets its band requirement before broad rollout.
\nUbiquiti — PPSK and RADIUS VLANs. Reviewed October 15, 2026.
", "content_text": "UniFi PPSK maps passwords to VLANs, but its WPA2 requirement excludes 6 GHz operation.\nSource facts\nUbiquiti documents UniFi Network PPSK as using different shared passwords on one SSID to determine a client’s VLAN. Individual usernames are not required for that method. The documented PPSK option is WPA2-only and therefore does not work on 6 GHz bands. RADIUS-assigned VLANs are a separate approach using user profiles and enterprise-capable authentication. For a client moving between PPSK VLANs, Ubiquiti describes forgetting the saved network and reconnecting with the appropriate new password. The VLANs must already be configured.\nSource: Ubiquiti — PPSK and RADIUS VLANs.\nApplicability\nThis applies to UniFi Network PPSK and the documented RADIUS alternative. Confirm the access-point, client, software, and radio requirements before choosing an authentication design for a production SSID.\nDSE recommendation\nDSE recommends deciding the required client population and radio bands before using PPSK to simplify SSID management. Document which password maps to which VLAN and who may distribute it. If 6 GHz is a requirement, review a supported alternative rather than assuming the PPSK network will use every radio. Keep the downstream VLAN access policy in the network design; choosing a VLAN by password is only one part of that policy. Provide support instructions for removing a saved password when a device legitimately changes VLAN.\nVerification\nUse test clients representative of the intended device classes. Verify their actual radio band, assigned VLAN, address, and permitted destinations for each test key. Exercise the documented saved-network change when moving between keys, and confirm that the design meets its band requirement before broad rollout.\nOfficial reference\nUbiquiti — PPSK and RADIUS VLANs. Reviewed October 15, 2026.", "content_markdown": "UniFi PPSK maps passwords to VLANs, but its WPA2 requirement excludes 6 GHz operation.\n\n## Source facts\n\nUbiquiti documents UniFi Network PPSK as using different shared passwords on one SSID to determine a client’s VLAN. Individual usernames are not required for that method. The documented PPSK option is WPA2-only and therefore does not work on 6 GHz bands. RADIUS-assigned VLANs are a separate approach using user profiles and enterprise-capable authentication. For a client moving between PPSK VLANs, Ubiquiti describes forgetting the saved network and reconnecting with the appropriate new password. The VLANs must already be configured.\n\nSource: [Ubiquiti — PPSK and RADIUS VLANs](https://help.ui.com/hc/en-us/articles/29887064407319-Using-PPSK-RADIUS-for-Multiple-VLANs-On-an-SSID-in-UniFi-Network).\n\n## Applicability\n\nThis applies to UniFi Network PPSK and the documented RADIUS alternative. Confirm the access-point, client, software, and radio requirements before choosing an authentication design for a production SSID.\n\n## DSE recommendation\n\nDSE recommends deciding the required client population and radio bands before using PPSK to simplify SSID management. Document which password maps to which VLAN and who may distribute it. If 6 GHz is a requirement, review a supported alternative rather than assuming the PPSK network will use every radio. Keep the downstream VLAN access policy in the network design; choosing a VLAN by password is only one part of that policy. Provide support instructions for removing a saved password when a device legitimately changes VLAN.\n\n## Verification\n\nUse test clients representative of the intended device classes. Verify their actual radio band, assigned VLAN, address, and permitted destinations for each test key. Exercise the documented saved-network change when moving between keys, and confirm that the design meets its band requirement before broad rollout.\n\n## Official reference\n\n[Ubiquiti — PPSK and RADIUS VLANs](https://help.ui.com/hc/en-us/articles/29887064407319-Using-PPSK-RADIUS-for-Multiple-VLANs-On-an-SSID-in-UniFi-Network). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-quarantine-reviewer-notification-retention/", "slug": "google-workspace-quarantine-reviewer-notification-retention", "url": "https://update.dsesecurity.com/updates/google-workspace-quarantine-reviewer-notification-retention/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-quarantine-reviewer-notification-retention.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-quarantine-reviewer-notification-retention/" }, "title": "Assign a real review process for Google email quarantine instead of relying on notifications", "summary": "Quarantine reviewers and notification recipients are not necessarily the same people.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:34:00+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 274, "potentially_affected": "This concerns Google Workspace email quarantine and its built-in notifications. Separate retention services such as Vault have their own configuration and should not be assumed to provide the same reviewer workflow.", "dse_recommendation": "DSE recommends naming the daily reviewers, backup reviewers, and escalation owner explicitly.", "primary_source": { "name": "Google — Email quarantine", "url": "https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-email-quarantine?hl=en", "published_on": null, "authority": "knowledge.workspace.google.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": "Quarantine reviewers and notification recipients are not necessarily the same people.
\nGoogle Workspace quarantine holds matched messages for review before delivery. Administrators can create restricted quarantines and assign reviewer groups, but the documented periodic notification feature sends its notices only to super administrators, not to reviewer groups or users with quarantine privileges. Recipients are not notified that a message is quarantined. Unacted-on messages are permanently deleted from quarantine after 30 days. If a custom quarantine is deleted while holding messages, its messages move to the default quarantine; references from rules must be addressed before deleting the quarantine.
\nSource: Google — Email quarantine.
\nThis concerns Google Workspace email quarantine and its built-in notifications. Separate retention services such as Vault have their own configuration and should not be assumed to provide the same reviewer workflow.
\nDSE recommends naming the daily reviewers, backup reviewers, and escalation owner explicitly. Establish a review cadence and approved evidence handling so missed notification emails do not allow messages to age out unnoticed. Explain to staff how to report a missing message without assuming the recipient will receive a quarantine notice. Before changing or retiring a quarantine, review its referencing rules and outstanding messages. Keep release and rejection decisions attributable, and ensure the review process respects the sensitivity of the held message content.
\nUse a harmless test rule and message to confirm the intended quarantine and reviewer access. Check which identities receive periodic notices and whether the recipient receives none. Review the pending-message age and rule references before retiring the test quarantine, then remove the test settings through the approved process.
\nGoogle — Email quarantine. Reviewed October 15, 2026.
", "content_text": "Quarantine reviewers and notification recipients are not necessarily the same people.\nSource facts\nGoogle Workspace quarantine holds matched messages for review before delivery. Administrators can create restricted quarantines and assign reviewer groups, but the documented periodic notification feature sends its notices only to super administrators, not to reviewer groups or users with quarantine privileges. Recipients are not notified that a message is quarantined. Unacted-on messages are permanently deleted from quarantine after 30 days. If a custom quarantine is deleted while holding messages, its messages move to the default quarantine; references from rules must be addressed before deleting the quarantine.\nSource: Google — Email quarantine.\nApplicability\nThis concerns Google Workspace email quarantine and its built-in notifications. Separate retention services such as Vault have their own configuration and should not be assumed to provide the same reviewer workflow.\nDSE recommendation\nDSE recommends naming the daily reviewers, backup reviewers, and escalation owner explicitly. Establish a review cadence and approved evidence handling so missed notification emails do not allow messages to age out unnoticed. Explain to staff how to report a missing message without assuming the recipient will receive a quarantine notice. Before changing or retiring a quarantine, review its referencing rules and outstanding messages. Keep release and rejection decisions attributable, and ensure the review process respects the sensitivity of the held message content.\nVerification\nUse a harmless test rule and message to confirm the intended quarantine and reviewer access. Check which identities receive periodic notices and whether the recipient receives none. Review the pending-message age and rule references before retiring the test quarantine, then remove the test settings through the approved process.\nOfficial reference\nGoogle — Email quarantine. Reviewed October 15, 2026.", "content_markdown": "Quarantine reviewers and notification recipients are not necessarily the same people.\n\n## Source facts\n\nGoogle Workspace quarantine holds matched messages for review before delivery. Administrators can create restricted quarantines and assign reviewer groups, but the documented periodic notification feature sends its notices only to super administrators, not to reviewer groups or users with quarantine privileges. Recipients are not notified that a message is quarantined. Unacted-on messages are permanently deleted from quarantine after 30 days. If a custom quarantine is deleted while holding messages, its messages move to the default quarantine; references from rules must be addressed before deleting the quarantine.\n\nSource: [Google — Email quarantine](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-email-quarantine?hl=en).\n\n## Applicability\n\nThis concerns Google Workspace email quarantine and its built-in notifications. Separate retention services such as Vault have their own configuration and should not be assumed to provide the same reviewer workflow.\n\n## DSE recommendation\n\nDSE recommends naming the daily reviewers, backup reviewers, and escalation owner explicitly. Establish a review cadence and approved evidence handling so missed notification emails do not allow messages to age out unnoticed. Explain to staff how to report a missing message without assuming the recipient will receive a quarantine notice. Before changing or retiring a quarantine, review its referencing rules and outstanding messages. Keep release and rejection decisions attributable, and ensure the review process respects the sensitivity of the held message content.\n\n## Verification\n\nUse a harmless test rule and message to confirm the intended quarantine and reviewer access. Check which identities receive periodic notices and whether the recipient receives none. Review the pending-message age and rule references before retiring the test quarantine, then remove the test settings through the approved process.\n\n## Official reference\n\n[Google — Email quarantine](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-email-quarantine?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-role-scope-two-approval-requests/", "slug": "google-workspace-role-scope-two-approval-requests", "url": "https://update.dsesecurity.com/updates/google-workspace-role-scope-two-approval-requests/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-role-scope-two-approval-requests.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-role-scope-two-approval-requests/" }, "title": "Expect two approvals when changing Google Workspace admin-role scope under multi-party review", "summary": "A move between organizational-unit scopes can remain pending until both generated requests are approved.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:58+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 268, "potentially_affected": "This concerns Google Workspace role-management multi-party approval where the feature is available and configured. It does not imply that every administrative operation or every API request is automatically covered.", "dse_recommendation": "DSE recommends documenting the role, old scope, new scope, and intended approver before submitting a scope change.", "primary_source": { "name": "Google — Assign admin roles", "url": "https://knowledge.workspace.google.com/admin/users/assign-specific-admin-roles?hl=en", "published_on": null, "authority": "knowledge.workspace.google.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": "A move between organizational-unit scopes can remain pending until both generated requests are approved.
\nGoogle Workspace can require multi-party review for administrator-role assignments. A requesting administrator initiates the change and a super administrator reviews it. The documented role-management controls can cover Admin console changes and API changes through separate settings. Changing an existing role assignment from one organizational-unit scope to another creates two approval requests, and both must be approved for the scope change to take effect. Not every role supports organizational-unit scoping; the assignment interface indicates whether that scope can be edited.
\nSource: Google — Assign admin roles.
\nThis concerns Google Workspace role-management multi-party approval where the feature is available and configured. It does not imply that every administrative operation or every API request is automatically covered.
\nDSE recommends documenting the role, old scope, new scope, and intended approver before submitting a scope change. Tell reviewers to expect the related pair of requests and assess them as one access change. Review the console and API approval settings separately so automation follows the intended governance. Maintain a pending-request checklist for the helpdesk, and avoid repeated resubmission while an existing request is awaiting its second decision. Recheck the final assignment rather than assuming one approval completed the move.
\nWith a low-impact test role and two test organizational units, observe the requests generated by an approved scope change. Confirm the effective scope before and after both decisions. Check the documented console and API settings and verify that an unsupported role is not mistakenly described as organizational-unit restricted.
\nGoogle — Assign admin roles. Reviewed October 15, 2026.
", "content_text": "A move between organizational-unit scopes can remain pending until both generated requests are approved.\nSource facts\nGoogle Workspace can require multi-party review for administrator-role assignments. A requesting administrator initiates the change and a super administrator reviews it. The documented role-management controls can cover Admin console changes and API changes through separate settings. Changing an existing role assignment from one organizational-unit scope to another creates two approval requests, and both must be approved for the scope change to take effect. Not every role supports organizational-unit scoping; the assignment interface indicates whether that scope can be edited.\nSource: Google — Assign admin roles.\nApplicability\nThis concerns Google Workspace role-management multi-party approval where the feature is available and configured. It does not imply that every administrative operation or every API request is automatically covered.\nDSE recommendation\nDSE recommends documenting the role, old scope, new scope, and intended approver before submitting a scope change. Tell reviewers to expect the related pair of requests and assess them as one access change. Review the console and API approval settings separately so automation follows the intended governance. Maintain a pending-request checklist for the helpdesk, and avoid repeated resubmission while an existing request is awaiting its second decision. Recheck the final assignment rather than assuming one approval completed the move.\nVerification\nWith a low-impact test role and two test organizational units, observe the requests generated by an approved scope change. Confirm the effective scope before and after both decisions. Check the documented console and API settings and verify that an unsupported role is not mistakenly described as organizational-unit restricted.\nOfficial reference\nGoogle — Assign admin roles. Reviewed October 15, 2026.", "content_markdown": "A move between organizational-unit scopes can remain pending until both generated requests are approved.\n\n## Source facts\n\nGoogle Workspace can require multi-party review for administrator-role assignments. A requesting administrator initiates the change and a super administrator reviews it. The documented role-management controls can cover Admin console changes and API changes through separate settings. Changing an existing role assignment from one organizational-unit scope to another creates two approval requests, and both must be approved for the scope change to take effect. Not every role supports organizational-unit scoping; the assignment interface indicates whether that scope can be edited.\n\nSource: [Google — Assign admin roles](https://knowledge.workspace.google.com/admin/users/assign-specific-admin-roles?hl=en).\n\n## Applicability\n\nThis concerns Google Workspace role-management multi-party approval where the feature is available and configured. It does not imply that every administrative operation or every API request is automatically covered.\n\n## DSE recommendation\n\nDSE recommends documenting the role, old scope, new scope, and intended approver before submitting a scope change. Tell reviewers to expect the related pair of requests and assess them as one access change. Review the console and API approval settings separately so automation follows the intended governance. Maintain a pending-request checklist for the helpdesk, and avoid repeated resubmission while an existing request is awaiting its second decision. Recheck the final assignment rather than assuming one approval completed the move.\n\n## Verification\n\nWith a low-impact test role and two test organizational units, observe the requests generated by an approved scope change. Confirm the effective scope before and after both decisions. Check the documented console and API settings and verify that an unsupported role is not mistakenly described as organizational-unit restricted.\n\n## Official reference\n\n[Google — Assign admin roles](https://knowledge.workspace.google.com/admin/users/assign-specific-admin-roles?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-admin-recovery-dns-account-evidence/", "slug": "google-workspace-admin-recovery-dns-account-evidence", "url": "https://update.dsesecurity.com/updates/google-workspace-admin-recovery-dns-account-evidence/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-admin-recovery-dns-account-evidence.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-admin-recovery-dns-account-evidence/" }, "title": "Prepare Google administrator recovery dependencies outside the Admin console", "summary": "Recovery may require domain-DNS control and business account evidence when another super administrator is unavailable.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" } ], "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:33:57+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 275, "potentially_affected": "This applies to Google Workspace super-administrator recovery planning. The available recovery path depends on the account’s settings and situation; keeping evidence does not guarantee that Google will approve a recovery request.", "dse_recommendation": "DSE recommends keeping a protected recovery record that authorized custodians can reach without the locked account.", "primary_source": { "name": "Google — Administrator security", "url": "https://knowledge.workspace.google.com/admin/users/security-best-practices-for-administrator-accounts?hl=en", "published_on": null, "authority": "knowledge.workspace.google.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": "Recovery may require domain-DNS control and business account evidence when another super administrator is unavailable.
\nGoogle recommends maintaining more than one super administrator, each operated by a different person. If self-recovery is unavailable and another super administrator cannot reset access, the documented recovery wizard asks for evidence about the organization’s account. Examples include creation details, the original secondary email address, order or billing information, and user count. Google may also require verification of domain ownership through DNS. The guide recommends spare enrolled security keys and securely stored backup codes as additional recovery preparations.
\nSource: Google — Administrator security.
\nThis applies to Google Workspace super-administrator recovery planning. The available recovery path depends on the account’s settings and situation; keeping evidence does not guarantee that Google will approve a recovery request.
\nDSE recommends keeping a protected recovery record that authorized custodians can reach without the locked account. Identify who controls the domain registrar and DNS platform, and verify that their recovery path is not solely dependent on Workspace email. Record the location of required business evidence rather than copying sensitive billing data into routine helpdesk tickets. Give each administrator a separate identity and test access to approved spare factors. Review custody after staff changes, domain transfers, or a change in billing responsibility.
\nConduct a tabletop exercise in which the primary administrator is unavailable. Confirm that another authorized administrator can sign in, that custodians can locate the recovery record, and that domain-DNS access remains independently recoverable. Do not initiate a real account-recovery request or expose backup codes simply to prove that the procedure exists.
\nGoogle — Administrator security. Reviewed October 15, 2026.
", "content_text": "Recovery may require domain-DNS control and business account evidence when another super administrator is unavailable.\nSource facts\nGoogle recommends maintaining more than one super administrator, each operated by a different person. If self-recovery is unavailable and another super administrator cannot reset access, the documented recovery wizard asks for evidence about the organization’s account. Examples include creation details, the original secondary email address, order or billing information, and user count. Google may also require verification of domain ownership through DNS. The guide recommends spare enrolled security keys and securely stored backup codes as additional recovery preparations.\nSource: Google — Administrator security.\nApplicability\nThis applies to Google Workspace super-administrator recovery planning. The available recovery path depends on the account’s settings and situation; keeping evidence does not guarantee that Google will approve a recovery request.\nDSE recommendation\nDSE recommends keeping a protected recovery record that authorized custodians can reach without the locked account. Identify who controls the domain registrar and DNS platform, and verify that their recovery path is not solely dependent on Workspace email. Record the location of required business evidence rather than copying sensitive billing data into routine helpdesk tickets. Give each administrator a separate identity and test access to approved spare factors. Review custody after staff changes, domain transfers, or a change in billing responsibility.\nVerification\nConduct a tabletop exercise in which the primary administrator is unavailable. Confirm that another authorized administrator can sign in, that custodians can locate the recovery record, and that domain-DNS access remains independently recoverable. Do not initiate a real account-recovery request or expose backup codes simply to prove that the procedure exists.\nOfficial reference\nGoogle — Administrator security. Reviewed October 15, 2026.", "content_markdown": "Recovery may require domain-DNS control and business account evidence when another super administrator is unavailable.\n\n## Source facts\n\nGoogle recommends maintaining more than one super administrator, each operated by a different person. If self-recovery is unavailable and another super administrator cannot reset access, the documented recovery wizard asks for evidence about the organization’s account. Examples include creation details, the original secondary email address, order or billing information, and user count. Google may also require verification of domain ownership through DNS. The guide recommends spare enrolled security keys and securely stored backup codes as additional recovery preparations.\n\nSource: [Google — Administrator security](https://knowledge.workspace.google.com/admin/users/security-best-practices-for-administrator-accounts?hl=en).\n\n## Applicability\n\nThis applies to Google Workspace super-administrator recovery planning. The available recovery path depends on the account’s settings and situation; keeping evidence does not guarantee that Google will approve a recovery request.\n\n## DSE recommendation\n\nDSE recommends keeping a protected recovery record that authorized custodians can reach without the locked account. Identify who controls the domain registrar and DNS platform, and verify that their recovery path is not solely dependent on Workspace email. Record the location of required business evidence rather than copying sensitive billing data into routine helpdesk tickets. Give each administrator a separate identity and test access to approved spare factors. Review custody after staff changes, domain transfers, or a change in billing responsibility.\n\n## Verification\n\nConduct a tabletop exercise in which the primary administrator is unavailable. Confirm that another authorized administrator can sign in, that custodians can locate the recovery record, and that domain-DNS access remains independently recoverable. Do not initiate a real account-recovery request or expose backup codes simply to prove that the procedure exists.\n\n## Official reference\n\n[Google — Administrator security](https://knowledge.workspace.google.com/admin/users/security-best-practices-for-administrator-accounts?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-2sv-enforcement-date-grace-window/", "slug": "google-workspace-2sv-enforcement-date-grace-window", "url": "https://update.dsesecurity.com/updates/google-workspace-2sv-enforcement-date-grace-window/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-2sv-enforcement-date-grace-window.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-2sv-enforcement-date-grace-window/" }, "title": "Plan Google Workspace 2SV enforcement around enrollment grace and scheduling behavior", "summary": "The scheduled enforcement date is not a precise activation time, and new-user grace still allows password-only access.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:56+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 266, "potentially_affected": "This concerns Google Workspace administrator-managed 2SV deployment. Google’s own administrator-account enforcement and the tenant’s available authentication methods require separate review before changing production policy.", "dse_recommendation": "DSE recommends recording the intended enforcement population, accepted methods, and grace-period decision before communicating a deadline.", "primary_source": { "name": "Google — Deploy 2-Step Verification", "url": "https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification?hl=en", "published_on": null, "authority": "knowledge.workspace.google.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": "The scheduled enforcement date is not a precise activation time, and new-user grace still allows password-only access.
\nGoogle’s 2-Step Verification deployment guide separates allowing enrollment from enforcing it. Administrators can enforce immediately or select a future date; the scheduled-date option can begin within 24–48 hours rather than at an exact chosen time. A configured new-user enrollment period permits password-only sign-in during that period. Google recommends checking enrollment before enforcement, and changing allowed methods can lock out users who have not prepared another eligible method. Enrollment reports and individual security settings provide different ways to review readiness.
\nSource: Google — Deploy 2-Step Verification.
\nThis concerns Google Workspace administrator-managed 2SV deployment. Google’s own administrator-account enforcement and the tenant’s available authentication methods require separate review before changing production policy.
\nDSE recommends recording the intended enforcement population, accepted methods, and grace-period decision before communicating a deadline. Use a pilot group to check onboarding and recovery procedures. If the business needs a precise cutover, account for the documented difference between immediate enforcement and the date-based option. Resolve users relying on a soon-disallowed method before changing it. Treat new-user grace as a deliberate access exception with an owner, and provide helpdesk guidance for distinguishing incomplete enrollment from an actual authentication failure.
\nUse test users with complete enrollment, incomplete enrollment, and the intended new-user grace status. Verify behavior for each allowed method before expanding enforcement. Review both report data and current individual settings where needed, and document activation timing instead of inferring it from the selected calendar date.
\nGoogle — Deploy 2-Step Verification. Reviewed October 15, 2026.
", "content_text": "The scheduled enforcement date is not a precise activation time, and new-user grace still allows password-only access.\nSource facts\nGoogle’s 2-Step Verification deployment guide separates allowing enrollment from enforcing it. Administrators can enforce immediately or select a future date; the scheduled-date option can begin within 24–48 hours rather than at an exact chosen time. A configured new-user enrollment period permits password-only sign-in during that period. Google recommends checking enrollment before enforcement, and changing allowed methods can lock out users who have not prepared another eligible method. Enrollment reports and individual security settings provide different ways to review readiness.\nSource: Google — Deploy 2-Step Verification.\nApplicability\nThis concerns Google Workspace administrator-managed 2SV deployment. Google’s own administrator-account enforcement and the tenant’s available authentication methods require separate review before changing production policy.\nDSE recommendation\nDSE recommends recording the intended enforcement population, accepted methods, and grace-period decision before communicating a deadline. Use a pilot group to check onboarding and recovery procedures. If the business needs a precise cutover, account for the documented difference between immediate enforcement and the date-based option. Resolve users relying on a soon-disallowed method before changing it. Treat new-user grace as a deliberate access exception with an owner, and provide helpdesk guidance for distinguishing incomplete enrollment from an actual authentication failure.\nVerification\nUse test users with complete enrollment, incomplete enrollment, and the intended new-user grace status. Verify behavior for each allowed method before expanding enforcement. Review both report data and current individual settings where needed, and document activation timing instead of inferring it from the selected calendar date.\nOfficial reference\nGoogle — Deploy 2-Step Verification. Reviewed October 15, 2026.", "content_markdown": "The scheduled enforcement date is not a precise activation time, and new-user grace still allows password-only access.\n\n## Source facts\n\nGoogle’s 2-Step Verification deployment guide separates allowing enrollment from enforcing it. Administrators can enforce immediately or select a future date; the scheduled-date option can begin within 24–48 hours rather than at an exact chosen time. A configured new-user enrollment period permits password-only sign-in during that period. Google recommends checking enrollment before enforcement, and changing allowed methods can lock out users who have not prepared another eligible method. Enrollment reports and individual security settings provide different ways to review readiness.\n\nSource: [Google — Deploy 2-Step Verification](https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification?hl=en).\n\n## Applicability\n\nThis concerns Google Workspace administrator-managed 2SV deployment. Google’s own administrator-account enforcement and the tenant’s available authentication methods require separate review before changing production policy.\n\n## DSE recommendation\n\nDSE recommends recording the intended enforcement population, accepted methods, and grace-period decision before communicating a deadline. Use a pilot group to check onboarding and recovery procedures. If the business needs a precise cutover, account for the documented difference between immediate enforcement and the date-based option. Resolve users relying on a soon-disallowed method before changing it. Treat new-user grace as a deliberate access exception with an owner, and provide helpdesk guidance for distinguishing incomplete enrollment from an actual authentication failure.\n\n## Verification\n\nUse test users with complete enrollment, incomplete enrollment, and the intended new-user grace status. Verify behavior for each allowed method before expanding enforcement. Review both report data and current individual settings where needed, and document activation timing instead of inferring it from the selected calendar date.\n\n## Official reference\n\n[Google — Deploy 2-Step Verification](https://knowledge.workspace.google.com/admin/security/deploy-2-step-verification?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-web-session-exclusions-idp-renewal/", "slug": "google-workspace-web-session-exclusions-idp-renewal", "url": "https://update.dsesecurity.com/updates/google-workspace-web-session-exclusions-idp-renewal/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-web-session-exclusions-idp-renewal.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-web-session-exclusions-idp-renewal/" }, "title": "Account for Google web-session exclusions and the upstream IdP session", "summary": "A shorter Google web session may renew silently if the upstream identity-provider session is still valid.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:55+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 270, "potentially_affected": "This applies to Google Workspace session-length controls on eligible editions. Review the exact browser, mobile, ChromeOS, and third-party IdP paths before promising a universal reauthentication interval.", "dse_recommendation": "DSE recommends describing the desired reauthentication outcome for each client class.", "primary_source": { "name": "Google — Session length", "url": "https://knowledge.workspace.google.com/admin/security/set-session-length-for-google-services?hl=en", "published_on": null, "authority": "knowledge.workspace.google.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": "A shorter Google web session may renew silently if the upstream identity-provider session is still valid.
\nGoogle Workspace web-session settings do not cover every client. Google documents exclusions for OAuth-authenticated applications, native mobile apps, and ChromeOS, with separate ChromeOS controls. A changed duration takes effect after users sign out and sign back in; existing sessions keep their prior duration until then. With a third-party identity provider, a still-valid IdP session can renew Google authentication without another interactive sign-in. The Google Admin console has its own fixed one-hour session, separate from the configurable sessions for other Google services.
\nSource: Google — Session length.
\nThis applies to Google Workspace session-length controls on eligible editions. Review the exact browser, mobile, ChromeOS, and third-party IdP paths before promising a universal reauthentication interval.
\nDSE recommends describing the desired reauthentication outcome for each client class. Inventory browser sessions, native mobile apps, and integrations rather than treating them as one population. Coordinate the Google and IdP lifetimes with the identity owner, and plan how existing users will receive the new setting. If an immediate transition is required, review the documented sign-in-cookie reset process and its user impact. Keep the Admin console’s fixed behavior separate in support guidance so its prompt is not mistaken for a failed organization-wide policy.
\nUse controlled test accounts to compare a newly signed-in web session, an existing session, and a native client. Repeat through the third-party IdP if used. Record the actual prompt and relevant session state, and confirm the policy outcome without assuming every client follows the web-browser rule.
\nGoogle — Session length. Reviewed October 15, 2026.
", "content_text": "A shorter Google web session may renew silently if the upstream identity-provider session is still valid.\nSource facts\nGoogle Workspace web-session settings do not cover every client. Google documents exclusions for OAuth-authenticated applications, native mobile apps, and ChromeOS, with separate ChromeOS controls. A changed duration takes effect after users sign out and sign back in; existing sessions keep their prior duration until then. With a third-party identity provider, a still-valid IdP session can renew Google authentication without another interactive sign-in. The Google Admin console has its own fixed one-hour session, separate from the configurable sessions for other Google services.\nSource: Google — Session length.\nApplicability\nThis applies to Google Workspace session-length controls on eligible editions. Review the exact browser, mobile, ChromeOS, and third-party IdP paths before promising a universal reauthentication interval.\nDSE recommendation\nDSE recommends describing the desired reauthentication outcome for each client class. Inventory browser sessions, native mobile apps, and integrations rather than treating them as one population. Coordinate the Google and IdP lifetimes with the identity owner, and plan how existing users will receive the new setting. If an immediate transition is required, review the documented sign-in-cookie reset process and its user impact. Keep the Admin console’s fixed behavior separate in support guidance so its prompt is not mistaken for a failed organization-wide policy.\nVerification\nUse controlled test accounts to compare a newly signed-in web session, an existing session, and a native client. Repeat through the third-party IdP if used. Record the actual prompt and relevant session state, and confirm the policy outcome without assuming every client follows the web-browser rule.\nOfficial reference\nGoogle — Session length. Reviewed October 15, 2026.", "content_markdown": "A shorter Google web session may renew silently if the upstream identity-provider session is still valid.\n\n## Source facts\n\nGoogle Workspace web-session settings do not cover every client. Google documents exclusions for OAuth-authenticated applications, native mobile apps, and ChromeOS, with separate ChromeOS controls. A changed duration takes effect after users sign out and sign back in; existing sessions keep their prior duration until then. With a third-party identity provider, a still-valid IdP session can renew Google authentication without another interactive sign-in. The Google Admin console has its own fixed one-hour session, separate from the configurable sessions for other Google services.\n\nSource: [Google — Session length](https://knowledge.workspace.google.com/admin/security/set-session-length-for-google-services?hl=en).\n\n## Applicability\n\nThis applies to Google Workspace session-length controls on eligible editions. Review the exact browser, mobile, ChromeOS, and third-party IdP paths before promising a universal reauthentication interval.\n\n## DSE recommendation\n\nDSE recommends describing the desired reauthentication outcome for each client class. Inventory browser sessions, native mobile apps, and integrations rather than treating them as one population. Coordinate the Google and IdP lifetimes with the identity owner, and plan how existing users will receive the new setting. If an immediate transition is required, review the documented sign-in-cookie reset process and its user impact. Keep the Admin console’s fixed behavior separate in support guidance so its prompt is not mistaken for a failed organization-wide policy.\n\n## Verification\n\nUse controlled test accounts to compare a newly signed-in web session, an existing session, and a native client. Repeat through the third-party IdP if used. Record the actual prompt and relevant session state, and confirm the policy outcome without assuming every client follows the web-browser rule.\n\n## Official reference\n\n[Google — Session length](https://knowledge.workspace.google.com/admin/security/set-session-length-for-google-services?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-oauth-specific-data-versus-trusted/", "slug": "google-workspace-oauth-specific-data-versus-trusted", "url": "https://update.dsesecurity.com/updates/google-workspace-oauth-specific-data-versus-trusted/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-oauth-specific-data-versus-trusted.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-oauth-specific-data-versus-trusted/" }, "title": "Choose scope-specific Google Workspace app access before marking an integration Trusted", "summary": "An application that needs one service does not automatically need permission to request every Workspace scope.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:54+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 272, "potentially_affected": "This applies to Google Workspace OAuth app-access controls. The selected organizational unit, app type, Google sign-in requirements, and any Context-Aware Access exemption must be checked separately.", "dse_recommendation": "DSE recommends identifying the exact OAuth client before approving an integration.", "primary_source": { "name": "Google — App access controls", "url": "https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data?hl=en", "published_on": null, "authority": "knowledge.workspace.google.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": "An application that needs one service does not automatically need permission to request every Workspace scope.
\nGoogle Workspace API controls distinguish Trusted, Specific Google data, Limited, and Blocked application access. Trusted allows access across Workspace services, including restricted ones. Specific Google data limits an app to the scopes configured by the administrator, while Limited allows only unrestricted services. The Admin console exposes the OAuth client ID and requested scopes for review. Google warns that the scope list shown during configuration can include everything an app has ever requested; the app’s details view shows the exact scopes currently configured.
\nSource: Google — App access controls.
\nThis applies to Google Workspace OAuth app-access controls. The selected organizational unit, app type, Google sign-in requirements, and any Context-Aware Access exemption must be checked separately.
\nDSE recommends identifying the exact OAuth client before approving an integration. Obtain the vendor’s required scope list and map each permission to the business task it enables. Prefer a scope-specific decision where it satisfies the approved requirement, and preserve necessary sign-in scopes. Review inherited organizational-unit settings and any explicit exceptions before expanding access. Record the approver, client ID, intended user population, and review date. Recheck scopes after integration changes instead of assuming the original app name represents an unchanged permission request.
\nUse a test user in the intended organizational unit to complete the approved integration workflow. Confirm the configured client and scopes in the details view, then test that an unapproved data operation remains unavailable. Record results without exporting user tokens or live data from unrelated services.
\nGoogle — App access controls. Reviewed October 15, 2026.
", "content_text": "An application that needs one service does not automatically need permission to request every Workspace scope.\nSource facts\nGoogle Workspace API controls distinguish Trusted, Specific Google data, Limited, and Blocked application access. Trusted allows access across Workspace services, including restricted ones. Specific Google data limits an app to the scopes configured by the administrator, while Limited allows only unrestricted services. The Admin console exposes the OAuth client ID and requested scopes for review. Google warns that the scope list shown during configuration can include everything an app has ever requested; the app’s details view shows the exact scopes currently configured.\nSource: Google — App access controls.\nApplicability\nThis applies to Google Workspace OAuth app-access controls. The selected organizational unit, app type, Google sign-in requirements, and any Context-Aware Access exemption must be checked separately.\nDSE recommendation\nDSE recommends identifying the exact OAuth client before approving an integration. Obtain the vendor’s required scope list and map each permission to the business task it enables. Prefer a scope-specific decision where it satisfies the approved requirement, and preserve necessary sign-in scopes. Review inherited organizational-unit settings and any explicit exceptions before expanding access. Record the approver, client ID, intended user population, and review date. Recheck scopes after integration changes instead of assuming the original app name represents an unchanged permission request.\nVerification\nUse a test user in the intended organizational unit to complete the approved integration workflow. Confirm the configured client and scopes in the details view, then test that an unapproved data operation remains unavailable. Record results without exporting user tokens or live data from unrelated services.\nOfficial reference\nGoogle — App access controls. Reviewed October 15, 2026.", "content_markdown": "An application that needs one service does not automatically need permission to request every Workspace scope.\n\n## Source facts\n\nGoogle Workspace API controls distinguish Trusted, Specific Google data, Limited, and Blocked application access. Trusted allows access across Workspace services, including restricted ones. Specific Google data limits an app to the scopes configured by the administrator, while Limited allows only unrestricted services. The Admin console exposes the OAuth client ID and requested scopes for review. Google warns that the scope list shown during configuration can include everything an app has ever requested; the app’s details view shows the exact scopes currently configured.\n\nSource: [Google — App access controls](https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data?hl=en).\n\n## Applicability\n\nThis applies to Google Workspace OAuth app-access controls. The selected organizational unit, app type, Google sign-in requirements, and any Context-Aware Access exemption must be checked separately.\n\n## DSE recommendation\n\nDSE recommends identifying the exact OAuth client before approving an integration. Obtain the vendor’s required scope list and map each permission to the business task it enables. Prefer a scope-specific decision where it satisfies the approved requirement, and preserve necessary sign-in scopes. Review inherited organizational-unit settings and any explicit exceptions before expanding access. Record the approver, client ID, intended user population, and review date. Recheck scopes after integration changes instead of assuming the original app name represents an unchanged permission request.\n\n## Verification\n\nUse a test user in the intended organizational unit to complete the approved integration workflow. Confirm the configured client and scopes in the details view, then test that an unapproved data operation remains unavailable. Record results without exporting user tokens or live data from unrelated services.\n\n## Official reference\n\n[Google — App access controls](https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-encrypted-export-account-portability-key-rotation/", "slug": "bitwarden-encrypted-export-account-portability-key-rotation", "url": "https://update.dsesecurity.com/updates/bitwarden-encrypted-export-account-portability-key-rotation/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-encrypted-export-account-portability-key-rotation.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-encrypted-export-account-portability-key-rotation/" }, "title": "Choose a portable Bitwarden encrypted export before moving between accounts or regions", "summary": "An account-restricted export cannot be restored to a newly created account with the same email address.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" } ], "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:33:53+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 271, "potentially_affected": "This concerns the portability of Bitwarden encrypted export formats. It does not establish that an export includes every attachment or configuration detail required for a complete service recovery.", "dse_recommendation": "DSE recommends deciding the recovery destination before selecting an export type.", "primary_source": { "name": "Bitwarden — Encrypted exports", "url": "https://bitwarden.com/help/encrypted-export/", "published_on": null, "authority": "bitwarden.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": "An account-restricted export cannot be restored to a newly created account with the same email address.
\nBitwarden offers account-restricted and password-protected encrypted JSON exports. Account-restricted exports depend on the originating account or organization encryption key and can only be imported back there. The documentation explicitly excludes another account with the same email address and an account on a different geographic or self-hosted server. Rotating the originating encryption key can also make an old restricted export undecryptable. Password-protected exports use the chosen password and can be imported into a different Bitwarden account, making them the documented option for that migration requirement.
\nSource: Bitwarden — Encrypted exports.
\nThis concerns the portability of Bitwarden encrypted export formats. It does not establish that an export includes every attachment or configuration detail required for a complete service recovery.
\nDSE recommends deciding the recovery destination before selecting an export type. If the requirement is migration or recovery into a replacement account, document why a password-protected export is appropriate and protect its password separately from the file. For account-restricted exports, include encryption-key rotation in the process that refreshes recovery material. Record source server, account or organization, format, creation date, and intended destination without including secrets. Verify authorized import rights and protect temporary exports through the approved credential-handling process.
\nUse a synthetic vault to test the chosen destination scenario. Confirm that the selected format imports where intended, and review key-rotation consequences before relying on an older restricted export. Check a representative item after import and securely remove temporary test files and passwords when the exercise is complete.
\nBitwarden — Encrypted exports. Reviewed October 15, 2026.
", "content_text": "An account-restricted export cannot be restored to a newly created account with the same email address.\nSource facts\nBitwarden offers account-restricted and password-protected encrypted JSON exports. Account-restricted exports depend on the originating account or organization encryption key and can only be imported back there. The documentation explicitly excludes another account with the same email address and an account on a different geographic or self-hosted server. Rotating the originating encryption key can also make an old restricted export undecryptable. Password-protected exports use the chosen password and can be imported into a different Bitwarden account, making them the documented option for that migration requirement.\nSource: Bitwarden — Encrypted exports.\nApplicability\nThis concerns the portability of Bitwarden encrypted export formats. It does not establish that an export includes every attachment or configuration detail required for a complete service recovery.\nDSE recommendation\nDSE recommends deciding the recovery destination before selecting an export type. If the requirement is migration or recovery into a replacement account, document why a password-protected export is appropriate and protect its password separately from the file. For account-restricted exports, include encryption-key rotation in the process that refreshes recovery material. Record source server, account or organization, format, creation date, and intended destination without including secrets. Verify authorized import rights and protect temporary exports through the approved credential-handling process.\nVerification\nUse a synthetic vault to test the chosen destination scenario. Confirm that the selected format imports where intended, and review key-rotation consequences before relying on an older restricted export. Check a representative item after import and securely remove temporary test files and passwords when the exercise is complete.\nOfficial reference\nBitwarden — Encrypted exports. Reviewed October 15, 2026.", "content_markdown": "An account-restricted export cannot be restored to a newly created account with the same email address.\n\n## Source facts\n\nBitwarden offers account-restricted and password-protected encrypted JSON exports. Account-restricted exports depend on the originating account or organization encryption key and can only be imported back there. The documentation explicitly excludes another account with the same email address and an account on a different geographic or self-hosted server. Rotating the originating encryption key can also make an old restricted export undecryptable. Password-protected exports use the chosen password and can be imported into a different Bitwarden account, making them the documented option for that migration requirement.\n\nSource: [Bitwarden — Encrypted exports](https://bitwarden.com/help/encrypted-export/).\n\n## Applicability\n\nThis concerns the portability of Bitwarden encrypted export formats. It does not establish that an export includes every attachment or configuration detail required for a complete service recovery.\n\n## DSE recommendation\n\nDSE recommends deciding the recovery destination before selecting an export type. If the requirement is migration or recovery into a replacement account, document why a password-protected export is appropriate and protect its password separately from the file. For account-restricted exports, include encryption-key rotation in the process that refreshes recovery material. Record source server, account or organization, format, creation date, and intended destination without including secrets. Verify authorized import rights and protect temporary exports through the approved credential-handling process.\n\n## Verification\n\nUse a synthetic vault to test the chosen destination scenario. Confirm that the selected format imports where intended, and review key-rotation consequences before relying on an older restricted export. Check a representative item after import and securely remove temporary test files and passwords when the exercise is complete.\n\n## Official reference\n\n[Bitwarden — Encrypted exports](https://bitwarden.com/help/encrypted-export/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-directory-connector-shared-config-scheduling/", "slug": "bitwarden-directory-connector-shared-config-scheduling", "url": "https://update.dsesecurity.com/updates/bitwarden-directory-connector-shared-config-scheduling/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-directory-connector-shared-config-scheduling.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-directory-connector-shared-config-scheduling/" }, "title": "Keep Bitwarden Directory Connector’s desktop and scheduled CLI runs from competing", "summary": "The desktop app and CLI share local configuration, so treat them as one synchronization workflow.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:52+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 271, "potentially_affected": "This applies to Bitwarden Directory Connector, not SCIM or SSO authentication. A scheduled process still needs access to the chosen directory and the organization’s provisioning credentials.", "dse_recommendation": "DSE recommends naming one synchronization host and one operational owner.", "primary_source": { "name": "Bitwarden — Directory Connector", "url": "https://bitwarden.com/help/directory-sync/", "published_on": null, "authority": "bitwarden.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": "The desktop app and CLI share local configuration, so treat them as one synchronization workflow.
\nBitwarden Directory Connector pulls users, groups, and associations from a supported source directory. It can run on demand or at a configured interval and can be configured to remove disabled users from the organization without deleting their accounts. The desktop app and CLI share their database and configuration, and Bitwarden does not recommend using them simultaneously on one machine. Its documented approach is to configure and test with the desktop app, then use the CLI to schedule production synchronization.
\nSource: Bitwarden — Directory Connector.
\nThis applies to Bitwarden Directory Connector, not SCIM or SSO authentication. A scheduled process still needs access to the chosen directory and the organization’s provisioning credentials.
\nDSE recommends naming one synchronization host and one operational owner. Complete a reviewed configuration in the desktop app, record the intended source and scope, then document how the scheduled CLI obtains that same configuration. Pause the scheduled task while making controlled desktop changes rather than running competing sessions. Review removal behavior before enabling automatic production runs, and maintain a protected change record for configuration and credential updates. Monitor completion and failures so a silent stalled task does not leave identity changes unapplied.
\nUse test users and groups to compare a desktop run with the intended scheduled CLI run, one at a time. Confirm the configured source scope and handling of a disabled test user. Verify that the schedule reports success or failure and that an administrator knows how to pause it during maintenance.
\nBitwarden — Directory Connector. Reviewed October 15, 2026.
", "content_text": "The desktop app and CLI share local configuration, so treat them as one synchronization workflow.\nSource facts\nBitwarden Directory Connector pulls users, groups, and associations from a supported source directory. It can run on demand or at a configured interval and can be configured to remove disabled users from the organization without deleting their accounts. The desktop app and CLI share their database and configuration, and Bitwarden does not recommend using them simultaneously on one machine. Its documented approach is to configure and test with the desktop app, then use the CLI to schedule production synchronization.\nSource: Bitwarden — Directory Connector.\nApplicability\nThis applies to Bitwarden Directory Connector, not SCIM or SSO authentication. A scheduled process still needs access to the chosen directory and the organization’s provisioning credentials.\nDSE recommendation\nDSE recommends naming one synchronization host and one operational owner. Complete a reviewed configuration in the desktop app, record the intended source and scope, then document how the scheduled CLI obtains that same configuration. Pause the scheduled task while making controlled desktop changes rather than running competing sessions. Review removal behavior before enabling automatic production runs, and maintain a protected change record for configuration and credential updates. Monitor completion and failures so a silent stalled task does not leave identity changes unapplied.\nVerification\nUse test users and groups to compare a desktop run with the intended scheduled CLI run, one at a time. Confirm the configured source scope and handling of a disabled test user. Verify that the schedule reports success or failure and that an administrator knows how to pause it during maintenance.\nOfficial reference\nBitwarden — Directory Connector. Reviewed October 15, 2026.", "content_markdown": "The desktop app and CLI share local configuration, so treat them as one synchronization workflow.\n\n## Source facts\n\nBitwarden Directory Connector pulls users, groups, and associations from a supported source directory. It can run on demand or at a configured interval and can be configured to remove disabled users from the organization without deleting their accounts. The desktop app and CLI share their database and configuration, and Bitwarden does not recommend using them simultaneously on one machine. Its documented approach is to configure and test with the desktop app, then use the CLI to schedule production synchronization.\n\nSource: [Bitwarden — Directory Connector](https://bitwarden.com/help/directory-sync/).\n\n## Applicability\n\nThis applies to Bitwarden Directory Connector, not SCIM or SSO authentication. A scheduled process still needs access to the chosen directory and the organization’s provisioning credentials.\n\n## DSE recommendation\n\nDSE recommends naming one synchronization host and one operational owner. Complete a reviewed configuration in the desktop app, record the intended source and scope, then document how the scheduled CLI obtains that same configuration. Pause the scheduled task while making controlled desktop changes rather than running competing sessions. Review removal behavior before enabling automatic production runs, and maintain a protected change record for configuration and credential updates. Monitor completion and failures so a silent stalled task does not leave identity changes unapplied.\n\n## Verification\n\nUse test users and groups to compare a desktop run with the intended scheduled CLI run, one at a time. Confirm the configured source scope and handling of a disabled test user. Verify that the schedule reports success or failure and that an administrator knows how to pause it during maintenance.\n\n## Official reference\n\n[Bitwarden — Directory Connector](https://bitwarden.com/help/directory-sync/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-scim-staged-users-invitation-policy-boundary/", "slug": "bitwarden-scim-staged-users-invitation-policy-boundary", "url": "https://update.dsesecurity.com/updates/bitwarden-scim-staged-users-invitation-policy-boundary/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-scim-staged-users-invitation-policy-boundary.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-scim-staged-users-invitation-policy-boundary/" }, "title": "Distinguish staged Bitwarden SCIM records from invited organization members", "summary": "A synchronized staged record does not yet receive an invitation, occupy a seat, or inherit policies.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:51+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 269, "potentially_affected": "This concerns Bitwarden SCIM provisioning and invitation state on supported organization plans. Provisioning a record is separate from authentication, vault decryption, and assignment of access to collection data.", "dse_recommendation": "DSE recommends tracking the onboarding sequence from source-directory assignment through staged record, invitation, acceptance, confirmation, and intended collection access.", "primary_source": { "name": "Bitwarden — About SCIM", "url": "https://bitwarden.com/help/about-scim/", "published_on": null, "authority": "bitwarden.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": "A synchronized staged record does not yet receive an invitation, occupy a seat, or inherit policies.
\nBitwarden SCIM can provision and deprovision organization members and groups from an identity provider using a SCIM endpoint and API key. By default, newly provisioned users enter Staged status rather than receiving an immediate invitation. The Automatically send email invitations setting changes that behavior. Staged users receive no invitation email, do not occupy a license seat, and are not subject to organization policies. The documentation also warns administrators to turn off Directory Connector before enabling SCIM when migrating from that provisioning method.
\nSource: Bitwarden — About SCIM.
\nThis concerns Bitwarden SCIM provisioning and invitation state on supported organization plans. Provisioning a record is separate from authentication, vault decryption, and assignment of access to collection data.
\nDSE recommends tracking the onboarding sequence from source-directory assignment through staged record, invitation, acceptance, confirmation, and intended collection access. Decide whether automatic invitations fit the organization’s joiner process before enabling them. Give helpdesk staff a status-based troubleshooting guide so they do not repeatedly recreate a user whose record is simply staged. During a migration, designate one provisioning authority and retire the previous synchronization job deliberately. Keep the SCIM key in approved secret storage and record its operational owner.
\nProvision a test user with automatic invitations disabled and confirm the staged state and lack of invitation. Then exercise the approved invitation path and check the final collection access. Review the old connector schedule during a SCIM migration to verify that competing synchronization is no longer running.
\nBitwarden — About SCIM. Reviewed October 15, 2026.
", "content_text": "A synchronized staged record does not yet receive an invitation, occupy a seat, or inherit policies.\nSource facts\nBitwarden SCIM can provision and deprovision organization members and groups from an identity provider using a SCIM endpoint and API key. By default, newly provisioned users enter Staged status rather than receiving an immediate invitation. The Automatically send email invitations setting changes that behavior. Staged users receive no invitation email, do not occupy a license seat, and are not subject to organization policies. The documentation also warns administrators to turn off Directory Connector before enabling SCIM when migrating from that provisioning method.\nSource: Bitwarden — About SCIM.\nApplicability\nThis concerns Bitwarden SCIM provisioning and invitation state on supported organization plans. Provisioning a record is separate from authentication, vault decryption, and assignment of access to collection data.\nDSE recommendation\nDSE recommends tracking the onboarding sequence from source-directory assignment through staged record, invitation, acceptance, confirmation, and intended collection access. Decide whether automatic invitations fit the organization’s joiner process before enabling them. Give helpdesk staff a status-based troubleshooting guide so they do not repeatedly recreate a user whose record is simply staged. During a migration, designate one provisioning authority and retire the previous synchronization job deliberately. Keep the SCIM key in approved secret storage and record its operational owner.\nVerification\nProvision a test user with automatic invitations disabled and confirm the staged state and lack of invitation. Then exercise the approved invitation path and check the final collection access. Review the old connector schedule during a SCIM migration to verify that competing synchronization is no longer running.\nOfficial reference\nBitwarden — About SCIM. Reviewed October 15, 2026.", "content_markdown": "A synchronized staged record does not yet receive an invitation, occupy a seat, or inherit policies.\n\n## Source facts\n\nBitwarden SCIM can provision and deprovision organization members and groups from an identity provider using a SCIM endpoint and API key. By default, newly provisioned users enter Staged status rather than receiving an immediate invitation. The Automatically send email invitations setting changes that behavior. Staged users receive no invitation email, do not occupy a license seat, and are not subject to organization policies. The documentation also warns administrators to turn off Directory Connector before enabling SCIM when migrating from that provisioning method.\n\nSource: [Bitwarden — About SCIM](https://bitwarden.com/help/about-scim/).\n\n## Applicability\n\nThis concerns Bitwarden SCIM provisioning and invitation state on supported organization plans. Provisioning a record is separate from authentication, vault decryption, and assignment of access to collection data.\n\n## DSE recommendation\n\nDSE recommends tracking the onboarding sequence from source-directory assignment through staged record, invitation, acceptance, confirmation, and intended collection access. Decide whether automatic invitations fit the organization’s joiner process before enabling them. Give helpdesk staff a status-based troubleshooting guide so they do not repeatedly recreate a user whose record is simply staged. During a migration, designate one provisioning authority and retire the previous synchronization job deliberately. Keep the SCIM key in approved secret storage and record its operational owner.\n\n## Verification\n\nProvision a test user with automatic invitations disabled and confirm the staged state and lack of invitation. Then exercise the approved invitation path and check the final collection access. Review the old connector schedule during a SCIM migration to verify that competing synchronization is no longer running.\n\n## Official reference\n\n[Bitwarden — About SCIM](https://bitwarden.com/help/about-scim/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-passwordless-member-removal-account-transition/", "slug": "bitwarden-passwordless-member-removal-account-transition", "url": "https://update.dsesecurity.com/updates/bitwarden-passwordless-member-removal-account-transition/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-passwordless-member-removal-account-transition.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-passwordless-member-removal-account-transition/" }, "title": "Plan the Bitwarden account transition before removing a member with no master password", "summary": "A passwordless member can lose access to the entire account unless the documented transition is completed first.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:50+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 278, "potentially_affected": "This applies to the documented Bitwarden trusted-device account type without a master password. It is a planned account-transition issue, not a recommendation to preserve access during a security termination.", "dse_recommendation": "DSE recommends identifying the member’s actual decryption and recovery state before a planned organization departure.", "primary_source": { "name": "Bitwarden — Onboarding and succession", "url": "https://bitwarden.com/help/onboarding-and-succession/", "published_on": null, "authority": "bitwarden.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": "A passwordless member can lose access to the entire account unless the documented transition is completed first.
\nBitwarden’s succession guide describes a specific removal risk for members who have no master password because they use SSO with trusted devices. Removing such a member eliminates account access unless account recovery first assigns a master password and the member signs in with that password at least once before removal. Without those steps, the guide says the removed user cannot simply rejoin and must delete the account and receive a new invitation. Revoking organization access also locks out the account until that access is restored.
\nSource: Bitwarden — Onboarding and succession.
\nThis applies to the documented Bitwarden trusted-device account type without a master password. It is a planned account-transition issue, not a recommendation to preserve access during a security termination.
\nDSE recommends identifying the member’s actual decryption and recovery state before a planned organization departure. Decide with the data owner whether the person is meant to retain an individual account and what data may remain there. If that transition is approved, follow the documented recovery and first-login sequence before removal, using protected credential handling. Keep the timing separate from any immediate security revocation requirement. Do not assume that sending another invitation will repair an account whose required transition was skipped.
\nRehearse the approved sequence with a synthetic passwordless test account. Confirm the assigned master password works through an actual sign-in before removing the test membership. Verify the intended post-removal account behavior and retained organization ownership, then document the outcome without copying credentials or real vault data.
\nBitwarden — Onboarding and succession. Reviewed October 15, 2026.
", "content_text": "A passwordless member can lose access to the entire account unless the documented transition is completed first.\nSource facts\nBitwarden’s succession guide describes a specific removal risk for members who have no master password because they use SSO with trusted devices. Removing such a member eliminates account access unless account recovery first assigns a master password and the member signs in with that password at least once before removal. Without those steps, the guide says the removed user cannot simply rejoin and must delete the account and receive a new invitation. Revoking organization access also locks out the account until that access is restored.\nSource: Bitwarden — Onboarding and succession.\nApplicability\nThis applies to the documented Bitwarden trusted-device account type without a master password. It is a planned account-transition issue, not a recommendation to preserve access during a security termination.\nDSE recommendation\nDSE recommends identifying the member’s actual decryption and recovery state before a planned organization departure. Decide with the data owner whether the person is meant to retain an individual account and what data may remain there. If that transition is approved, follow the documented recovery and first-login sequence before removal, using protected credential handling. Keep the timing separate from any immediate security revocation requirement. Do not assume that sending another invitation will repair an account whose required transition was skipped.\nVerification\nRehearse the approved sequence with a synthetic passwordless test account. Confirm the assigned master password works through an actual sign-in before removing the test membership. Verify the intended post-removal account behavior and retained organization ownership, then document the outcome without copying credentials or real vault data.\nOfficial reference\nBitwarden — Onboarding and succession. Reviewed October 15, 2026.", "content_markdown": "A passwordless member can lose access to the entire account unless the documented transition is completed first.\n\n## Source facts\n\nBitwarden’s succession guide describes a specific removal risk for members who have no master password because they use SSO with trusted devices. Removing such a member eliminates account access unless account recovery first assigns a master password and the member signs in with that password at least once before removal. Without those steps, the guide says the removed user cannot simply rejoin and must delete the account and receive a new invitation. Revoking organization access also locks out the account until that access is restored.\n\nSource: [Bitwarden — Onboarding and succession](https://bitwarden.com/help/onboarding-and-succession/).\n\n## Applicability\n\nThis applies to the documented Bitwarden trusted-device account type without a master password. It is a planned account-transition issue, not a recommendation to preserve access during a security termination.\n\n## DSE recommendation\n\nDSE recommends identifying the member’s actual decryption and recovery state before a planned organization departure. Decide with the data owner whether the person is meant to retain an individual account and what data may remain there. If that transition is approved, follow the documented recovery and first-login sequence before removal, using protected credential handling. Keep the timing separate from any immediate security revocation requirement. Do not assume that sending another invitation will repair an account whose required transition was skipped.\n\n## Verification\n\nRehearse the approved sequence with a synthetic passwordless test account. Confirm the assigned master password works through an actual sign-in before removing the test membership. Verify the intended post-removal account behavior and retained organization ownership, then document the outcome without copying credentials or real vault data.\n\n## Official reference\n\n[Bitwarden — Onboarding and succession](https://bitwarden.com/help/onboarding-and-succession/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-nested-collection-no-access-inheritance/", "slug": "bitwarden-nested-collection-no-access-inheritance", "url": "https://update.dsesecurity.com/updates/bitwarden-nested-collection-no-access-inheritance/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-nested-collection-no-access-inheritance.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-nested-collection-no-access-inheritance/" }, "title": "Do not infer Bitwarden collection permissions from the folder-like hierarchy", "summary": "Nesting organizes the list; it does not copy a parent collection’s access or items.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:49+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 264, "potentially_affected": "This concerns Bitwarden organization collections and their visual nesting. Personal-vault folders, group membership, and organization administrative roles are separate concepts with different effects.", "dse_recommendation": "DSE recommends maintaining a collection-to-group access table independent of the visual hierarchy.", "primary_source": { "name": "Bitwarden — Collections", "url": "https://bitwarden.com/help/about-collections/", "published_on": null, "authority": "bitwarden.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": "Nesting organizes the list; it does not copy a parent collection’s access or items.
\nBitwarden collections group organization-owned items for sharing, and the organization can assign access to users or groups. An organization-owned item must belong to at least one collection, while its ownership stays with the organization rather than an individual user. The documentation makes a specific distinction about nested collections: nesting changes how the collection list appears in the vault filter. It does not cause the child collection to inherit its parent’s items, access, or permissions. Those assignments must be configured independently.
\nSource: Bitwarden — Collections.
\nThis concerns Bitwarden organization collections and their visual nesting. Personal-vault folders, group membership, and organization administrative roles are separate concepts with different effects.
\nDSE recommends maintaining a collection-to-group access table independent of the visual hierarchy. When creating a nested collection, review its explicit permissions and intended items instead of assuming the parent establishes a boundary. Use names that help users find information without implying inheritance that does not exist. During a restructure, check both old and new assignments before moving sensitive items. Keep organization ownership and collection access visible in the change record so a tidy-looking list does not hide unintended sharing.
\nCreate parent and child test collections with different synthetic items and access groups. Confirm that access to the parent alone does not reveal the child’s items. Add the intended child assignment and retest. Review effective permissions through every relevant group and individual assignment before applying the structure to production data.
\nBitwarden — Collections. Reviewed October 15, 2026.
", "content_text": "Nesting organizes the list; it does not copy a parent collection’s access or items.\nSource facts\nBitwarden collections group organization-owned items for sharing, and the organization can assign access to users or groups. An organization-owned item must belong to at least one collection, while its ownership stays with the organization rather than an individual user. The documentation makes a specific distinction about nested collections: nesting changes how the collection list appears in the vault filter. It does not cause the child collection to inherit its parent’s items, access, or permissions. Those assignments must be configured independently.\nSource: Bitwarden — Collections.\nApplicability\nThis concerns Bitwarden organization collections and their visual nesting. Personal-vault folders, group membership, and organization administrative roles are separate concepts with different effects.\nDSE recommendation\nDSE recommends maintaining a collection-to-group access table independent of the visual hierarchy. When creating a nested collection, review its explicit permissions and intended items instead of assuming the parent establishes a boundary. Use names that help users find information without implying inheritance that does not exist. During a restructure, check both old and new assignments before moving sensitive items. Keep organization ownership and collection access visible in the change record so a tidy-looking list does not hide unintended sharing.\nVerification\nCreate parent and child test collections with different synthetic items and access groups. Confirm that access to the parent alone does not reveal the child’s items. Add the intended child assignment and retest. Review effective permissions through every relevant group and individual assignment before applying the structure to production data.\nOfficial reference\nBitwarden — Collections. Reviewed October 15, 2026.", "content_markdown": "Nesting organizes the list; it does not copy a parent collection’s access or items.\n\n## Source facts\n\nBitwarden collections group organization-owned items for sharing, and the organization can assign access to users or groups. An organization-owned item must belong to at least one collection, while its ownership stays with the organization rather than an individual user. The documentation makes a specific distinction about nested collections: nesting changes how the collection list appears in the vault filter. It does not cause the child collection to inherit its parent’s items, access, or permissions. Those assignments must be configured independently.\n\nSource: [Bitwarden — Collections](https://bitwarden.com/help/about-collections/).\n\n## Applicability\n\nThis concerns Bitwarden organization collections and their visual nesting. Personal-vault folders, group membership, and organization administrative roles are separate concepts with different effects.\n\n## DSE recommendation\n\nDSE recommends maintaining a collection-to-group access table independent of the visual hierarchy. When creating a nested collection, review its explicit permissions and intended items instead of assuming the parent establishes a boundary. Use names that help users find information without implying inheritance that does not exist. During a restructure, check both old and new assignments before moving sensitive items. Keep organization ownership and collection access visible in the change record so a tidy-looking list does not hide unintended sharing.\n\n## Verification\n\nCreate parent and child test collections with different synthetic items and access groups. Confirm that access to the parent alone does not reveal the child’s items. Add the intended child assignment and retest. Review effective permissions through every relevant group and individual assignment before applying the structure to production data.\n\n## Official reference\n\n[Bitwarden — Collections](https://bitwarden.com/help/about-collections/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-trusted-device-per-app-approval/", "slug": "bitwarden-trusted-device-per-app-approval", "url": "https://update.dsesecurity.com/updates/bitwarden-trusted-device-per-app-approval/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-trusted-device-per-app-approval.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-trusted-device-per-app-approval/" }, "title": "Approve the Bitwarden app instance, not just the computer name", "summary": "The browser extension and desktop application on one computer are separate trusted devices.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:48+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 274, "potentially_affected": "This applies to organizations using Bitwarden SSO with trusted devices. It is different from a computer’s inventory status, browser profile management, or an identity provider’s own trusted-device flag.", "dse_recommendation": "DSE recommends recording which app and browser profile a user is trying to approve.", "primary_source": { "name": "Bitwarden — Trusted devices", "url": "https://bitwarden.com/help/about-trusted-devices/", "published_on": null, "authority": "bitwarden.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": "The browser extension and desktop application on one computer are separate trusted devices.
\nBitwarden SSO with trusted devices separates SSO authentication from vault decryption using a device-stored key. A trusted device means an approved Bitwarden application instance, such as a browser extension or mobile app. Each app requires its own approval even when several apps run on one computer or phone. An untrusted app must obtain approval through an available method before it can decrypt the vault. The documentation describes approval from another device, administrator approval, or an existing master password where the account has one.
\nSource: Bitwarden — Trusted devices.
\nThis applies to organizations using Bitwarden SSO with trusted devices. It is different from a computer’s inventory status, browser profile management, or an identity provider’s own trusted-device flag.
\nDSE recommends recording which app and browser profile a user is trying to approve. A request from a newly installed extension should not be dismissed simply because the same computer’s desktop app already works. Confirm the requester and the intended app instance using the approved identity process before accepting a request. Document available recovery methods for users without an established trusted app. Include browser-profile replacement, app reinstallations, and device retirement in user guidance so approval requests have an understandable operational context.
\nUse a controlled account to sign in through two separate Bitwarden apps on one test device. Confirm that approval of the first does not silently establish trust for the second. Review the approval method and verify that an unapproved app cannot decrypt the vault merely because SSO authentication succeeded.
\nBitwarden — Trusted devices. Reviewed October 15, 2026.
", "content_text": "The browser extension and desktop application on one computer are separate trusted devices.\nSource facts\nBitwarden SSO with trusted devices separates SSO authentication from vault decryption using a device-stored key. A trusted device means an approved Bitwarden application instance, such as a browser extension or mobile app. Each app requires its own approval even when several apps run on one computer or phone. An untrusted app must obtain approval through an available method before it can decrypt the vault. The documentation describes approval from another device, administrator approval, or an existing master password where the account has one.\nSource: Bitwarden — Trusted devices.\nApplicability\nThis applies to organizations using Bitwarden SSO with trusted devices. It is different from a computer’s inventory status, browser profile management, or an identity provider’s own trusted-device flag.\nDSE recommendation\nDSE recommends recording which app and browser profile a user is trying to approve. A request from a newly installed extension should not be dismissed simply because the same computer’s desktop app already works. Confirm the requester and the intended app instance using the approved identity process before accepting a request. Document available recovery methods for users without an established trusted app. Include browser-profile replacement, app reinstallations, and device retirement in user guidance so approval requests have an understandable operational context.\nVerification\nUse a controlled account to sign in through two separate Bitwarden apps on one test device. Confirm that approval of the first does not silently establish trust for the second. Review the approval method and verify that an unapproved app cannot decrypt the vault merely because SSO authentication succeeded.\nOfficial reference\nBitwarden — Trusted devices. Reviewed October 15, 2026.", "content_markdown": "The browser extension and desktop application on one computer are separate trusted devices.\n\n## Source facts\n\nBitwarden SSO with trusted devices separates SSO authentication from vault decryption using a device-stored key. A trusted device means an approved Bitwarden application instance, such as a browser extension or mobile app. Each app requires its own approval even when several apps run on one computer or phone. An untrusted app must obtain approval through an available method before it can decrypt the vault. The documentation describes approval from another device, administrator approval, or an existing master password where the account has one.\n\nSource: [Bitwarden — Trusted devices](https://bitwarden.com/help/about-trusted-devices/).\n\n## Applicability\n\nThis applies to organizations using Bitwarden SSO with trusted devices. It is different from a computer’s inventory status, browser profile management, or an identity provider’s own trusted-device flag.\n\n## DSE recommendation\n\nDSE recommends recording which app and browser profile a user is trying to approve. A request from a newly installed extension should not be dismissed simply because the same computer’s desktop app already works. Confirm the requester and the intended app instance using the approved identity process before accepting a request. Document available recovery methods for users without an established trusted app. Include browser-profile replacement, app reinstallations, and device retirement in user guidance so approval requests have an understandable operational context.\n\n## Verification\n\nUse a controlled account to sign in through two separate Bitwarden apps on one test device. Confirm that approval of the first does not silently establish trust for the second. Review the approval method and verify that an unapproved app cannot decrypt the vault merely because SSO authentication succeeded.\n\n## Official reference\n\n[Bitwarden — Trusted devices](https://bitwarden.com/help/about-trusted-devices/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-event-log-client-delay-coverage-limits/", "slug": "bitwarden-event-log-client-delay-coverage-limits", "url": "https://update.dsesecurity.com/updates/bitwarden-event-log-client-delay-coverage-limits/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-event-log-client-delay-coverage-limits.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-event-log-client-delay-coverage-limits/" }, "title": "Interpret missing Bitwarden events with the client-reporting limits in mind", "summary": "An empty event search does not prove that an offline client performed no action.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:47+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 269, "potentially_affected": "This applies to organization event logs on eligible Bitwarden plans. It does not establish a complete endpoint audit trail or guarantee that every offline or tampered-client action is represented.", "dse_recommendation": "DSE recommends defining which event types an investigation requires before exporting logs.", "primary_source": { "name": "Bitwarden — Event logs", "url": "https://bitwarden.com/help/event-logs/", "published_on": null, "authority": "bitwarden.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": "An empty event search does not prove that an offline client performed no action.
\nBitwarden organization event logs include timestamped activity and can be viewed or exported through documented web and API interfaces. The documentation distinguishes server events, which are saved immediately, from client events, which are normally transmitted periodically. A disconnected client cannot report events, and altered clients can suppress or modify reporting. Bitwarden explicitly cautions that these logs may not satisfy every forensic or auditing requirement. The event viewer also limits the date span displayed at one time even though the documented retention is longer.
\nSource: Bitwarden — Event logs.
\nThis applies to organization event logs on eligible Bitwarden plans. It does not establish a complete endpoint audit trail or guarantee that every offline or tampered-client action is represented.
\nDSE recommends defining which event types an investigation requires before exporting logs. Allow for normal client-reporting delay, and compare the requested time range with the viewer’s limits. Preserve relevant account, device, and application evidence through the appropriate process when a missing event matters. Document the distinction between “no matching record found” and “the action did not occur.” Review API export access and protected storage for event data, and correlate organization changes with independent identity or endpoint records where appropriate.
\nWith a test account and synthetic vault item, perform a documented client event and compare its appearance with a server-side change. Observe reporting timing without assuming a fixed maximum. Confirm the export covers the requested period and record any known disconnected-client interval as an evidence limitation.
\nBitwarden — Event logs. Reviewed October 15, 2026.
", "content_text": "An empty event search does not prove that an offline client performed no action.\nSource facts\nBitwarden organization event logs include timestamped activity and can be viewed or exported through documented web and API interfaces. The documentation distinguishes server events, which are saved immediately, from client events, which are normally transmitted periodically. A disconnected client cannot report events, and altered clients can suppress or modify reporting. Bitwarden explicitly cautions that these logs may not satisfy every forensic or auditing requirement. The event viewer also limits the date span displayed at one time even though the documented retention is longer.\nSource: Bitwarden — Event logs.\nApplicability\nThis applies to organization event logs on eligible Bitwarden plans. It does not establish a complete endpoint audit trail or guarantee that every offline or tampered-client action is represented.\nDSE recommendation\nDSE recommends defining which event types an investigation requires before exporting logs. Allow for normal client-reporting delay, and compare the requested time range with the viewer’s limits. Preserve relevant account, device, and application evidence through the appropriate process when a missing event matters. Document the distinction between “no matching record found” and “the action did not occur.” Review API export access and protected storage for event data, and correlate organization changes with independent identity or endpoint records where appropriate.\nVerification\nWith a test account and synthetic vault item, perform a documented client event and compare its appearance with a server-side change. Observe reporting timing without assuming a fixed maximum. Confirm the export covers the requested period and record any known disconnected-client interval as an evidence limitation.\nOfficial reference\nBitwarden — Event logs. Reviewed October 15, 2026.", "content_markdown": "An empty event search does not prove that an offline client performed no action.\n\n## Source facts\n\nBitwarden organization event logs include timestamped activity and can be viewed or exported through documented web and API interfaces. The documentation distinguishes server events, which are saved immediately, from client events, which are normally transmitted periodically. A disconnected client cannot report events, and altered clients can suppress or modify reporting. Bitwarden explicitly cautions that these logs may not satisfy every forensic or auditing requirement. The event viewer also limits the date span displayed at one time even though the documented retention is longer.\n\nSource: [Bitwarden — Event logs](https://bitwarden.com/help/event-logs/).\n\n## Applicability\n\nThis applies to organization event logs on eligible Bitwarden plans. It does not establish a complete endpoint audit trail or guarantee that every offline or tampered-client action is represented.\n\n## DSE recommendation\n\nDSE recommends defining which event types an investigation requires before exporting logs. Allow for normal client-reporting delay, and compare the requested time range with the viewer’s limits. Preserve relevant account, device, and application evidence through the appropriate process when a missing event matters. Document the distinction between “no matching record found” and “the action did not occur.” Review API export access and protected storage for event data, and correlate organization changes with independent identity or endpoint records where appropriate.\n\n## Verification\n\nWith a test account and synthetic vault item, perform a documented client event and compare its appearance with a server-side change. Observe reporting timing without assuming a fixed maximum. Confirm the export covers the requested period and record any known disconnected-client interval as an evidence limitation.\n\n## Official reference\n\n[Bitwarden — Event logs](https://bitwarden.com/help/event-logs/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-secure-files-log-access-audit-boundaries/", "slug": "gitlab-secure-files-log-access-audit-boundaries", "url": "https://update.dsesecurity.com/updates/gitlab-secure-files-log-access-audit-boundaries/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-secure-files-log-access-audit-boundaries.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-secure-files-log-access-audit-boundaries/" }, "title": "Review GitLab Secure Files access and logging before storing signing material", "summary": "Secure Files encrypts stored files, but job output and project access still need explicit review.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:46+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 275, "potentially_affected": "This applies to GitLab project-level Secure Files, not CI variables or an external secrets manager. Verify current version support and the privileges of every project member before selecting this mechanism.", "dse_recommendation": "DSE recommends treating storage protection, job exposure, and audit evidence as separate requirements.", "primary_source": { "name": "GitLab — Secure Files", "url": "https://docs.gitlab.com/ci/secure_files/", "published_on": null, "authority": "docs.gitlab.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": "Secure Files encrypts stored files, but job output and project access still need explicit review.
\nGitLab project-level Secure Files stores files outside the repository and does not version-control them. The documented feature accepts text and binary files within its size limit. Uploaded files are encrypted, and the current glab download command verifies their recorded checksum. However, contents printed by a job are not masked in the job log. Project members with Developer, Maintainer, or Owner roles can access the files. GitLab also documents that interactions with project-level Secure Files are not included in audit events.
\nSource: GitLab — Secure Files.
\nThis applies to GitLab project-level Secure Files, not CI variables or an external secrets manager. Verify current version support and the privileges of every project member before selecting this mechanism.
\nDSE recommends treating storage protection, job exposure, and audit evidence as separate requirements. Store only material intended for the project’s authorized developer population. Download the specific required file to a controlled job path, and prevent scripts or debugging output from printing its contents. Keep a separate owner-approved change record for rotations because repository history and Secure Files audit events will not supply that record. Review runner persistence and artifact paths so a downloaded private key does not escape through a cache or build archive.
\nUse a harmless test file to confirm download checksum verification and identify which roles can retrieve it. Review job logs and resulting artifacts for accidental inclusion. Confirm the rotation record can identify the approved replacement without expecting a Secure Files audit event that the feature does not provide.
\nGitLab — Secure Files. Reviewed October 15, 2026.
", "content_text": "Secure Files encrypts stored files, but job output and project access still need explicit review.\nSource facts\nGitLab project-level Secure Files stores files outside the repository and does not version-control them. The documented feature accepts text and binary files within its size limit. Uploaded files are encrypted, and the current glab download command verifies their recorded checksum. However, contents printed by a job are not masked in the job log. Project members with Developer, Maintainer, or Owner roles can access the files. GitLab also documents that interactions with project-level Secure Files are not included in audit events.\nSource: GitLab — Secure Files.\nApplicability\nThis applies to GitLab project-level Secure Files, not CI variables or an external secrets manager. Verify current version support and the privileges of every project member before selecting this mechanism.\nDSE recommendation\nDSE recommends treating storage protection, job exposure, and audit evidence as separate requirements. Store only material intended for the project’s authorized developer population. Download the specific required file to a controlled job path, and prevent scripts or debugging output from printing its contents. Keep a separate owner-approved change record for rotations because repository history and Secure Files audit events will not supply that record. Review runner persistence and artifact paths so a downloaded private key does not escape through a cache or build archive.\nVerification\nUse a harmless test file to confirm download checksum verification and identify which roles can retrieve it. Review job logs and resulting artifacts for accidental inclusion. Confirm the rotation record can identify the approved replacement without expecting a Secure Files audit event that the feature does not provide.\nOfficial reference\nGitLab — Secure Files. Reviewed October 15, 2026.", "content_markdown": "Secure Files encrypts stored files, but job output and project access still need explicit review.\n\n## Source facts\n\nGitLab project-level Secure Files stores files outside the repository and does not version-control them. The documented feature accepts text and binary files within its size limit. Uploaded files are encrypted, and the current glab download command verifies their recorded checksum. However, contents printed by a job are not masked in the job log. Project members with Developer, Maintainer, or Owner roles can access the files. GitLab also documents that interactions with project-level Secure Files are not included in audit events.\n\nSource: [GitLab — Secure Files](https://docs.gitlab.com/ci/secure_files/).\n\n## Applicability\n\nThis applies to GitLab project-level Secure Files, not CI variables or an external secrets manager. Verify current version support and the privileges of every project member before selecting this mechanism.\n\n## DSE recommendation\n\nDSE recommends treating storage protection, job exposure, and audit evidence as separate requirements. Store only material intended for the project’s authorized developer population. Download the specific required file to a controlled job path, and prevent scripts or debugging output from printing its contents. Keep a separate owner-approved change record for rotations because repository history and Secure Files audit events will not supply that record. Review runner persistence and artifact paths so a downloaded private key does not escape through a cache or build archive.\n\n## Verification\n\nUse a harmless test file to confirm download checksum verification and identify which roles can retrieve it. Review job logs and resulting artifacts for accidental inclusion. Confirm the rotation record can identify the approved replacement without expecting a Secure Files audit event that the feature does not provide.\n\n## Official reference\n\n[GitLab — Secure Files](https://docs.gitlab.com/ci/secure_files/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-ci-inputs-creation-time-validation-scope/", "slug": "gitlab-ci-inputs-creation-time-validation-scope", "url": "https://update.dsesecurity.com/updates/gitlab-ci-inputs-creation-time-validation-scope/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-ci-inputs-creation-time-validation-scope.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-ci-inputs-creation-time-validation-scope/" }, "title": "Validate GitLab pipeline options at creation time with typed inputs", "summary": "Typed inputs can reject invalid pipeline choices before jobs begin, but they are not runtime variables.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:45+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 273, "potentially_affected": "This covers GitLab CI/CD input configuration on supported versions. It does not make arbitrary script interpolation safe or turn user-supplied pipeline options into protected secret storage.", "dse_recommendation": "DSE recommends using bounded inputs for operational choices such as an approved environment or deployment mode.", "primary_source": { "name": "GitLab — CI/CD inputs", "url": "https://docs.gitlab.com/ci/inputs/", "published_on": null, "authority": "docs.gitlab.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": "Typed inputs can reject invalid pipeline choices before jobs begin, but they are not runtime variables.
\nGitLab CI/CD inputs provide typed parameters and validation when a pipeline is created. Their values are interpolated at initialization and remain fixed for the pipeline run. Inputs can restrict values through types, predefined options, and regular expressions. Their scope is the configuration file where they are defined; another included file or downstream pipeline needs an explicit input handoff. An input without a default is mandatory. GitLab warns that automatically triggered pipelines can fail to start if required inputs have no available values.
\nSource: GitLab — CI/CD inputs.
\nThis covers GitLab CI/CD input configuration on supported versions. It does not make arbitrary script interpolation safe or turn user-supplied pipeline options into protected secret storage.
\nDSE recommends using bounded inputs for operational choices such as an approved environment or deployment mode. Define the smallest useful option set and describe the consequence of each choice in plain language. Review how manual, scheduled, merge-request, and downstream pipelines obtain their values. Choose safe defaults only where the workflow allows them; otherwise provide an explicit required value through the calling configuration. Keep credentials in the approved secret mechanism and review the scripts that consume inputs as carefully as other pipeline code.
\nTest one valid option, an invalid value, and a missing mandatory input in a nonproduction pipeline. Confirm that validation occurs before jobs run. Exercise an included configuration and a downstream pipeline to verify explicit input passing, and check every automatic trigger path the project actually uses.
\nGitLab — CI/CD inputs. Reviewed October 15, 2026.
", "content_text": "Typed inputs can reject invalid pipeline choices before jobs begin, but they are not runtime variables.\nSource facts\nGitLab CI/CD inputs provide typed parameters and validation when a pipeline is created. Their values are interpolated at initialization and remain fixed for the pipeline run. Inputs can restrict values through types, predefined options, and regular expressions. Their scope is the configuration file where they are defined; another included file or downstream pipeline needs an explicit input handoff. An input without a default is mandatory. GitLab warns that automatically triggered pipelines can fail to start if required inputs have no available values.\nSource: GitLab — CI/CD inputs.\nApplicability\nThis covers GitLab CI/CD input configuration on supported versions. It does not make arbitrary script interpolation safe or turn user-supplied pipeline options into protected secret storage.\nDSE recommendation\nDSE recommends using bounded inputs for operational choices such as an approved environment or deployment mode. Define the smallest useful option set and describe the consequence of each choice in plain language. Review how manual, scheduled, merge-request, and downstream pipelines obtain their values. Choose safe defaults only where the workflow allows them; otherwise provide an explicit required value through the calling configuration. Keep credentials in the approved secret mechanism and review the scripts that consume inputs as carefully as other pipeline code.\nVerification\nTest one valid option, an invalid value, and a missing mandatory input in a nonproduction pipeline. Confirm that validation occurs before jobs run. Exercise an included configuration and a downstream pipeline to verify explicit input passing, and check every automatic trigger path the project actually uses.\nOfficial reference\nGitLab — CI/CD inputs. Reviewed October 15, 2026.", "content_markdown": "Typed inputs can reject invalid pipeline choices before jobs begin, but they are not runtime variables.\n\n## Source facts\n\nGitLab CI/CD inputs provide typed parameters and validation when a pipeline is created. Their values are interpolated at initialization and remain fixed for the pipeline run. Inputs can restrict values through types, predefined options, and regular expressions. Their scope is the configuration file where they are defined; another included file or downstream pipeline needs an explicit input handoff. An input without a default is mandatory. GitLab warns that automatically triggered pipelines can fail to start if required inputs have no available values.\n\nSource: [GitLab — CI/CD inputs](https://docs.gitlab.com/ci/inputs/).\n\n## Applicability\n\nThis covers GitLab CI/CD input configuration on supported versions. It does not make arbitrary script interpolation safe or turn user-supplied pipeline options into protected secret storage.\n\n## DSE recommendation\n\nDSE recommends using bounded inputs for operational choices such as an approved environment or deployment mode. Define the smallest useful option set and describe the consequence of each choice in plain language. Review how manual, scheduled, merge-request, and downstream pipelines obtain their values. Choose safe defaults only where the workflow allows them; otherwise provide an explicit required value through the calling configuration. Keep credentials in the approved secret mechanism and review the scripts that consume inputs as carefully as other pipeline code.\n\n## Verification\n\nTest one valid option, an invalid value, and a missing mandatory input in a nonproduction pipeline. Confirm that validation occurs before jobs run. Exercise an included configuration and a downstream pipeline to verify explicit input passing, and check every automatic trigger path the project actually uses.\n\n## Official reference\n\n[GitLab — CI/CD inputs](https://docs.gitlab.com/ci/inputs/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-job-artifact-expiry-keep-latest-exceptions/", "slug": "gitlab-job-artifact-expiry-keep-latest-exceptions", "url": "https://update.dsesecurity.com/updates/gitlab-job-artifact-expiry-keep-latest-exceptions/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-job-artifact-expiry-keep-latest-exceptions.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-job-artifact-expiry-keep-latest-exceptions/" }, "title": "Check GitLab’s keep-latest behavior before relying on artifact expiry", "summary": "An expire_in value alone does not describe the retention of every pipeline artifact.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:44+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 269, "potentially_affected": "This applies to GitLab job-artifact retention and download behavior as documented on review. Check the installed version and project or instance settings before forecasting storage reclamation.", "dse_recommendation": "DSE recommends separating temporary pipeline handoffs from distributable releases.", "primary_source": { "name": "GitLab — Job artifacts", "url": "https://docs.gitlab.com/ci/jobs/job_artifacts/", "published_on": null, "authority": "docs.gitlab.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": "An expire_in value alone does not describe the retention of every pipeline artifact.
\nGitLab job artifacts can have an expire_in setting; otherwise the instance default applies. The current documentation states that artifacts from the latest pipeline on each reference and the most recent successful pipeline can be preserved regardless of that expiry. Disabling the keep-latest behavior makes new artifacts follow their configured expiry, while older preserved artifacts may remain until another pipeline runs for the same reference. A latest-artifact URL also changes its target as new pipelines run, so it is not a fixed release identifier.
\nSource: GitLab — Job artifacts.
\nThis applies to GitLab job-artifact retention and download behavior as documented on review. Check the installed version and project or instance settings before forecasting storage reclamation.
\nDSE recommends separating temporary pipeline handoffs from distributable releases. Record the desired retention, the keep-latest setting, and whether a branch is likely to run another pipeline. Review artifact contents for accidental credential or customer-data inclusion before retention changes. Use an appropriate versioned release store for outputs that must have a stable identity, rather than relying on a moving latest-job link. Obtain the required retention decision before deleting artifacts, and account for job logs or report data that may also be affected.
\nCreate harmless artifacts on a test reference, observe the relevant keep-latest behavior, then run a newer pipeline and review which artifacts become eligible to expire. Check the resolved target of a latest URL. Record settings and timing without interpreting “eligible for expiry” as immediate guaranteed disk reclamation.
\nGitLab — Job artifacts. Reviewed October 15, 2026.
", "content_text": "An expire_in value alone does not describe the retention of every pipeline artifact.\nSource facts\nGitLab job artifacts can have an expire_in setting; otherwise the instance default applies. The current documentation states that artifacts from the latest pipeline on each reference and the most recent successful pipeline can be preserved regardless of that expiry. Disabling the keep-latest behavior makes new artifacts follow their configured expiry, while older preserved artifacts may remain until another pipeline runs for the same reference. A latest-artifact URL also changes its target as new pipelines run, so it is not a fixed release identifier.\nSource: GitLab — Job artifacts.\nApplicability\nThis applies to GitLab job-artifact retention and download behavior as documented on review. Check the installed version and project or instance settings before forecasting storage reclamation.\nDSE recommendation\nDSE recommends separating temporary pipeline handoffs from distributable releases. Record the desired retention, the keep-latest setting, and whether a branch is likely to run another pipeline. Review artifact contents for accidental credential or customer-data inclusion before retention changes. Use an appropriate versioned release store for outputs that must have a stable identity, rather than relying on a moving latest-job link. Obtain the required retention decision before deleting artifacts, and account for job logs or report data that may also be affected.\nVerification\nCreate harmless artifacts on a test reference, observe the relevant keep-latest behavior, then run a newer pipeline and review which artifacts become eligible to expire. Check the resolved target of a latest URL. Record settings and timing without interpreting “eligible for expiry” as immediate guaranteed disk reclamation.\nOfficial reference\nGitLab — Job artifacts. Reviewed October 15, 2026.", "content_markdown": "An expire_in value alone does not describe the retention of every pipeline artifact.\n\n## Source facts\n\nGitLab job artifacts can have an expire_in setting; otherwise the instance default applies. The current documentation states that artifacts from the latest pipeline on each reference and the most recent successful pipeline can be preserved regardless of that expiry. Disabling the keep-latest behavior makes new artifacts follow their configured expiry, while older preserved artifacts may remain until another pipeline runs for the same reference. A latest-artifact URL also changes its target as new pipelines run, so it is not a fixed release identifier.\n\nSource: [GitLab — Job artifacts](https://docs.gitlab.com/ci/jobs/job_artifacts/).\n\n## Applicability\n\nThis applies to GitLab job-artifact retention and download behavior as documented on review. Check the installed version and project or instance settings before forecasting storage reclamation.\n\n## DSE recommendation\n\nDSE recommends separating temporary pipeline handoffs from distributable releases. Record the desired retention, the keep-latest setting, and whether a branch is likely to run another pipeline. Review artifact contents for accidental credential or customer-data inclusion before retention changes. Use an appropriate versioned release store for outputs that must have a stable identity, rather than relying on a moving latest-job link. Obtain the required retention decision before deleting artifacts, and account for job logs or report data that may also be affected.\n\n## Verification\n\nCreate harmless artifacts on a test reference, observe the relevant keep-latest behavior, then run a newer pipeline and review which artifacts become eligible to expire. Check the resolved target of a latest URL. Record settings and timing without interpreting “eligible for expiry” as immediate guaranteed disk reclamation.\n\n## Official reference\n\n[GitLab — Job artifacts](https://docs.gitlab.com/ci/jobs/job_artifacts/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-shared-runner-private-image-pull-policy/", "slug": "gitlab-shared-runner-private-image-pull-policy", "url": "https://update.dsesecurity.com/updates/gitlab-shared-runner-private-image-pull-policy/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-shared-runner-private-image-pull-policy.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-shared-runner-private-image-pull-policy/" }, "title": "Prevent a shared GitLab runner from reusing another project’s private image without a registry check", "summary": "The if-not-present pull policy can cross an authorization boundary through the local image cache.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:43+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 266, "potentially_affected": "This concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.", "dse_recommendation": "DSE recommends documenting which users and projects share each runner and who controls image selection.", "primary_source": { "name": "GitLab — Runner security", "url": "https://docs.gitlab.com/runner/security/", "published_on": null, "authority": "docs.gitlab.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": "The if-not-present pull policy can cross an authorization boundary through the local image cache.
\nGitLab’s runner security guide describes a private-image risk on shared runners. One user’s authorized job can pull an image into the runner’s local cache. A later user without registry access can request that image and receive the cached copy when the pull policy is if-not-present. GitLab recommends always for mixed-trust runners where users may request registry images, and reserves if-not-present for trusted dedicated use. The guide also distinguishes never for an administrator-controlled set of images already present on the runner.
\nSource: GitLab — Runner security.
\nThis concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.
\nDSE recommends documenting which users and projects share each runner and who controls image selection. For mixed-trust use, require an appropriate registry authorization check instead of silently trusting a cached private image. For a deliberately fixed image set, review the administrator-maintained model separately. Inspect runner configuration, allowed policies, and job overrides together. Keep credential helpers and host-side registry configuration in the broader runner security review, and consider dedicated execution capacity for workloads with incompatible trust requirements.
\nUsing a disposable private image and two test identities, verify the chosen policy with a warm cache and with no cache. Confirm that an identity lacking registry permission cannot obtain the cached private image through the shared runner. Remove the test image and credentials afterward.
\nGitLab — Runner security. Reviewed October 15, 2026.
", "content_text": "The if-not-present pull policy can cross an authorization boundary through the local image cache.\nSource facts\nGitLab’s runner security guide describes a private-image risk on shared runners. One user’s authorized job can pull an image into the runner’s local cache. A later user without registry access can request that image and receive the cached copy when the pull policy is if-not-present. GitLab recommends always for mixed-trust runners where users may request registry images, and reserves if-not-present for trusted dedicated use. The guide also distinguishes never for an administrator-controlled set of images already present on the runner.\nSource: GitLab — Runner security.\nApplicability\nThis concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.\nDSE recommendation\nDSE recommends documenting which users and projects share each runner and who controls image selection. For mixed-trust use, require an appropriate registry authorization check instead of silently trusting a cached private image. For a deliberately fixed image set, review the administrator-maintained model separately. Inspect runner configuration, allowed policies, and job overrides together. Keep credential helpers and host-side registry configuration in the broader runner security review, and consider dedicated execution capacity for workloads with incompatible trust requirements.\nVerification\nUsing a disposable private image and two test identities, verify the chosen policy with a warm cache and with no cache. Confirm that an identity lacking registry permission cannot obtain the cached private image through the shared runner. Remove the test image and credentials afterward.\nOfficial reference\nGitLab — Runner security. Reviewed October 15, 2026.", "content_markdown": "The if-not-present pull policy can cross an authorization boundary through the local image cache.\n\n## Source facts\n\nGitLab’s runner security guide describes a private-image risk on shared runners. One user’s authorized job can pull an image into the runner’s local cache. A later user without registry access can request that image and receive the cached copy when the pull policy is if-not-present. GitLab recommends always for mixed-trust runners where users may request registry images, and reserves if-not-present for trusted dedicated use. The guide also distinguishes never for an administrator-controlled set of images already present on the runner.\n\nSource: [GitLab — Runner security](https://docs.gitlab.com/runner/security/).\n\n## Applicability\n\nThis concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.\n\n## DSE recommendation\n\nDSE recommends documenting which users and projects share each runner and who controls image selection. For mixed-trust use, require an appropriate registry authorization check instead of silently trusting a cached private image. For a deliberately fixed image set, review the administrator-maintained model separately. Inspect runner configuration, allowed policies, and job overrides together. Keep credential helpers and host-side registry configuration in the broader runner security review, and consider dedicated execution capacity for workloads with incompatible trust requirements.\n\n## Verification\n\nUsing a disposable private image and two test identities, verify the chosen policy with a warm cache and with no cache. Confirm that an identity lacking registry permission cannot obtain the cached private image through the shared runner. Remove the test image and credentials afterward.\n\n## Official reference\n\n[GitLab — Runner security](https://docs.gitlab.com/runner/security/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-deployment-approval-manual-job-start/", "slug": "gitlab-deployment-approval-manual-job-start", "url": "https://update.dsesecurity.com/updates/gitlab-deployment-approval-manual-job-start/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-deployment-approval-manual-job-start.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-deployment-approval-manual-job-start/" }, "title": "Explain why an approved GitLab deployment may still be waiting to run", "summary": "Approval satisfies the release gate; the deployment job still requires a separate start.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "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:33:42+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 258, "potentially_affected": "This concerns GitLab deployment approvals on supported Premium or Ultimate environments. Pipeline status, environment protection, approval eligibility, and permission to execute the job are related but separate checks.", "dse_recommendation": "DSE recommends making the release procedure explicit about who approves and who starts the reviewed deployment.", "primary_source": { "name": "GitLab — Deployment approvals", "url": "https://docs.gitlab.com/ci/environments/deployment_approvals/", "published_on": null, "authority": "docs.gitlab.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": "Approval satisfies the release gate; the deployment job still requires a separate start.
\nGitLab deployment approvals block jobs targeting protected environments until the required approvals are granted. The deployment job does not have to be configured as a manual job for the approval gate to apply. After approval, however, the documentation requires an operator to run the job manually; approval alone does not start it. A person can provide only one approval per deployment even when they belong to several approver groups. By default, the user who triggered the pipeline cannot approve that deployment.
\nSource: GitLab — Deployment approvals.
\nThis concerns GitLab deployment approvals on supported Premium or Ultimate environments. Pipeline status, environment protection, approval eligibility, and permission to execute the job are related but separate checks.
\nDSE recommends making the release procedure explicit about who approves and who starts the reviewed deployment. Present a release record that identifies the pipeline, commit, environment, required approvals, and final execution step. Avoid repeatedly creating pipelines when the existing job is simply waiting for its authorized start. Review overlapping approver-group membership so the requested approval count can actually be satisfied. Keep self-approval settings deliberate, and revisit approval rules promptly when staff move or their access changes.
\nIn a test protected environment, observe the blocked job before approval and its state after approval. Confirm that it runs only after the intended operator starts it. Use overlapping test group memberships to verify the one-approval-per-person behavior and record the resulting approval history.
\nGitLab — Deployment approvals. Reviewed October 15, 2026.
", "content_text": "Approval satisfies the release gate; the deployment job still requires a separate start.\nSource facts\nGitLab deployment approvals block jobs targeting protected environments until the required approvals are granted. The deployment job does not have to be configured as a manual job for the approval gate to apply. After approval, however, the documentation requires an operator to run the job manually; approval alone does not start it. A person can provide only one approval per deployment even when they belong to several approver groups. By default, the user who triggered the pipeline cannot approve that deployment.\nSource: GitLab — Deployment approvals.\nApplicability\nThis concerns GitLab deployment approvals on supported Premium or Ultimate environments. Pipeline status, environment protection, approval eligibility, and permission to execute the job are related but separate checks.\nDSE recommendation\nDSE recommends making the release procedure explicit about who approves and who starts the reviewed deployment. Present a release record that identifies the pipeline, commit, environment, required approvals, and final execution step. Avoid repeatedly creating pipelines when the existing job is simply waiting for its authorized start. Review overlapping approver-group membership so the requested approval count can actually be satisfied. Keep self-approval settings deliberate, and revisit approval rules promptly when staff move or their access changes.\nVerification\nIn a test protected environment, observe the blocked job before approval and its state after approval. Confirm that it runs only after the intended operator starts it. Use overlapping test group memberships to verify the one-approval-per-person behavior and record the resulting approval history.\nOfficial reference\nGitLab — Deployment approvals. Reviewed October 15, 2026.", "content_markdown": "Approval satisfies the release gate; the deployment job still requires a separate start.\n\n## Source facts\n\nGitLab deployment approvals block jobs targeting protected environments until the required approvals are granted. The deployment job does not have to be configured as a manual job for the approval gate to apply. After approval, however, the documentation requires an operator to run the job manually; approval alone does not start it. A person can provide only one approval per deployment even when they belong to several approver groups. By default, the user who triggered the pipeline cannot approve that deployment.\n\nSource: [GitLab — Deployment approvals](https://docs.gitlab.com/ci/environments/deployment_approvals/).\n\n## Applicability\n\nThis concerns GitLab deployment approvals on supported Premium or Ultimate environments. Pipeline status, environment protection, approval eligibility, and permission to execute the job are related but separate checks.\n\n## DSE recommendation\n\nDSE recommends making the release procedure explicit about who approves and who starts the reviewed deployment. Present a release record that identifies the pipeline, commit, environment, required approvals, and final execution step. Avoid repeatedly creating pipelines when the existing job is simply waiting for its authorized start. Review overlapping approver-group membership so the requested approval count can actually be satisfied. Keep self-approval settings deliberate, and revisit approval rules promptly when staff move or their access changes.\n\n## Verification\n\nIn a test protected environment, observe the blocked job before approval and its state after approval. Confirm that it runs only after the intended operator starts it. Use overlapping test group memberships to verify the one-approval-per-person behavior and record the resulting approval history.\n\n## Official reference\n\n[GitLab — Deployment approvals](https://docs.gitlab.com/ci/environments/deployment_approvals/). Reviewed October 15, 2026." } ] }