Microsoft Storm-3168: Are Compromised Service Principals a Blind Spot in Your Azure Security?
Microsoft has disclosed cloud attacks involving compromised service principals, highlighting why organizations need to protect workload identities with the same discipline applied to privileged user accounts.
Executive Summary
Microsoft Security has documented activity associated with Storm-3168 in which compromised service principals were used during an attack against an Azure environment.
According to Microsoft's investigation, the attackers used compromised workload identities for cloud reconnaissance and destructive activity. Microsoft reported more than 100 storage-account deletion attempts during an approximately seven-minute destructive sequence.
The incident highlights an important cloud-security issue: organizations often closely monitor administrators and privileged user accounts while application identities, service principals, secrets and permissions can receive considerably less ongoing review.
What happened?
Microsoft published details of Storm-3168 activity on September 25, 2026. The investigation describes attackers operating inside an Azure environment using compromised service principals.
Microsoft observed the threat actor using two compromised service principals during the intrusion. The identities were used for activities including reconnaissance, credential collection and destructive operations.
What is a service principal?
In Microsoft Entra ID, a service principal represents an application's identity within a tenant. Applications, scripts, automation platforms and integrations can use these identities to authenticate and access permitted resources.
Service principals are part of the broader category of workload identities, which also includes managed identities.
They are essential to modern cloud environments, but they can become a security risk when permissions are excessive, credentials are poorly protected, ownership is unclear or old application identities remain active long after they are needed.
Why this matters
Non-human identities
Traditional identity-security processes frequently focus on employees and administrators. Workload identities can therefore receive less scrutiny.
Powerful permissions
A service principal may have access to Azure resources, APIs or business data. Excessive permissions increase the potential impact of compromise.
Long-lived credentials
Application secrets and certificates can remain active for long periods. Poor credential management can create persistent exposure.
Who should review their environment?
This issue is particularly relevant to organizations using Azure and Microsoft Entra ID with application integrations or automation.
- Organizations with numerous Entra ID application registrations.
- Businesses using Azure automation, scripts or API integrations.
- Environments with applications using Microsoft Graph or Azure APIs.
- Organizations using Power Platform and other automated workflows.
- Companies introducing AI agents that connect to cloud systems.
- Organizations that have accumulated applications from previous projects, vendors or administrators.
What should organizations check now?
Inventory service principals and applications
Identify enterprise applications, application registrations and workload identities currently present in the tenant. Determine which are actively used and which may be obsolete.
Review ownership
Every important application identity should have clear business and technical ownership. Investigate identities whose purpose or owner cannot be established.
Review permissions
Check Azure roles, Microsoft Graph permissions and other access granted to applications. Remove privileges that are no longer required and apply least-privilege principles.
Review secrets and credentials
Identify old, exposed or unnecessarily long-lived credentials. Rotate credentials where appropriate and avoid storing secrets insecurely in scripts, repositories or configuration files.
Investigate workload-identity activity
Review sign-in and audit information for unexpected application activity, unusual access patterns or operations inconsistent with the application's normal purpose.
Protect recovery and critical resources
Review safeguards around critical Azure resources, backups and recovery capabilities so that compromise of an identity does not automatically translate into irreversible business impact.
NOAVAXIS Recommendation
Organizations should treat workload identities as part of their core identity security program rather than as configuration objects that are reviewed only when an application is deployed.
A practical governance process should answer four simple questions: What is this identity for? Who owns it? What can it access? Does it still need that access?
Those questions should be revisited regularly because cloud environments change. Applications are replaced, projects end, administrators leave and integrations accumulate permissions over time.
From one-time review to continuous governance
The broader lesson from Storm-3168 is not simply that service principals can be compromised. It is that non-human identities have become part of the modern enterprise attack surface.
As businesses introduce more automation, APIs and AI agents, the number of machine identities is likely to grow. Identity governance therefore needs to cover both people and workloads.
Need visibility into your Microsoft cloud identities?
NOAVAXIS TECHNOLOGY helps organizations identify security risks across Microsoft cloud environments, prioritize remediation and establish practical ongoing governance.
We can help review application identities, service principals, permissions, credentials and related Microsoft Entra and Azure security controls as part of a broader risk and efficiency review.
Talk to an ExpertOfficial Sources
Microsoft Security Blog
Storm-3168: Agentic-driven cloud attacks using compromised service principals
Microsoft Learn
Workload identities in Microsoft Entra