14 ways to lose Azure DevOps data

Azure Devops is a popular CI/CD platform utilized by software development teams. The core use includes source code hosting, CI/CD, project management, test managements and dependency management. Given the extensive capabilities of Azure DevOps, the attack vector for cyber criminals is also bigger – putting more pressure on securing sensitive data.

With the growth of sophisticated cyber attacks – cyber security must also be re-evaluated and properly addressed. Therefore, in this article we will outline 14 potential ways in which Azure DevOps data can be lost and how these risks can be mitigated.

#1 Accidental deletion of projects

Human error remains the leading cause of data loss. Users can accidentally delete: entire projects, git repositories, pipelines with their histories, artifacts or even test plans and board data – this could lead to irreversible damages. Azure DevOps offers limited retention for deleted data, but does not provide point-in-time restore. 

Permissions amplify risks further, as weak access controls lead to a broader blast radius during a security incident. Examples range from offboarding employees and reorganizing teams to pre-migration cleanups and removing “useless” data – though the scope is broad in this regard.

Avoid accidental deletion:

The main aspects of mitigating the risks of accidental deletion are enforcing the principle of least privilege, role-based access controls, limiting the amount of project admins, and off-site backups.

#2 Vulnerable credentials

Azure DevOps is a platform that does not rely on passwords but rather on credentials such as: Personal Access Tokens (PATs), Service Connections (Azure, AWS, GCP, Kubernetes, etc), OAuth app tokens, SSH keys. A leaked Azure DevOps token grants attackers the same level of access as the compromised user.

The reasons behind exposed credentials:

• PATs can be hardcoded into repos or scripts
• Long-lived tokens with no rotation or proper revoking procedures 
• Tokens stored in shared documents or CI/CD variables without masking
• Token scope too broad 

How to ensure the security of credentials:

• Enforce MFA
• Prioritize managed identities 
• Leverage Entra ID
• Use short-lived PATs
• Rotate tokens often and regularly 
• Minimize permissions 
• Revoke when unused 

#3 Data overwritten during force push

While Azure Repos uses git and git allows history to be rewritten using force push – this poses a threat. Why could this be dangerous in Azure Repos? Well, force push is enabled by default so it can result in lost commits and collaboration work.

Mitigate data loss caused by force push:

• Block force push in permissions
• Implement proper branch policies
• Third-party backup with point-in-time restore
• Limit pushing to shared branches 

#4 Insider threats

Any user authorized to access secrets, stop delivery, modify pipelines or delete data is considered an insider threat. Whether accidental or intentional – does not matter. A single account with excessive permissions in the wrong hands is enough for irreversible data loss.

Take a look at what insiders can damage in Azure DevOps:

• Delete repositories
• Modify or disable pipelines
• Leak secrets from variable groups
• Remove artifacts and build history
• Change branch policies
• Lock teams out of projects

Be prepared for insider threats. Automate off-boarding, require SSO and MFA, keep off-site backups, clearly separate duties and enforce the principle of least privilege.

#5 Data loss beyond source code 

Apart from code, Azure DevOps also holds critical metadata, like configurations, Boards data, build and release artifacts, test cases and results along with logs. Losing access to such data may negatively impact compliance as well as business continuity. 

During project migrations, reorganizations, API-driven automation, or large-scale restructures, metadata can turn out to be incomplete, desynchronized, or even permanently lost. Scenarios include partial imports, broken links between repos and pipelines, missing build history, or lost work item relationships.

Be sure to set retention policies, guarantee backups with sufficient coverage, limit automation that modifies at scale and implement flexible, tested recovery.

#6 Ransomware attacks 

Cyber criminals often abuse trusted paths such as exposed credentials to launch ransomware attacks. Once a threat actor gains access, they can encrypt, delete, overwrite and corrupt your Azure DevOps data, including: 

• Azure Repos git repositories (malicious commits, forced rewrites)
• Pipeline definitions and run data (poisoned builds, erased history)
• Build and release artifacts (overwritten binaries)
• Variable groups and secrets (exfiltrated credentials, leaked tokens, compromised deploy keys)
• Service Connections (abuse of Azure, AWS, or GCP, access to encrypt or destroy infrastructure)
• Project configuration and metadata (pipelines disabled, permissions altered, projects deleted)

Prevent ransomware attacks:

As the party responsible for protecting accounts, access, authorization, and data, the customer must enforce strict identity and permission controls, secure execution environments, and immutable, off-site backups. In Azure DevOps, ransomware prevention focuses on controlling trusted access paths, not infrastructure components managed by Microsoft.

👉 Make sure to explore these 30 cybersecurity statistics to be prepared for 2026 with the latest trends.

#7 No backup or disaster recovery

Backup and disaster recovery are foundational to protecting DevOps data. In the case of Azure DevOps, this responsibility does not sit with Microsoft at the data level. While the platform ensures service availability, customers are solely responsible for preserving and recovering their own data.

Native backup in Azure DevOps Server is based entirely on regular SQL Server database backups and is designed to protect the data layer, not the application or client machines. Microsoft provides a Scheduled Backup Wizard that helps administrators back up all Azure DevOps Server databases. These SQL backups contain all information required to restore an Azure DevOps Server deployment, whether to the same server or to new hardware, depending on the recovery scenario.

In short, the native approach is database-centric, manual/administrator-driven, and infrastructure-dependent, offering basic disaster recovery but no point-in-time restore granularity, cross-service awareness, or SaaS-style automation.

👉 Azure DevOps backup best practices
👉 Azure DevOps disaster recovery best practices

