Documentation Controls Reference

Disables the policy that automatically grants all enterprise members access to every project in the organization.

Remediation steps

1. Navigate to Organization Settings > Policies.
2. Find "Enterprise access to projects".
3. Set it to Off to restrict access.

Microsoft Learn →

Prevents users from requesting access to the organization, eliminating an unmanaged onboarding channel.

Remediation steps

1. Navigate to Organization Settings > Policies.
2. Find "Request access".
3. Set it to Off to prevent users from requesting access to the organization.

Microsoft Learn →

Restricts user invitations to organization administrators only, preventing project or team admins from adding external users without governance.

Remediation steps

1. Navigate to Organization Settings > Policies.
2. Find "Allow team and project administrators to invite new users".
3. Set it to Off.
4. Only Organization Administrators will be able to add new users.

Microsoft Learn →

Restricts Azure DevOps access to a defined set of trusted IP ranges via Microsoft Entra Conditional Access, preventing sign-ins from arbitrary networks.

Remediation steps

1. Microsoft Entra ID P1 or P2 is required.
2. In the Microsoft Entra admin center, open Protection > Conditional Access.
3. Create or update a policy targeting the Azure DevOps cloud app.
4. Under Conditions > Locations, define your trusted IP ranges as a named location.
5. Set the policy to Block (or Grant with restrictions) for sign-ins outside those locations.
6. Enable the policy and validate from a non-trusted IP.

Microsoft Learn →

Verifies that membership in Project Collection Administrators and other privileged groups is limited to users with a current, documented business need.

Remediation steps

1. Navigate to Organization Settings > Permissions.
2. Open the Project Collection Administrators group (and any other privileged groups).
3. Review every member; remove anyone without a current, documented business need.
4. Prefer adding a Microsoft Entra group rather than individual users so membership is governed centrally.
5. Re-review on a recurring schedule (e.g. quarterly).

Microsoft Learn →

Verifies the Project Collection Administrators group has no more than 6 members, applying least-privilege to the most powerful role in the organization.

Remediation steps

1. Navigate to Organization Settings > Permissions.
2. Select "Project Collection Administrators".
3. Review the Members tab.
4. Remove unnecessary members to reduce to 6 or fewer.

Microsoft Learn →

Verifies the Project Collection Administrators group has at least 2 members so there is a backup (break-glass) administrator.

Remediation steps

1. Navigate to Organization Settings > Permissions.
2. Select "Project Collection Administrators".
3. Add at least one backup administrator to ensure continuity.

Microsoft Learn →

Flags non-person / service accounts in PCA so they can be replaced with workload identities (managed identity, service principal, workload identity federation) scoped to least privilege.

Remediation steps

1. Navigate to Organization Settings > Permissions > Project Collection Administrators.
2. Identify any service / non-person accounts (e.g. build, deploy, automation identities).
3. Replace them with a workload identity (managed identity, service principal, or workload identity federation) scoped to the minimum required permissions.
4. Remove the service accounts from the privileged group.

Microsoft Learn →

Confirms that privileged actions are performed from dedicated ALT / SC-ALT administrator accounts rather than from day-to-day user accounts.

Remediation steps

1. Provision dedicated ALT / SC-ALT (administrator) accounts for every user who performs privileged actions.
2. Restrict day-to-day work (email, browsing, code commits) to the standard account.
3. Remove the standard user accounts from Project Collection Administrators and Project Administrators.
4. Add only the ALT accounts to privileged groups.
5. Enforce phishing-resistant MFA and Conditional Access on the ALT accounts.

Microsoft Learn →

Reviews membership of the Project Collection Service Accounts group, which carries PCA-equivalent permissions and should be tightly controlled.

Remediation steps

1. Navigate to Organization Settings > Permissions.
2. Select "Project Collection Service Accounts".
3. Review members — these have PCA-equivalent permissions.
4. Remove any unnecessary members or service accounts.

Microsoft Learn →

Self-hosted agent hosts must be enrolled in a patch-management program so OS and runtime CVEs are remediated on a defined cadence.

Remediation steps

1. Identify the host machine(s) backing the self-hosted agent pool.
2. Enroll them in your patch-management solution (Azure Update Manager, WSUS, SCCM, Ansible, etc.).
3. Confirm the agent service restarts cleanly after patching.
4. Establish a maximum patch-lag SLA (e.g. critical CVEs within 7 days).
5. Document an exception process for anything that cannot be patched.

Microsoft Learn →

Self-hosted agent VMs should be based on a CIS-benchmarked or otherwise hardened image, with unused services disabled and EDR / host firewall in place.

Remediation steps

1. Base the self-hosted agent VM on a hardened image (CIS-benchmarked, Azure Marketplace hardened image, or your golden image).
2. Disable unused services and inbound ports.
3. Apply a host firewall allow-list and EDR/antimalware.
4. Run periodic configuration scans (Microsoft Defender for Cloud, Azure Policy guest configuration, etc.) and remediate drift.

