Detect new service principals by monitoring Azure and Microsoft Entra directory activity for application or enterprise application creation. Alert on unexpected registrations or service principals created outside approved automation. Investigate the creator, tenant context, and any immediate role assignments or credential additions, because attackers may create service principals to establish persistent cloud access.
What to watch in Azure and Microsoft Entra telemetry
New service principals usually appear as application registrations or enterprise applications, so the detection problem is really directory activity monitoring, not just sign-in monitoring. The highest-value signal is a creation event that is out of pattern for your tenant, such as an app created by a user who does not normally provision applications, or created outside an approved automation path. Tie that event to the creator and the tenant context first, then evaluate whether the object immediately gained roles, permissions, or credentials.
For a broader control baseline on Azure and Entra roles, scopes, and service principal hygiene, use the Azure RBAC and Service Principals Guide. It helps you distinguish ordinary administrative activity from role assignment patterns that deserve an alert.
Creation alone is not always malicious. Many environments rely on CI/CD, managed integrations, or provisioning workflows that legitimately create service principals at scale, so your detection logic should reduce noise by allowing known automation identities and known change windows. The useful question is whether the new object was expected, whether it has a documented owner, and whether its permissions match the declared use case.
To understand the full lifecycle of workload credentials behind the object, the Cloud Workload Identity Guide is a strong companion because it covers how Azure service principals fit into the wider workload identity model and why keyless patterns reduce long-lived exposure.
How attackers abuse newly created service principals
Attackers create service principals to turn directory access into durable cloud access. A newly created principal can become the foothold for app-only Graph access, privileged role assignment, or secret and certificate attachment, which then survives password resets on user accounts. That makes the creation event itself an early indicator of persistence, especially when it is followed quickly by credential material being added.
The best-known abuse pattern is not the creation event by itself, but the sequence after it: create the object, add a secret or certificate, grant API permissions, and then use it quietly. That is why monitoring should correlate app creation with immediate changes to credentials, consent, and role bindings. If you only watch for sign-in anomalies, you can miss the setup phase entirely.
For the identity and privilege side of that sequence, Service Account Security Guide gives a useful control lens on ownership, least privilege, and lifecycle governance for non-human identities. It is especially helpful when investigating whether the new object is a legitimate integration or an overprivileged foothold.
When adversaries want cloud persistence, they often prefer identities that are not tied to an interactive user session. A service principal can be recreated, renamed, or blended into automation noise, so the practical defence is to treat creation plus privilege gain as the suspicious combination, not creation alone. That distinction matters because many malicious tenants never need to log in as a human account again once the principal exists.
Building a detection that is actually usable
Good detection needs three layers: baseline, enrichment, and triage. Baseline tells you which applications and enterprise applications are normal for each tenant or subscription. Enrichment adds the creator, the source IP, the application owner, the consent or role grant that followed, and whether a credential was attached. Triage then asks a simple question: does this object fit the tenant’s approved automation pattern, or does it create new access without a matching business change?
Alerting should be tuned to the point where an analyst can answer, in one pass, who created the service principal, why it exists, and what it can now reach. If the answer requires hunting across several consoles, the detection is too weak. Good alert content should also tell you whether the object is new, whether it was created by an admin, and whether it now has access that exceeds the norm for similar integrations.
If your incident workflow needs a response pattern for suspicious cloud identity changes, the Cloud Credential Compromise Playbook is directly useful because it aligns investigation, containment, and rotation around the same kind of credentialed cloud access this detection is meant to surface.
A separate operational lesson is that service principal detection becomes much stronger when paired with permission-review workflows. New objects should not only trigger an alert, they should also trigger a review of ownership, granted API scopes, and whether the object has been left with excessive standing privilege. That is where many otherwise legitimate apps become risky.
Risk and Threat Considerations
New service principals are a persistence and privilege risk because they can be created quietly, granted powerful access, and left behind even after the original compromise path is closed. In Azure tenants with broad admin rights or weak change control, an attacker can use this to establish durable cloud access that is harder to spot than a compromised user account.
Failure mechanism: The attacker creates or modifies an application object, attaches credentials or consent, and then uses application permissions or role assignments to operate without relying on the original user session.
Impact: This can produce silent tenant persistence, unauthorized data access, mailbox or directory abuse, and delayed detection because the access appears to come from an apparently valid application identity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | Service principal creation and credential addition are persistence-oriented account changes. |
| Recommendation — Monitor for new cloud identities and follow-on permission or credential changes. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Detecting new service principals depends on reviewing directory audit events and correlating follow-on changes. |
| AC-6 — Least Privilege | Unexpected service principals become dangerous when they are granted excessive standing access. | |
| IA-5 — Authenticator Management | New principals often become risky when secrets or certificates are added after creation. | |
| Recommendation — Correlate directory audit events with permission and credential changes. Restrict service principal privileges to the minimum required scope. Track and rotate credentials attached to newly created principals. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | Directory activity monitoring is the core detection mechanism for newly created principals. |
| Recommendation — Extend monitoring to Entra directory events and alert on anomalous object creation. | ||
Practitioner Guidance
What to verify: For every new service principal alert, verify who created it, which automation or change request it maps to, and whether a secret, certificate, or role assignment appeared shortly after creation. If those links are missing, treat the object as suspicious until proven otherwise.
Decision rule: If the service principal has any standing privilege beyond a tightly scoped automation use case, prioritise containment and permission review before normalising the event as routine provisioning. If it is legitimate, record the owner and expected permission footprint so the same pattern can be recognised later.
Practitioner takeaway: The real detection target is not “a service principal exists”, it is “a new cloud identity appeared and immediately became capable of persistent access.”