To ensure recoverability and protect Azure DevOps data against deletion, corruption, or malicious activity, a backup and disaster recovery approach must provide:

• Immutable, off-site, WORM-compliant storage 
• Geo-redundancy, replication
• Data residency of choice 
• Automated backup
• Scheduling with different, customizable plans
• Full coverage with all critical metadata
• Encryption at rest and in transit 
• 3-2-1 backup rule 
• Unlimited retention
• Compliance with industry regulations like SOC 2 Type II or ISO 27001
• Flexible recovery with point-in-time restore, full data recovery and data migration between platforms (for example from Azure DevOps to GitLab)

For complete, professional protection opt for solutions encompassing the above mentioned functionalities. Backup and recovery vendors like GitProtect automate backup processes, simplify recovery, keep your data safe and support compliance efforts. By covering the aspects mentioned above, GitProtect supports the security of your Azure DevOps and you get peace of mind that all backup copies are safe.

#8 Single Owner issue

In Azure DevOps, a small number of privileged roles – primarily Organization Owners and Project Administrators – control access to repositories, pipelines, permissions, and project settings. When these roles are assigned to a single individual, that person becomes a single point of failure for the entire delivery process.

If the only owner or admin loses access, leaves the organization, is unavailable during an incident, or has their account compromised, teams may be unable to merge code, modify branch policies, fix broken pipelines, rotate credentials, or respond to security events. Even when data still exists, operations can come to a complete stop due to lack of administrative control.

How to mitigate the single owner bottleneck:

• Assign at least two Organization Owners
• Ensure multiple Project Administrators for critical projects
• Avoid shared admin accounts; use named identities
• Enforce SSO and MFA for privileged users
• Document administrative procedures
• Review and validate admin access regularly

#9 Service disruptions

Within Azure DevOps availability depends entirely on Microsoft-operated services. While outages may be temporary, their impact on customer data and operations is not always reversible. When Azure DevOps experiences service degradation or downtime, access to repositories, pipelines, artifacts, boards, and APIs can be partially or completely unavailable.

To reduce the impact of service disruptions:

• Maintain independent, off-site backups of Azure DevOps data
• Avoid relying on pipelines or APIs as the only export mechanism
• Monitor Azure DevOps service health and pipeline failures
• Back up data before major changes, upgrades, or migrations
• Prepare incident response procedures for DevOps outages

#10 Pipeline failures / API limits

Pipelines in Azure DevOps can fail due to misconfigured YAML, missing or rotated secrets, agent issues, or service connection errors. Azure DevOps APIs are rate-limited and throttled, which can cause pipelines or automation to stop mid-run, resulting in missing artifacts, logs, or outputs.

Mitigation:

• Validate pipeline changes before production
• Monitor pipeline failures and API throttling
• Don’t use pipelines as the only export/backup path
• Add retries and output checks
• Keep independent backups outside CI/CD

#11 Insecure pipelines & agents

Azure DevOps pipelines have direct access to code, secrets, artifacts, and service connections. If jobs or agents are left too permissive or poorly set up, they become a ready execution path into your environment. Self-hosted agents especially run on machines you control and often have broader access than necessary – including sensitive folders, credentials, and networks. If someone abuses a pipeline or compromises an agent, they can leak secrets, push malicious code, overwrite build outputs, or use service connections to reach other systems. Best practice is to run agents with the least privilege possible and separate sensitive build pools from general jobs.

How this should be addressed:

• Restrict pipeline permissions and triggers to trusted roles and branches
• Use Microsoft-hosted agents where practical, or harden and isolate self-hosted agents
• Separate build, deploy, and infra credentials
• Review pipeline changes like code

#12 Mirrors & repo divergence

Repositories are often mirrored or synchronized with external systems such as GitHub, other Azure DevOps organizations, or on-prem Git servers. When these mirrors fall out of sync, teams may work on outdated or incomplete code without realizing it. Failed sync jobs, expired tokens, broken automation, or silent API errors can cause repositories to drift over time. 

Once divergence occurs, later merges or forced updates can overwrite valid commits, remove history, or introduce inconsistencies between environments. In these situations, data loss happens at the moment when someone assumes the mirror is up to date and acts on it.

Mitigate these risks:

• Monitor mirror and sync jobs for failures
• Rotate and audit credentials used for repository synchronization
• Validate repository state before overwrites or merges
• Avoid force pushes on mirrored branches
• Maintain independent backups to recover overwritten history

#13 Public projects & exposure

Repositories and projects can be changed to public, and any data pushed to a public repo becomes instantly accessible and is actively scanned by bots. A single leaked token, key, or config file is enough to expose internal systems. Even if the commit is reverted, the secret remains in Git history and may already be cloned, cached, or indexed externally. Once sensitive data is pushed to a public Azure DevOps repository, it should be considered permanently compromised.

How this should be addressed:

• Restrict who can change project visibility
• Scan repositories for secrets
• Block commits containing credentials
• Rotate any secret exposed publicly

#14 Entra ID changes causing data lock-out

Azure DevOps data can be effectively locked out – without being deleted – due to changes in Azure AD / Entra ID. If Azure DevOps is disconnected from its Entra ID tenant, conditional access policies become too restrictive, user UPNs are changed, or service principals are removed, users and pipelines can lose access instantly. While repositories, work items, and metadata remain intact, broken identity mappings prevent authentication, resulting in 401/403 errors and halted deployments. In practice, the data still exists, but the “keys” live in Entra ID – and changing them without preparation can cut off all access to the environment.

👉 For more in regards to Azure DevOps data security, check out Azure DevOps security best practices