Microsoft Learn →

Disables automatic provisioning of agent pools into every project so pools are intentionally granted only to projects that need them.

Remediation steps

1. Navigate to Organization Settings > Pipelines > Agent pools.
2. Click Settings.
3. Turn Off "Auto-provision this pool in all projects".
4. Manually provision pools only in projects that need them.

Microsoft Learn →

Confirms protected resources (service connections, environments, variable groups, secure files, agent pools) are not granted blanket access to every YAML pipeline.

Remediation steps

1. Navigate to Project Settings.
2. Open the relevant resource (Service connections / Agent pools / Environments / Secure files / Variable groups).
3. Select the resource, click the three dots button, then Security.
4. Under Pipeline permissions, click "Restrict Permission".
5. Add only the specific YAML pipelines that need access.

Microsoft Learn →

Confirms self-hosted agents are configured to auto-update so security patches and protocol changes are picked up promptly.

Remediation steps

1. Navigate to Organization Settings > Pipelines > Agent pools.
2. Select the agent pool.
3. Click Settings.
4. Turn On "Allow agents in this pool to automatically update".

Microsoft Learn →

Detects user-defined agent capability values that look like secrets (tokens, passwords) and would be exposed in plain text to every job that runs on the agent.

Remediation steps

1. Navigate to Organization Settings > Agent pools.
2. Select the pool, then click the Agents tab.
3. Select an agent and click Capabilities.
4. Review user-defined capabilities for any values that look like secrets.
5. Remove or replace with variable references.

Microsoft Learn →

Azure DevOps retains audit events for only 90 days. Streaming them to external storage (Log Analytics, Splunk, Event Grid) preserves the evidence required for incident response and compliance.

Remediation steps

1. Navigate to Organization Settings > Auditing > Streams.
2. Configure an audit stream to an external destination (Azure Event Grid, Azure Monitor / Log Analytics, Splunk, or a generic webhook).
3. Confirm events are arriving at the destination.
4. Retain the exported audit data per your compliance retention requirement (Azure DevOps only retains audit events for 90 days).

Microsoft Learn →

Confirms audit log streaming to a SIEM (Splunk, Azure Monitor, Event Grid, etc.) is configured so security events are retained beyond the 90-day in-product window.

Remediation steps

1. Navigate to Organization Settings > Auditing.
2. Click the Streams tab.
3. Click New Stream to set up audit log streaming.
4. Select your SIEM target (Splunk, Azure Monitor, Azure Event Grid, etc.).
5. Configure and enable the stream.

Microsoft Learn →

Alert rules should fire on sensitive audit events (PCA changes, policy changes, new service connections, broad-scope PAT creation, extension installs) and route to an on-call channel.

Remediation steps

1. Stream audit events to Log Analytics (Azure Monitor) via an audit stream.
2. Define KQL alert rules for sensitive actions: PCA group changes, policy changes, new service connections, extension installs, PAT creation with broad scopes, etc.
3. Route alerts to an on-call channel (Teams, PagerDuty, email).
4. Tune thresholds quarterly to control noise.

Microsoft Learn →

Confirms the organization is backed by Microsoft Entra ID (Azure AD) so user identities and policies are centrally governed and lifecycle-managed.

Remediation steps

1. Navigate to Organization Settings > Azure Active Directory.
2. Click Connect directory.
3. Select your Azure AD tenant and complete the connection.
4. Verify all users are AAD-backed.

Microsoft Learn →

Detects users from external (non-AAD) identity providers, such as personal Microsoft accounts, that may not be subject to organizational identity controls.

Remediation steps

1. Navigate to Organization Settings > Users.
2. Filter for users with non-AAD origins (personal accounts).
3. Review each external user for business justification.
4. Remove unnecessary external users by clicking the three dots > Remove.

Microsoft Learn →

Detects projects with Public visibility, which makes work items and source code accessible without authentication.

Remediation steps

1. Navigate to Project Settings > Overview.
2. Under Visibility, change from Public to Private.
3. Click Save.
4. Repeat for each public project.

Microsoft Learn →

