Implementation Planning: Admin-locked "Always off" Duo/DAP availability for selected subgroups

Overview

This issue tracks implementation planning for issue #595666 (closed): Admin-locked "Always off" Duo/DAP availability for selected subgroups.

The goal is to close the governance gap for GitLab customers who need to permanently disable Duo/DAP for specific subgroups while allowing other subgroups to remain owner-controllable under the same instance.

Context

Currently, GitLab supports an Always Off mode at the instance level, but it applies to the entire hierarchy. There is no way to selectively lock specific subgroups as Always off (non-overrideable) while leaving other sibling subgroups as Off by default but owner-controllable.

This is a blocker for customers in regulated/public-sector environments who need:

  • A default-deny posture across the platform (instance = Off by default)
  • Hard-ban on Duo/DAP for specific agency subgroups (admin-locked Always off)
  • Owner-controlled opt-in for other subgroups

Planning Tasks

1. Engineering Discovery

  • Audit the existing Always Off implementation to understand the enforcement cascade (instance → group → subgroup → project)
  • Identify all places in the codebase where Duo availability is read/evaluated and determine what changes are needed to support a new admin-locked Always Off state at the subgroup level
  • Assess how the new locked state interacts with the existing Always Off at instance level and parent group level
  • Confirm clean data migration path for all existing setting combinations
  • Identify API changes needed (REST and GraphQL)
  • Identify any frontend changes needed (admin UI, group settings, project settings)
  • Review relationship and shared implementation with #594735 (Always on locked mode) for symmetry

2. Scope Definition

  • Confirm the exact scopes where admin-locked Always Off can be set (subgroup level, not just instance level)
  • Define who can apply/remove the locked state: instance admins only, or also root group Owners
  • Define the enforcement behavior: when admin-locked Always Off is set, subgroup/project owners cannot enable Duo within that scope
  • Clarify interaction with the DAP Control Plane and child capability toggles
  • Define behavior when instance is Off by default and a subgroup is Always off (locked) — confirm no conflict
  • Define clear messaging shown to subgroup/project Owners when Duo is locked by an ancestor admin

3. Design & UX

  • Align with UX on UI changes for the admin panel and group settings page
  • Review copy/legal implications (e.g., labeling and descriptions for the new locked mode)
  • Design the visual distinction between owner-set Always Off and admin-locked Always Off
  • Consider the broader AI Section proposal (two-control redesign) and whether any parts should be incorporated now or deferred

4. Testing Strategy

  • Define unit and integration test coverage for the new enforcement logic
  • Plan E2E test scenarios covering:
    • Instance Off by default + subgroup Always off (locked) + sibling subgroup Off by default (owner-controllable)
    • Admin applying and removing the locked state
    • Owner attempting to override the locked state (should be blocked)
  • Identify edge cases: mixed settings across nested groups, migration from existing states

5. Rollout & Migration

  • Define feature flag strategy
  • Confirm no data loss for existing setting combinations
  • Plan documentation updates

Open Questions

  • Should admin-locked Always Off be available only on GitLab, or also on self-managed and GitLab.com?
  • What is the interaction between admin-locked Always Off at subgroup level and a parent group that has Always Off (non-locked) set? Which takes precedence?
  • Can a root group Owner apply the locked state, or is it instance-admin-only?
  • Engineering confirmation of clean data migration for all existing setting combinations
  • How does this interact with the related Always On (locked) work in #594735? Should they share implementation?

Requirements / Product Decisions

  • The locked Always Off state must be settable and removable only by instance administrators (not subgroup/project Owners).
  • Subgroup/project Owners must see clear messaging that Duo is disabled and locked by an ancestor admin.
  • The feature must support a mixed model under the same instance: some subgroups locked Always off, others Off by default but owner-controllable.

References

  • Parent Issue: #595666 (closed) Admin-locked "Always off" Duo/DAP availability for selected subgroups on GitLab
  • Related Issue: #594735 Add 'Always on' GitLab Duo availability mode that group Owners cannot override
  • Planning template reference: #598361 Implementation Planning: Add 'Always On' availability mode for Duo
Edited by Nate Rosandich