Skip to main content
Azure DevOps integration lets Blitzy access your repositories to analyze code, create branches, push commits, and manage pull requests. Blitzy authenticates through a Microsoft Entra ID (formerly Azure AD) application using a dedicated service identity user in your ADO organization. This guide walks an ADO administrator through the complete process of granting Blitzy controlled access to your source control repositories.
Jump to: Prerequisites | Permissions | Setup | Repository Permissions | Connect App | Verification

​
Prerequisites

Never use a personal employee account for service integrations. Always create a dedicated service identity so that access is not disrupted by employee departures or password changes, and so that audit logs clearly identify vendor activity.

​
Permissions

Blitzy requires the following Azure DevOps permissions, scoped to the minimum level needed.
The Blitzy Azure AD app requests broad permission scopes during installation. However, actual access is controlled entirely by the “Blitzy Service Access” custom security group you configure in ADO. The app can only perform actions that this group explicitly allows - regardless of what the OAuth consent screen lists.

​
Create the Service Identity User

Create a dedicated user account in Microsoft Entra ID for the Blitzy integration. This is a non-interactive account - it does not represent a real person.
1

Navigate to Entra ID User Management

Sign in to the Microsoft Entra admin center at https://entra.microsoft.com. Expand Identity, then select Users > All users. Click + New user > Create new user.
2

Configure the service user properties

In the Basics tab, fill in the following fields:Under Properties (optional), set the Department to “Service Accounts” and the Job title to “Third-Party Integration - Blitzy” for easy identification.
3

Create the user

Click Review + create, then click Create.
Consider disabling MFA for this service account, as Blitzy authenticates programmatically. Use Conditional Access policies to exclude this specific account. If your organization requires MFA for all accounts, work with Blitzy to use a service principal with certificate-based authentication instead.
Ensure that this service account password does not expire (or is updated regularly before expiry per your organizational policy).

​
Add the Service User to Azure DevOps

1

Open organization user settings

Sign in to your Azure DevOps organization at https://dev.azure.com/{YourOrganization}. Click Organization settings (gear icon at the bottom-left), then Users under General.
2

Add the service user

Click Add users. In the Users or Service Principals field, enter [email protected] and select the account when it appears.
3

Set access level

Set Access level to Basic. Basic is required for Code/Repos access - Stakeholder access does not include source control permissions for private projects.
4

Select projects

Under Add to projects, select only the project(s) that contain the repositories Blitzy needs to access. Do not select all projects.
5

Set initial group and confirm

Set Azure DevOps Groups to Project Contributors for now. Click Add to finalize. You will restrict this further in the next section using a custom security group.
Adding the user to the Contributors group provides broad code access across all repos in the project by default. The next section shows how to create a custom group with restricted permissions and remove the user from Contributors.

​
Create a Custom Security Group

To enforce the principle of least privilege, create a custom security group that grants Blitzy only the specific permissions needed.
1

Create the group

Navigate to Project settings > Permissions. Click + New Group. Set the name to Blitzy Service Access and description to Custom security group for Blitzy third-party vendor. Add [email protected] as a member. Click Create.
2

Remove the service user from Contributors

On the Permissions page, click the Contributors group, then the Members tab. Locate [email protected] and click Remove.
After this step, the service user’s only project-level membership is the custom “Blitzy Service Access” group. All repository and branch permissions are configured through this group.

​
Configure Repository-Level Permissions

Restrict Blitzy to specific repositories by denying access at the top level, then explicitly allowing access on individual repos.

​
Deny Access to All Repositories (Default)

  1. Navigate to Project settings > Repos > Repositories.
  2. Click the top-level Git repositories node.
  3. Click the Security tab.
  4. Click + Add and find the “Blitzy Service Access” group.
  5. Set all permissions to Deny. Click Save changes.

​
Allow Access on Specific Repositories

For each repository Blitzy should access, explicitly override the Deny with Allow.
  1. Click the specific repository (e.g., “frontend-app”).
  2. Click the Security tab, then find or add the “Blitzy Service Access” group.
  3. Set permissions:
  1. Click Save changes. Repeat for each additional repository.
Keep a record of which repos you grant access to. A simple spreadsheet or wiki page in ADO makes audits and access reviews easier.

​
Branch-Level Security and Policies

Azure DevOps lets you set permissions on individual branches to control which branches Blitzy can push to, create pull requests against, or read.Open branch security settings:
  1. Navigate to Repos > Branches within the target project.
  2. Locate the branch (e.g., main), click … (More actions) > Branch security.