Flags Microsoft Entra B2B guest users (identified by #EXT# in the email) for review to confirm each one has a documented business justification.

Remediation steps

1. Navigate to Organization Settings > Users.
2. Filter for guest users (look for #EXT# in email).
3. Review each guest user for documented business justification.
4. Remove unnecessary guest users via the three dots > Remove.

Microsoft Learn →

Confirms that Microsoft Entra Conditional Access policy validation is enabled so MFA, location, and device controls are enforced on Azure DevOps sign-ins.

Remediation steps

1. Navigate to Organization Settings > Policies.
2. Enable "Enable Azure Active Directory (Azure AD) Conditional Access Policy Validation".
3. Configure Conditional Access policies in Azure AD (requires Azure AD P1/P2).
4. Test that policies are enforced for ADO access.

Microsoft Learn →

Disables the organization-wide setting that allows pipeline status badges to be retrieved without authentication, hiding pipeline names and run outcomes from anonymous users.

Remediation steps

1. Navigate to Organization Settings (or Project Settings).
2. Open Settings under Pipelines.
3. Turn On the setting "Disable anonymous access to badges".

Microsoft Learn →

Detects sensitive values (passwords, keys, tokens, connection strings) stored as regular pipeline variables instead of secret variables or Key Vault references.

Remediation steps

1. Open the pipeline definition (build or release).
2. Review all variables for sensitive values (passwords, keys, tokens, connection strings).
3. For each secret, click the lock icon to mark it as a secret variable.
4. Consider moving secrets to Azure Key Vault and linking via variable groups.

Microsoft Learn →

Every build pipeline should run a SAST tool (CodeQL / GHAzDO, SonarQube, Checkmarx, Semgrep, etc.) and fail on new high/critical findings.

Remediation steps

1. Decide on the SAST tool(s) (CodeQL via GHAzDO, SonarQube/SonarCloud, Checkmarx, Semgrep, etc.).
2. Add the analysis task(s) to each build pipeline (or a shared template).
3. Fail the build on new high/critical findings; track existing findings as work items.
4. For Azure Repos, enable GitHub Advanced Security for Azure DevOps to get code scanning and push protection out of the box.

Microsoft Learn →

Certificates, keystores and signing keys belong in the pipeline Secure Files library with pipeline-scoped permissions, not in the repo or in plain pipeline variables.

Remediation steps

1. Navigate to Project > Pipelines > Library > Secure files.
2. Upload certificates, keystores, signing keys, etc. as secure files (rather than committing them to the repo).
3. Restrict pipeline permissions on each secure file to only the pipelines that need it.
4. In pipelines, use the DownloadSecureFile@1 task to consume them.

Microsoft Learn →

Identifies build pipelines that have not run in 90+ days and should be removed or archived to reduce maintenance and attack surface.

Remediation steps

1. Navigate to Project > Pipelines.
2. Identify pipelines that have not run in 90+ days.
3. Delete or disable unused pipelines via the three dots menu.
4. Document any pipelines kept for archival purposes.

Microsoft Learn →

Prevents pipeline variables from being overridden at queue time unless explicitly allowed, reducing the risk of parameter-injection attacks via run parameters.

Remediation steps

1. Navigate to Organization Settings (or Project Settings).
2. Open Settings under Pipelines.
3. Turn On the setting "Limit variables that can be set at queue time".
4. For each pipeline, mark only necessary variables as "Settable at queue time".

Microsoft Learn →

Flags pipeline variables that accept URL values and are marked settable-at-queue-time — a common SSRF and exfiltration vector.

Remediation steps

1. Open the build pipeline definition.
2. Review variables that accept URL values.
3. Remove the "Settable at queue time" flag from URL-type variables.
4. Hardcode trusted URLs or use service connections instead.

Microsoft Learn →

Flags pipelines that build from external repositories (GitHub, Bitbucket, etc.) so the connections can be reviewed for least-privilege.

Remediation steps

1. Open the build pipeline definition.
2. Check the repository source — if it points to an external repo (GitHub, Bitbucket, etc.).
3. Review and document the business justification for using external repositories.
4. Ensure the external repo connection uses least-privilege authentication.

Microsoft Learn →

Per-pipeline check ensuring the job authorization scope is set to "current project" rather than the whole project collection.

Remediation steps

1. Open the build pipeline definition.
2. Click Settings (three dots > Settings).
3. Under "Build job authorization scope", select "Current project".
4. Save the pipeline.

Microsoft Learn →

Confirms PR validation does not expose pipeline secrets to forked pull-request builds — a common supply-chain attack vector.

Remediation steps

1. Open the build pipeline definition.
2. Go to Triggers > Pull request validation.
3. Uncheck "Make secrets available to builds of forks".
4. Ensure "Build fork pull requests" is carefully controlled.

Microsoft Learn →

Any Copilot-related extension must be from an approved publisher (e.g. GitHub) and aligned with the organization's AI / data-handling policy.

Remediation steps

1. Navigate to Organization Settings > Extensions > Installed.
2. Confirm any Copilot-related extensions are published by GitHub (or another explicitly approved publisher).
3. Uninstall unapproved or look-alike extensions.
4. Document an approval workflow for AI / Copilot-style extensions and align with your AI / data-handling policy.
5. Review extension permissions and the data they can access.

Microsoft Learn →

Ensures multi-stage YAML environments labelled production have an approvals check configured so deployments cannot proceed unattended.

Remediation steps

1. Navigate to Project > Pipelines > Environments.
2. Select the production environment.
3. Click the three dots > Approvals and checks.
4. Add an Approvals check with at least one approver.
5. Consider also adding a Branch control check to restrict to main branch.

Microsoft Learn →

Confirms each production environment requires at least two distinct approvers (or a group), preventing a single account from rubber-stamping a deployment.

Remediation steps

1. Navigate to Project > Pipelines > Environments.
2. Select the production environment.
3. Open Approvals and checks.
4. Edit the Approval check.
5. Add at least 2 distinct approvers (users or a group) and set "Minimum number of approvers required" to 2 or higher.
6. Enable "Requestor should not be an approver" to prevent self-approval.

Microsoft Learn →

Confirms each production environment has a Branch control check that restricts deployments to a protected production branch, preventing unintended deployments from feature branches.

Remediation steps

1. Navigate to Project > Pipelines > Environments > [production environment] > Approvals and checks.
2. Click Add and select "Branch control".
3. Set Allowed branches to refs/heads/main (or your protected production branch).
4. Enable "Ensure protection of the branch" so the check also fails if branch policies are missing.
5. Validate by attempting a deployment from a non-allowed branch and confirming it is blocked.

Microsoft Learn →

Reviews installed Marketplace extensions to confirm each comes from a trusted or verified publisher and is still needed.

Remediation steps

1. Navigate to Organization Settings > Extensions.
2. Review each installed extension and its publisher.
3. Verify the publisher is trusted (Microsoft or verified publisher).
4. Remove any extensions from untrusted or unknown publishers.

Microsoft Learn →

All shared and installed non-built-in extensions should come from trusted publishers and be subject to a documented intake/approval workflow.

Remediation steps

1. Navigate to Organization Settings > Extensions > Shared (and Installed).
2. For each non-built-in extension, verify the publisher is trusted and the extension is still actively maintained.
3. Remove unused or unverified extensions.
4. Establish an approved-publisher allow-list and an intake review for new extension requests.

Microsoft Learn →

The Manage Extensions permission should be limited to a small, trusted group (typically Project Collection Administrators).

Remediation steps

1. Navigate to Organization Settings > Extensions > Permissions.
2. Review who holds the Manage Extensions permission.
3. Restrict the Manager role to a small, trusted group (e.g. Project Collection Administrators).
4. Remove any individual users that no longer need the permission.

Microsoft Learn →

Reviews pending Marketplace extension install requests so unknown or risky extensions are not approved by default.

Remediation steps

1. Navigate to Organization Settings > Extensions.
2. Click the Requested tab.
3. Review each pending request.
4. Approve trusted extensions and reject unknown ones.

Microsoft Learn →

Ensures broad groups (Contributors, Readers, Project Valid Users) only have Reader access on Azure Artifacts feeds so packages cannot be modified by anyone.

Remediation steps

1. Navigate to Artifacts > select the feed.
2. Click the gear icon (Feed settings).
3. Click Permissions.
4. For broad groups (Contributors, Readers, Valid Users), set role to Reader.
5. Remove any unnecessary admin/write access.

Microsoft Learn →

Verifies that package upload (Contributor/Collaborator) permissions on feeds are restricted to specific service accounts or build identities.

Remediation steps

1. Navigate to Artifacts > select the feed.
2. Click the gear icon (Feed settings).
3. Click Permissions.
4. Restrict upload (Contributor/Collaborator) roles to specific service accounts or build identities.
5. Set broad groups to Reader only.

Microsoft Learn →

Restricts who can create Azure Artifacts feeds to a small, named group so feed sprawl and unmanaged package sources are avoided.

Remediation steps

1. Navigate to Organization Settings > Artifacts > Permissions (or the Artifacts hub at organization scope).
2. Review who has the "Create new feed" permission.
3. Restrict creation to a small, named group (e.g. Feed Administrators) rather than Project Collection Valid Users.
4. Document an intake process for new feeds.

Microsoft Learn →

Advisory: flags feeds with active upstream sources. Upstreams are usually required; the real mitigation against dependency-confusion is to publish every internal package name to the feed at least once (save-to-feed) so the local copy always wins over public registries.

Remediation steps

1. Decide whether each upstream (npmjs, nuget.org, Maven Central, etc.) is required. Disable any that aren't.
2. List every internal package name your org publishes.
3. Publish each internal name to the feed at least once so it's saved-to-feed.
4. For npm, use scoped package names (@your-scope/...).
5. Filter the feed view by Saved periodically to confirm internal names are present.
6. Document acceptance of FEED-03 in your remediation log once the mitigation is verified.

Microsoft Learn →

Disables third-party application access via OAuth so unsanctioned apps cannot obtain delegated access to Azure DevOps on a user's behalf.

Remediation steps

1. Navigate to Organization Settings > Policies.
2. Find "Third-party application access via OAuth".
3. Set it to Off.
4. Review any existing OAuth applications and revoke unnecessary access.

Microsoft Learn →

Disables SSH authentication for Git so users authenticate with managed credentials over HTTPS rather than long-lived SSH keys.

Remediation steps

1. Navigate to Organization Settings > Policies.
2. Find "SSH authentication".
3. Set it to Off.
4. Users should use HTTPS with credential managers instead.

Microsoft Learn →

Flags individual PATs that hold all-scopes / full-access permissions instead of the minimum scopes needed for the task.

Remediation steps

1. Navigate to User Settings > Personal access tokens.
2. Select the PAT with full access.
3. Click Edit / Regenerate.
4. Select only the specific scopes needed (e.g., Code: Read, Build: Read & execute).
5. Save with the restricted scope.

Microsoft Learn →

Flags Personal Access Tokens with expirations longer than the recommended 90 days.

Remediation steps

1. Navigate to User Settings > Personal access tokens.
2. Select the long-lived PAT.
3. Click Regenerate.
4. Set the expiration to 90 days or less.
5. Update any automation using the old PAT value.

Microsoft Learn →

Identifies PATs that will expire within 7 days so they can be rotated proactively before automation breaks.

Remediation steps

1. Navigate to User Settings > Personal access tokens.
2. Identify the PAT expiring within 7 days.
3. Click Regenerate to extend with appropriate scope and duration.
4. Update any automation or scripts using the PAT.

Microsoft Learn →

Flags PATs granted highly sensitive scopes (security_manage, entitlements, project_manage) that should be performed by a service principal or managed identity instead.

Remediation steps

1. Navigate to User Settings > Personal access tokens.
2. Identify PATs with critical scopes (security_manage, entitlements, project_manage).
3. Delete the PAT and recreate with minimal required scopes.
4. For automation, use a Service Principal or Managed Identity instead.

Microsoft Learn →

Enforces a maximum lifespan on Personal Access Tokens at the organization level, limiting the value of a leaked token.

Remediation steps

1. Navigate to Organization Settings > Policies.
2. Find "Enforce maximum personal access token lifespan".
3. Set it to On and configure the maximum lifetime (e.g., 90 days).

Microsoft Learn →

Requires Personal Access Tokens to be created with specific scopes rather than full access, enforcing least privilege.

Remediation steps

1. Navigate to Organization Settings > Policies.
2. Find "Restrict scope of personal access tokens".
3. Set it to On to enforce scoped PATs.

Microsoft Learn →

Blocks creation of full-scope (global) Personal Access Tokens at the organization level so tokens must target specific scopes.

Remediation steps

1. Navigate to Organization Settings > Policies.
2. Find "Restrict global personal access tokens".
3. Set it to On to block full-access PATs.

Microsoft Learn →

The "Create repository" permission should be granted only to trusted groups (e.g. Project Administrators) so repos are created through a governed intake process.

Remediation steps

1. Navigate to Project Settings > Repositories > Security.
2. Locate the "Create repository" permission.
3. Set Allow only for trusted groups (e.g. Project Administrators); set Not set or Deny for broad groups like Contributors.
4. Document an intake process for new repos.

Microsoft Learn →

No broader group (Contributors, Project Valid Users, Project Collection Build Service Accounts, etc.) should hold elevated allow bits at the project-default Build ACL. The scanner reads the Build security namespace and FAILs the control when any broad group has Edit, Delete, Administer, Override check-in, or other mutating permission allowed at the project root.

Remediation steps

1. Open Pipelines > Builds and choose Manage security (project-default Build ACL).
2. For each flagged broader group, set Edit / Delete / Administer / Override check-in validation to Not set or Deny.
3. Leave View build pipeline / View builds at Allow only where required.
4. Verify the flagged group can no longer modify or queue pipelines.

Microsoft Learn →

No broader group should hold elevated allow bits at the project-default Release ACL. The scanner reads the ReleaseManagement security namespace and FAILs when any broad group has Edit, Delete, Manage approvers, or Administer allowed at the project root.

Remediation steps

1. Open Pipelines > Releases > Security (project-default).
2. For each flagged broader group, set Edit / Delete / Manage approvers / Administer to Not set or Deny.
3. Leave View at Allow only where required.
4. Confirm the flagged group can no longer modify approvals or release definitions.

Microsoft Learn →

Service connections carry credentials to cloud subscriptions, container registries, and other sensitive systems. Broader groups (Contributors, Project Collection Build Service) should not hold User, Creator, or Administrator at the project-default. The scanner reads the ServiceEndpoints namespace at endpoints/{projectId}.

Remediation steps

1. Open Project Settings > Service connections > Security (project-default).
2. Remove broader groups from User, Administrator, and Creator roles.
3. Grant named pipeline-team groups only.
4. For production-grade connections, prefer per-connection roles over project-default.

Microsoft Learn →

Agent pools execute pipeline tasks with whatever credentials the agent process holds. Broader groups should not hold Use, Manage, or Administer on a pool. This control currently surfaces as NOT CHECKED — per-pool ACL enumeration against the DistributedTask namespace is tracked for Phase 2b.

Remediation steps

1. Open Project Settings > Agent pools.
2. For each pool, choose Security and remove broader groups (Contributors, Build Service) from Administrator, User, and Service Account.
3. Repeat at Organization Settings > Agent pools for org-level pools.

Microsoft Learn →

Variable groups frequently hold secrets (or are linked to Key Vault). Broader groups should not hold Administrator or User at the project-default Library ACL. The scanner reads the Library namespace at Library/{projectId}.

Remediation steps

1. Open Pipelines > Library > Security (project-default).
2. For each flagged broader group, set Administrator and User to Not set.
3. Grant User only to the pipeline teams that consume the variable group.
4. For groups holding secrets, prefer Key Vault-linked variable groups with managed identity.

Microsoft Learn →

No broader group should hold elevated allow bits at the project-default Git ACL. The scanner reads the Git Repositories namespace at repoV2/{projectId} and flags any broad group granted Administer, Manage permissions, Force push, Remove others' locks, Edit policies, or Manage notes.

Remediation steps

1. Open Project Settings > Repositories > Security (project-default Git ACL).
2. For each flagged broader group, set Administer / Manage permissions / Force push / Edit policies / Manage notes to Not set or Deny.
3. Leave Read at Allow only where required.
4. Re-run adoqr to confirm the ACE no longer carries elevated bits.

Microsoft Learn →

Secure files store signing certs, kubeconfigs, and other high-value artifacts. The scanner reads the Library namespace at Library/{projectId} (shared with variable groups) and flags any broad group with Administrator or User at the project-default.

Remediation steps

1. Open Pipelines > Library > Secure files > Security (project-default).
2. For each flagged broader group, set Administrator and User to Not set.
3. For high-value secure files, pin per-file roles instead of inheriting project-default.

Microsoft Learn →

Pipeline environments gate deployments to production targets. Broader groups should not hold User, Creator, or Administrator on any environment. This control currently surfaces as NOT CHECKED — per-environment ACL enumeration is tracked for Phase 2b.

Remediation steps

1. Open Pipelines > Environments.
2. For each environment, open the three-dot menu > Security.
3. Remove broader groups from Administrator, User, and Creator roles.
4. Combine with Approvals and Branch control checks so a misconfigured pipeline cannot deploy to production.

Microsoft Learn →

Restricts the build pipeline job authorization token to resources within the current project, preventing lateral movement across the organization if a pipeline is compromised.

Remediation steps

1. Navigate to Organization Settings (or Project Settings).
2. Open Settings under Pipelines.
3. Turn On the setting "Limit job authorization scope to current project for non-release pipelines".

Microsoft Learn →

Restricts the classic release pipeline job authorization token to the current project, containing the blast radius of a compromised release.

Remediation steps

1. Navigate to Organization Settings (or Project Settings).
2. Open Settings under Pipelines.
3. Turn On the setting "Limit job authorization scope to current project for release pipelines".

Microsoft Learn →

Requires YAML pipelines to explicitly declare the repositories they need, blocking implicit access to other repos in the organization.

Remediation steps

1. Navigate to Organization Settings (or Project Settings).
2. Open Settings under Pipelines.
3. Turn On the setting "Protect access to repositories in YAML pipelines".

Microsoft Learn →

Pipeline decorators and other auto-injected tasks run in every pipeline. They must come from a trusted source, be pinned to a known version, and be required by policy.

Remediation steps

1. Navigate to Organization Settings > Pipelines (and any extensions that auto-inject tasks).
2. List every task that is auto-injected into pipelines (decorators, pipeline policies, agent pre/post-jobs).
3. For each, confirm the task is published by a trusted source and required by policy.
4. Remove unused or unverified decorators.
5. Pin tasks to a specific version where the marketplace supports it.

Microsoft Learn →

Ensures the project visibility is set to Private so source code, work items, and pipeline data are not exposed to anonymous internet users.

Remediation steps

1. Navigate to Project Settings.
2. Click Overview.
3. Under Visibility, select Private.
4. Save.

Microsoft Learn →

Verifies that Project Administrators membership is limited to users with a current, documented business need, ideally via a Microsoft Entra group.

Remediation steps

1. Navigate to Project Settings > Permissions > Project Administrators.
2. Review every member; remove anyone without a documented business need.
3. Prefer adding a Microsoft Entra group rather than individual users.
4. Re-review on a recurring schedule (e.g. quarterly).

Microsoft Learn →

Verifies each Project Administrators group has 6 or fewer members, following least-privilege for project-level admin rights.

Remediation steps

1. Navigate to Project Settings > Permissions.
2. Select "Project Administrators".
3. Review the Members tab.
4. Remove unnecessary members to reduce to 6 or fewer.

Microsoft Learn →

Verifies each Project Administrators group has at least 2 members so the project has a backup administrator.

Remediation steps

1. Navigate to Project Settings > Permissions.
2. Select "Project Administrators".
3. Add at least one backup administrator.

Microsoft Learn →

Reviews the size of the Build Administrators group to ensure it has not grown unboundedly through historical assignments.

Remediation steps

1. Navigate to Project Settings > Permissions.
2. Select "Build Administrators".
3. Review and remove unnecessary members to keep count reasonable.

Microsoft Learn →

Detects guest (external) identities assigned to administrator groups — a high-risk pattern that should generally be avoided.

Remediation steps

1. Navigate to Organization Settings > Permissions (or Project Settings > Permissions).
2. Select the Administrators group.
3. Identify any guest users (look for #EXT# in email).
4. Remove guest users from administrator groups immediately.

Microsoft Learn →

Flags members of administrator groups who have not signed in recently — privileged accounts must be actively used and monitored.

Remediation steps

1. Navigate to Organization Settings > Permissions (or Project Settings > Permissions).
2. Select the Administrators group.
3. Review the Members tab for inactive users.
4. Remove inactive members who have not accessed the org in 90+ days.

Microsoft Learn →

Deployments to production environments should pass an artifact-evaluation check (signed artifact, expected build pipeline, etc.) before the gate releases.

Remediation steps

1. Navigate to Project > Pipelines > Environments > [environment] > Approvals and checks.
2. Add an "Evaluate artifact" check.
3. Define the policy (e.g. require a signed artifact, require a specific build pipeline as the source).
4. Test by attempting a deployment from a non-compliant artifact and confirm it is blocked.

Microsoft Learn →

Confirms repositories have secret scanning or credential scanning (GHAzDO push protection, CredScan, CodeQL) configured to catch leaked secrets before they are committed.

Remediation steps

1. Navigate to Project Settings > Repos > Repositories.
2. Select a repository.
3. Click Settings tab.
4. Enable "Push protection" under GitHub Advanced Security for Azure DevOps (GHAzDO).
5. Alternatively, add a credential scanning task (CredScan, CodeQL) to your build pipeline.

Microsoft Learn →

Enforces a repository policy that requires commits to come from an approved author email domain, blocking spoofed identities in Git history.

Remediation steps

1. Navigate to Project Settings > Repos > Repositories.
2. Select a repository (or All Repositories for project-wide).
3. Click the Policies tab.
4. Under Repository Policies, turn On "Commit author email validation".
5. Configure the author email pattern (e.g., *@yourcompany.com).

Microsoft Learn →

Identifies projects with no recent builds or commits (180+ days) that may no longer be needed.

Remediation steps

1. Navigate to Organization Settings > Projects.
2. Identify projects with no recent builds or commits (180+ days).
3. Contact project owners to confirm the project is still needed.
4. Disable or delete inactive projects.

Microsoft Learn →

Project-level check that anonymous access to pipeline status badges is disabled.

Remediation steps

1. Navigate to Project Settings.
2. Open Settings under Pipelines.
3. Turn On the setting "Disable anonymous access to badges".

Microsoft Learn →

Identifies classic release pipelines that have not run in 90+ days and may be candidates for retirement.

Remediation steps

1. Navigate to Project > Pipelines > Releases.
2. Identify release pipelines that have not run in 90+ days.
3. Delete or disable unused pipelines via the three dots menu.

Microsoft Learn →

Ensures classic release pipelines require human approval before deploying to production-like stages, providing a control gate against unauthorized changes.

Remediation steps

1. Navigate to Project > Pipelines > Releases.
2. Edit the release pipeline.
3. Click on the pre-deployment conditions icon (lightning bolt) on the production stage.
4. Enable Pre-deployment approvals.
5. Add at least one approver who is not the release creator.

Microsoft Learn →

Production environments should be guarded by a Branch control check that allows deployments only from the protected main branch.

Remediation steps

1. Navigate to Project > Pipelines > Environments > [production environment] > Approvals and checks.
2. Add a "Branch control" check.
3. Set Allowed branches to refs/heads/main (or your protected production branch).
4. Enable "Ensure protection of the branch" so the check fails if branch policies are not in place.
5. Validate that a deployment from a feature branch is blocked.

Microsoft Learn →

Flags classic release pipeline variables that can be overridden at release creation time, which is a parameter-injection risk.

Remediation steps

1. Open the release pipeline definition.
2. Go to Variables.
3. Review each variable marked as "Settable at release time".
4. Remove the settable flag from variables that should not be overridden.

Microsoft Learn →

Per-pipeline check ensuring each classic release pipeline's job authorization scope is set to "Current project" rather than the whole project collection — the release-side equivalent of BUILD-11.

Remediation steps

1. Open the release pipeline definition.
2. Click the three dots > Settings (Options for classic releases).
3. Set "Release job authorization scope" to "Current project".
4. Save the pipeline.
5. Repeat for every release pipeline flagged.

Microsoft Learn →

Identifies repositories with no commits in 180+ days that may be candidates for archival.

Remediation steps

1. Navigate to Project > Repos.
2. Identify repositories with no commits in 180+ days.
3. Archive or delete unused repositories.
4. Consider moving to a dedicated archive project.

Microsoft Learn →

Per-repo equivalent of PROJ-14. Confirms a credential / secret push-protection policy is actually enabled on each repo's default branch (rather than just existing somewhere in the project).

Remediation steps

1. Navigate to Project Settings > Repos > Repositories.
2. Select the flagged repository.
3. Open the Policies tab.
4. Enable "Push protection" via GitHub Advanced Security for Azure DevOps (GHAzDO) or add a credential-scanner branch policy targeting the default branch.
5. Confirm the policy is enabled (not just defined) and scoped to the default branch.

Microsoft Learn →

Per-repo equivalent of PROJ-15. Confirms the "Commit author email validation" branch policy is actually enabled on each repo's default branch.

Remediation steps

1. Navigate to Project Settings > Repos > Repositories.
2. Select the flagged repository.
3. Open the Policies tab.
4. Under Branch Policies for the default branch, turn On "Commit author email validation".
5. Configure the allowed email pattern (e.g. *@yourcompany.com).

Microsoft Learn →

Verifies Azure service connections authenticate using certificates or Workload Identity Federation rather than long-lived service principal secrets.

Remediation steps

1. Navigate to Project Settings > Service connections.
2. Select the service connection.
3. Click Edit.
4. Change authentication from secret to certificate-based or Workload Identity Federation.
5. Upload the certificate or configure federation.
6. Save.

Microsoft Learn →

Checks that Azure Resource Manager service connections are scoped to a Resource Group rather than an entire Subscription or Management Group.

Remediation steps

1. Navigate to Project Settings.
2. Open Service connections under Pipelines.
3. Select the Azure Resource Manager service connection.
4. Click Edit.
5. Change the Scope level from Subscription to a specific Resource Group.
6. Save the changes.

Microsoft Learn →

Service connections must be reviewed on a recurring cadence so unused / stale connections are disabled or removed.

Remediation steps

1. Navigate to Project Settings > Service connections.
2. For each service connection, click the three dots > Usage history.
3. Review which pipelines have used the connection recently.
4. Remove or disable any service connection that is no longer in use.
5. Schedule a recurring review (e.g. quarterly).

Microsoft Learn →

Flags legacy Azure Classic service connections that should be replaced with Azure Resource Manager (ARM) connections using modern authentication.

Remediation steps

1. Navigate to Project Settings.
2. Open Service connections under Pipelines.
3. Identify any Azure Classic service connections.
4. Delete the Azure Classic connection (three dots > Delete).
5. Create a new Azure Resource Manager service connection scoped to a resource group.

Microsoft Learn →

Promotes Workload Identity Federation (OIDC) or certificates over service principal client secrets on Azure service connections.

Remediation steps

1. Navigate to Project Settings > Service connections.
2. Select the service connection.
3. Click Edit.
4. Switch to Workload Identity Federation (recommended) or certificate authentication.
5. Save and verify pipeline access.

Microsoft Learn →

Verifies that service connections are not shared across multiple projects, limiting blast radius if one project is compromised.

Remediation steps

1. Navigate to Project Settings.
2. Open Service connections under Pipelines.
3. Select a service connection, click the three dots > Security.
4. Under Project permissions, ensure only the current project has access.
5. Remove any other projects that no longer require access.

Microsoft Learn →

Identifies user accounts that have not signed in for 90+ days and should be removed to reduce attack surface and license costs.

Remediation steps

1. Navigate to Organization Settings > Users.
2. Sort by Last Access Date.
3. Identify users inactive for 90+ days.
4. Remove or disable inactive accounts via the three dots > Remove.

Microsoft Learn →

Detects Azure DevOps users whose underlying Microsoft Entra accounts have been deleted or disabled but who remain provisioned in Azure DevOps.

Remediation steps

1. Run the assessment with -IncludeGraphCheck to auto-detect deleted/disabled users.
2. Navigate to Organization Settings > Users.
3. Cross-reference with Azure AD to find deleted or disabled accounts.
4. Remove any users whose AAD accounts no longer exist.

Microsoft Learn →

Identifies guest (B2B) accounts inactive for 90+ days that no longer need access and should be deprovisioned.

Remediation steps

1. Navigate to Organization Settings > Users.
2. Filter for guest users (#EXT#) and sort by Last Access Date.
3. Identify guest users inactive for 90+ days.
4. Remove inactive guest accounts via the three dots > Remove.

Microsoft Learn →

Verifies that variable groups containing secrets are scoped to specific pipelines rather than shared with every pipeline in the project.

Remediation steps

1. Navigate to Project > Pipelines > Library.
2. Select the variable group containing secrets.
3. Click Security (or the three dots > Security).
4. Under Pipeline permissions, click "Restrict Permission".
5. Add only the pipelines that need access.

Microsoft Learn →

Recommends linking pipeline variable groups to Azure Key Vault rather than storing secret values directly in Azure DevOps.

Remediation steps

1. Navigate to Project > Pipelines > Library.
2. Click + Variable group.
3. Enable "Link secrets from an Azure key vault".
4. Select the Azure subscription and Key Vault.
5. Choose the secrets to link.
6. Save the variable group.

Microsoft Learn →