Secure your Azure Boards

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Azure Boards provides multiple layers of security to protect your work tracking data, control access to sensitive information, and ensure compliance with organizational policies. This article outlines the security concepts, access controls, and best practices for securing your Azure Boards implementation.

Security model overview

Azure Boards security operates on a multi-layered approach that includes:

• Control identity and access management: Manage who can access your work items and what they can do. For more information, see About access levels
• Implement permission-based access: Apply fine-grained permissions for different work tracking operations. For more information, see Set work tracking permissions
• Configure area and iteration security: Restrict access to specific work items based on project areas. For more information, see Set area paths and assign to a team
• Manage work item types and field security: Control visibility and editability of work item fields. For more information, see Add and modify a field
• Enable audit and compliance: Track changes and maintain compliance requirements. For more information, see Access, export, and filter audit logs

Identity and access management

Access levels

Azure Boards uses access levels to control what features users can access. For comprehensive information about default permissions for each access level, see Default permissions and access levels for Azure Boards.

For more information, see About access levels.

Authentication

Azure Boards supports multiple authentication methods:

Permission model

Security groups

Azure Boards uses security groups to manage permissions efficiently. For more information about all available security groups and their permissions, see About permissions and security groups. For detailed guidance on configuring team administrators and their permissions, see Manage team administrators.

Work item permissions

Control access to work items through these key permissions. For step-by-step instructions on configuring these permissions, see Set work tracking permissions.

Area path security

Area paths provide hierarchical security boundaries:

Project Root
├── Team A (Restricted to Team A members)
├── Team B (Restricted to Team B members)
└── Shared Components (Accessible to all teams)

Configure area path permissions to:

• Restrict team access to specific work items
• Create secure workspaces for different departments
• Control visibility of sensitive projects

For detailed instructions on setting up area path permissions, see Set work tracking permissions.

Field-level security

Sensitive data protection

Protect sensitive information using these strategies:

• Create custom fields with restricted access that only specific groups can view or edit. For more information, see Add and modify a field
• Limit work item type restrictions to control who can create or modify certain work item types. For more information, see Customize a work item type
• Configure hidden fields to be invisible to certain user groups. For more information, see Add and modify a field
• Set read-only fields to prevent unauthorized modifications to critical data.

Compliance features

Best practices for Azure Boards security

Access management

• Apply least privilege principle: Grant minimum required permissions. For more information, see About permissions and security groups
• Conduct regular access reviews: Periodically audit user permissions and group memberships. For more information, see Export user list with access levels
• Use group-based management: Manage security groups instead of individual permissions. For more information, see About permissions and security groups
• Implement conditional access: Enable location and device-based access controls. For more information, see Manage conditional access

Work item security

• Design area path strategy: Create hierarchical structure that aligns with security requirements. For more information, see Set work tracking permissions
• Configure team isolation: Set up teams to access only their designated work items. For more information, see Add a team, move from one default team to several teams
• Implement field security: Restrict access to sensitive fields like budget or personal information. For more information, see Add and modify a field
• Control link security: Manage who can create dependencies between work items. For more information, see Link work items to objects

Data protection

• Handle sensitive information carefully: Avoid storing credentials or personal data in work items
• Manage file attachments: Implement policies for acceptable file types and sizes
• Validate external links: Approve external URL links in work items
• Secure query access: Ensure queries don't expose unauthorized data. For more information, see Set permissions for queries and query folders

Monitoring and compliance

• Monitor activity patterns: Track work item access patterns and unusual activities. For more information, see Access, export, and filter audit logs
• Audit change logs: Maintain logs of all work item modifications. For more information, see Query work item history and auditing
• Implement regular backups: Create backup strategies for critical work tracking data. For more information, see Data protection overview
• Establish incident response: Create procedures for security incidents involving work items. For more information, see Security best practices

Common security scenarios

Multi-team projects

When multiple teams work within a single project, it's essential to establish clear security boundaries to ensure teams can only access their relevant work items while maintaining collaboration where needed. Azure Boards uses area paths to create these security boundaries, allowing you to configure granular access control for different teams and organizational levels.

For guidance on setting up team administrators for each team, see Manage team administrators.

Example scenario: A software development project with specialized teams working on different components, plus management oversight:

Project: ProductDevelopment
├── Area: Frontend (Frontend team access)
├── Area: Backend (Backend team access)
├── Area: QA (QA team access)
└── Area: Management (Manager access only)

In this configuration:

• Frontend team members can view and edit work items only in the Frontend area
• Backend team members have access restricted to Backend work items
• QA team members can access QA-specific work items for testing coordination
• Managers have visibility into Management area items for strategic planning and reporting
• Cross-team dependencies can be managed through carefully configured shared areas or explicit permissions

This approach ensures that sensitive information remains restricted, so teams can focus on their specific responsibilities without distractions from unrelated work items.

Cross-project collaboration

Manage security when teams work across projects:

• Grant cross-project permissions: Provide specific access to external team members
• Control work item linking: Manage who can create dependencies across projects
• Manage shared queries: Control access to queries that span multiple projects. For detailed configuration steps, see Set permissions for queries and query folders

Contractor and vendor access

Secure access for external contributors. For comprehensive guidance on managing external users, see Add external users to your organization.

• Assign limited access levels: Configure appropriate access levels for external users
• Implement time-bound permissions: Create temporary access with expiration dates
• Restrict area access: Limit contractor access to specific project areas
• Audit external activity: Monitor all actions by external users

Security configuration checklist

Initial setup

• [ ] Configure appropriate access levels for all users
• [ ] Set up security groups aligned with organizational structure
• [ ] Design area path hierarchy based on security requirements
• [ ] Configure team permissions and access boundaries
• [ ] Set work tracking permissions for area paths and iterations
• [ ] Configure query folder permissions to control access to shared queries

Ongoing management

• [ ] Conduct regular permission audits and access reviews
• [ ] Monitor work item access patterns and anomalies
• [ ] Update security configurations as teams evolve
• [ ] Maintain documentation of security decisions and changes
• [ ] Review and update team administrator assignments as needed

Compliance preparation

• [ ] Document data handling procedures
• [ ] Implement audit log retention policies
• [ ] Configure export capabilities for compliance reporting
• [ ] Establish incident response procedures