Skip to content

Latest commit

 

History

History
80 lines (57 loc) · 6.71 KB

File metadata and controls

80 lines (57 loc) · 6.71 KB
title Change application connection and security policies for organizations
titleSuffix Azure DevOps Services
description Manage security policies for accessing organization through Conditional Access, OAuth, SSH, and personal access tokens (PATs).
ms.subservice azure-devops-organizations
ms.assetid 2fdfbfe2-b9b2-4d61-ad3e-45f11953ef3e
ms.topic how-to
ms.author chcomley
author chcomley
ms.date 10/10/2025
monikerRange azure-devops

Change application connection & security policies for your organization

[!INCLUDE alt-creds-deprecation-notice]

This article shows how to manage your organization's security policies that determine how users and applications can access services and resources in your organization. You can access most of these policies in Organization settings.

Prerequisites

Category Requirements
Permissions

[!INCLUDE manage-policies]

Restrict authentication methods

To allow seamless access to your organization without repeatedly prompting for user credentials, applications can use authentication methods, like OAuth, SSH, and personal access token (PATs). By default, all existing organizations allow access for all authentication methods.

You can limit access to these authentication methods by disabling the following application connection policies:

When you deny access to an authentication method, no application can access your organization through that method. Any application that previously had access encounter authentication errors and lose access.

Conditional Access policy support on Azure DevOps

Conditional Access (CA) in Azure DevOps is enforced through Microsoft Entra ID and supports both interactive (web) and non-interactive (client credential) flows, validating policies like MFA, IP restrictions, and device compliance during sign-in and periodically via token checks.

SSH key policies

SSH authentication

The SSH authentication policy controls whether or not an organization allows the use of SSH keys.

Validate SSH key expiration

To avoid losing access due to an expired SSH key, create and upload a new key before the current one expires. The system sends automated notifications 7 days before expiration and again after expiration to help you stay ahead. For more information, see Step 1: Create your SSH keys.

The Validate SSH key expiration policy is enabled by default. When active, it enforces the expiration date—expired keys immediately become invalid.

If you disable the policy, the system no longer checks expiration dates, and expired keys remain usable.

Policies by Level

| Policy | Org-level | Tenant-level | |--------------|-------------| | Third-party application access via OAuth | ✅ | | | SSH authentication | ✅ | | | Validate SSH key expiration | ✅ | | | Log audit events | ✅ | | | Restrict personal access token creation | ✅ | | | Allow public projects | ✅ | | | Additional protections when using public package registries | ✅ | | | Enable IP Conditional Access policy validation on non-interactive flows | ✅ | | | External guest access | ✅ | | | Allow team and project administrators to invite new users | ✅ | | | Request access allows users to request access to the organization with a provided internal URL | ✅ | | | Allow Microsoft to collect feedback from users | ✅ | | | Restrict organization creation | | ✅ | | Restrict global personal access token creation | | ✅ | | Restrict full-scoped personal access token creation| | ✅ | | Enforce maximum personal access token lifespan | | ✅ |