Insights and Resources
Could a Cloud App Identity Delete Your Data and Backups?
Published 2026-09-28 by Joshua Smith · 7 min read
An attacker does not always need an employee's password to cause serious damage. Modern businesses also give identities to applications, scripts, integrations, and automated services. If one of those identities is compromised and has broad permissions, it may be able to inventory systems, retrieve credentials, delete production data, and interfere with recovery.
The practical answer: Inventory the non-human identities in your cloud environment, eliminate unnecessary access, replace long-lived secrets where possible, monitor their behavior, and protect backups with controls that the same identity cannot disable. The goal is not to stop automation. It is to make sure one compromised application account cannot take down production and recovery together.
What Microsoft Observed
On September 25, 2026, Microsoft published research about malicious activity in a compromised Azure environment. The attackers used two compromised service principals, which are identities used by applications or automated services rather than people. [1]
One identity performed reconnaissance. The other was used for discovery, destructive operations, and credential collection. Microsoft observed more than 150 attempted destructive or credential-related operations in 35 minutes. A seven-minute sequence included more than 100 attempts to delete storage accounts. Many of those storage accounts were successfully deleted. The attackers also deleted an Azure Key Vault, a Function App, and an App Service plan, while attempting to delete databases and interfere with recovery protections.
Microsoft did not report a ransom note or confirm that data was successfully stolen. The research describes one compromised environment, not a vulnerability that automatically exposes every Azure customer. The business lesson is broader: automation can move at machine speed, and application identities often have powerful access that is easy to overlook.
What Is a Cloud Application Identity?
Microsoft calls these accounts workload identities. They include service principals, managed identities, and other identities assigned to software. [2]
Consider an automated billing integration that exports data every night, a deployment tool that updates an application, or a backup process that connects to cloud storage. Each system needs permission to do its job. Instead of signing in as an employee, it uses its own identity.
That is useful and often necessary. It can also create three problems:
- The identity may have more permission than the application actually needs.
- Its secret or credential may remain valid for months or years.
- It cannot complete a normal multifactor authentication prompt like a person can.
An identity created for one narrow task can quietly accumulate access as systems change. If nobody reviews it, an old integration may retain the ability to read, change, or delete far more than anyone realizes.
How Could an Application Credential Be Exposed?
In the environment Microsoft investigated, a client ID, client secret, and tenant ID had previously appeared in a public GitHub issue. Microsoft could not confirm that this disclosure caused the compromise, but it emphasized an important rule: removing an exposed secret from a webpage or code repository does not make the secret safe again.
Copies may remain in edit histories, cached pages, logs, archives, screenshots, or cloned repositories. Any credential exposed publicly should be treated as compromised and revoked or rotated immediately.
Credentials can also leak through configuration files, support tickets, chat messages, shared documents, employee devices, or vendor systems. This is one reason a vendor security review should include questions about how outside developers and service providers handle cloud credentials.
Six Steps to Reduce the Risk
1. Inventory every non-human identity
Create a list of application registrations, service principals, managed identities, API keys, automation accounts, and vendor integrations. For each one, record:
- its business owner;
- the system or workflow it supports;
- the resources it can access;
- the credential type and expiration date;
- when it was last used; and
- who reviews it.
An identity without a known owner or current purpose should not retain access by default.
2. Revoke exposed credentials, do not merely hide them
If a secret appears in code, a public issue, a ticket, or another inappropriate location, revoke or rotate it immediately. Then review sign-in and activity logs from the period when it may have been exposed.
Editing the file or deleting the post is cleanup, not containment.
3. Reduce privileges and scope
Give an application only the permissions required for its defined task. Access to one storage account is safer than access to an entire subscription. Read access is safer than contributor access when the application does not need to make changes.
Pay particular attention to identities that can delete resources, change permissions, retrieve secrets, modify backup settings, or operate across multiple subscriptions.
4. Replace long-lived secrets where practical
Microsoft-managed identities and federated credentials can reduce the need to store reusable secrets in code or configuration files. The best choice depends on the application and where it runs, but the question is worth asking whenever a new integration is designed or an old one is reviewed.
If a stored secret is unavoidable, use an approved secret-management system, set an expiration, rotate it on a defined schedule, and alert before it expires.
5. Protect recovery from the same compromise
A backup is not enough if the same identity that can delete production can also disable or erase recovery.
Microsoft recommends controls such as immutable backup vaults, soft delete, multiuser authorization, separation of duties, and restricted access to backup resources. Some settings have operational and retention consequences, so they should be designed and tested rather than enabled casually. [4]
At minimum, confirm that:
- backup administration is separated from ordinary cloud administration;
- destructive backup changes require additional authorization;
- important recovery points cannot be immediately deleted;
- alerts reach someone outside the potentially compromised workflow; and
- a restore has been tested, not merely assumed.
Our small-business backup planning guide explains why cloud hosting and recoverability are not the same thing.
6. Monitor behavior, not just sign-ins
A valid identity can still behave maliciously. Watch for unusual resource enumeration, bulk deletion attempts, secret retrieval, access from unexpected locations, permission changes, and activity at unusual times.
The faster an automated attack can operate, the more important it is to have alerts tied to a clear response plan. Decide in advance who can disable an identity, rotate its credentials, preserve logs, and protect recovery systems during an incident.
Questions to Ask Your IT Provider or Cloud Team
Business leaders do not need to become Azure engineers, but they should expect clear answers to these questions:
- Do we have an inventory of application and automation identities?
- Which non-human identities can delete data or change backup protections?
- Are any long-lived secrets stored in code, documents, tickets, or scripts?
- Who reviews unused identities and excessive permissions?
- Could the compromise of one identity affect both production and recovery?
- When did we last test restoration after a destructive cloud event?
If the answers are unclear, start with an identity and recovery review. You do not need to rebuild the entire environment at once. Find the identities with the broadest access, protect the recovery path, and work down the list.
The Leadership Takeaway
Cloud automation is not the problem. Unmanaged authority is.
An application identity should have a specific owner, a specific purpose, limited permissions, a safe credential method, and visible activity. Backups should remain recoverable even when a production administrator or automated identity is compromised.
Those controls turn a powerful cloud identity from an invisible business risk into a managed part of your technology environment.
Want help reviewing cloud identities and recovery controls? Schilling IT can help identify high-risk access, document ownership, and test whether critical systems can be recovered after a destructive event. Schedule a security and resilience conversation.