Add the Blitzy group and set permissions:
  1. In the Branch security panel, click + Add.
  2. Search for and select the “Blitzy Service Access” group.
  3. For protected branches like main, set Contribute to Deny. For working branches like develop, set Contribute to Allow.
  4. Click Save.
Branch permissions override repository-level permissions. If Blitzy has “Contribute = Allow” at the repo level but “Contribute = Deny” on main, it can push to other branches but not main. This is the desired outcome.
Recommended branching strategy:
Branch policies enforce code review and build validation even if Blitzy has Contribute permissions on a branch.
  1. Navigate to Project settings > Repos > Repositories > select the target repository.
  2. Click the Policies tab, then select the branch (e.g., main).
  3. Enable the following recommended policies:
    • Require a minimum number of reviewers - Set to at least 1 reviewer
    • Check for linked work items - Optional but recommended for traceability
    • Check for comment resolution - Require all comments resolved before merge
    • Build validation - Add a build pipeline that must succeed before PR completion
    • Automatically included reviewers - Add your team lead as an auto-reviewer for PRs
  4. Click Save.
Never grant Blitzy the “Bypass policies when completing pull requests” or “Bypass policies when pushing” permissions. These would allow the vendor to skip code reviews and CI checks.

​
Connect the Blitzy ADO Integration App

Blitzy’s Azure AD app uses OAuth to authenticate. Ensure third-party application access is enabled in your ADO organization settings.
1

Verify OAuth settings

Navigate to Organization settings > Policies (under Security). Locate the Third-party application access via OAuth policy and ensure the toggle is set to On.
2

Install the Blitzy Azure AD application

Follow the guidance in the Blitzy platform to set up the ADO integration. Use the service identity account [email protected] to connect.
3

Share the integration

In the Blitzy platform, Share the ADO integration with your Blitzy teams.
If your organization uses Conditional Access policies that block third-party OAuth by default, enabling the ADO toggle alone is not sufficient. You must also create a Conditional Access exclusion for the service identity account targeting the app registration.

​
Verification and Testing

After completing the configuration, verify that the setup works correctly and that permissions are properly restricted.
Test pull request creation:
  1. Create a pull request from a permitted branch to main.
  2. Confirm the PR is created successfully.
  3. Verify that branch policies (required reviewers, build validation) are enforced.
Test the Blitzy integration:
  1. Log in to the Blitzy platform.
  2. Create a test project.
  3. Ensure that this project can only see the allowed repos and branches.
Document the test results and keep them as part of your compliance records. This is especially useful during security audits.

​
Ongoing Maintenance

  • Quarterly reviews - Review Blitzy’s access level, repository permissions, and branch permissions every quarter
  • Last access date - Check the Users page in Organization settings to see when the service user last accessed ADO
  • Audit logs - Review ADO audit logs regularly (Organization settings > Auditing)

​
Offboarding Blitzy

1

Revoke ADO access

Remove the service user from all projects. Delete the “Blitzy Service Access” security group.
2

Disable the identity

Delete or disable the Entra ID user account ([email protected]).
3

Remove the app

Uninstall the Blitzy Azure AD app. Contact Blitzy support to remove the ADO integration from the Blitzy platform.
4

Document

Record the offboarding in your change management system.

​
Troubleshooting

Ensure the Entra ID tenant is connected to the ADO organization (Org settings > Microsoft Entra). The user must exist in the same tenant.
Confirm that the user is the service identity user, not your personal account.
The repository permission is set to Deny. Check if the correct repo has Allow set on Read for the Blitzy group.
Check branch-level security. The Blitzy group may have Contribute = Deny or Not set on that branch.
Branch policies may be blocking. Ensure that reviewers have approved, builds pass, and comments are resolved.
ADO caches permissions. Wait a few minutes, clear browser cache, or sign out and back in.

​
Security Checklist

  • Dedicated service identity user created in Entra ID (not a personal account)
  • Service user added to ADO with Basic access level
  • Custom “Blitzy Service Access” security group created
  • Service user removed from default Contributors group
  • All repositories set to Deny at the top-level for the custom group
  • Only authorized repositories have explicit Allow permissions
  • Branch-level security configured: protected branches deny push access (optional)
  • Branch policies enabled - required reviewers, build validation (optional)
  • Third-party OAuth access enabled in Organization policies (if required)
  • Clone, push, and PR tests passed for both allowed and denied repos/branches
  • Access review schedule established (quarterly)
  • Offboarding procedure documented