When should organisations investigate Microsoft 365 application identities first?

Why Security Teams Should Investigate Application Identities First

When Microsoft 365 looks “healthy” at the user layer but data still leaks, consent grants keep appearing, or API calls do not match normal work patterns, application identities deserve first attention. A service principal can bypass the signal patterns that sign-in monitoring is built to catch, especially when consent, token issuance, or delegated permissions are the real control plane. That is why the question is less about which account is noisy and more about which workload is acting outside expectation. This is a classic NHI issue, not just an IAM issue.

The risk is amplified by poor visibility. NHI Mgmt Group research shows only 5.7% of organisations have full visibility into their service accounts, which means most teams are already searching with incomplete telemetry. That is where NIST Cybersecurity Framework 2.0 becomes useful: it pushes teams to connect identity, detection, and response instead of treating them as separate workstreams. In practice, many security teams discover application abuse only after a token has already been used to read mail, pull files, or grant persistence.

Two recent patterns illustrate why this matters. The Microsoft Midnight Blizzard breach showed how identity weakness can be operationally invisible until the investigation is well underway, while the JetBrains GitHub plugin token exposure demonstrated how secrets tied to software identities can become the real foothold rather than the user login.

How It Works in Practice

Investigation should start with the application identity when the pattern suggests service-level abuse rather than user compromise. That means reviewing enterprise apps, service principals, app registrations, delegated permissions, OAuth consent history, certificate or secret age, and token usage against workload purpose. The practical question is whether the application is acting within the intent it was granted, not simply whether a user signed in successfully.

Current guidance suggests a staged approach. First, verify whether the app has high-risk permissions such as mail read, directory read, offline access, or tenant-wide consent. Then check whether those permissions are justified by the app’s business function and whether any recent consent events were user-approved, admin-approved, or anomalous. Finally, correlate API activity with deployment events, change tickets, and known automation windows. This is where NIST Cybersecurity Framework 2.0 helps teams link detection and response, while the Microsoft Azure OpenAI service breach is a reminder that service-side trust decisions can be abused when identity governance is weak.

• Confirm whether the app uses long-lived client secrets, certificates, or managed identity.
• Review consent grants and the scope of delegated or application permissions.
• Compare API call patterns with the app’s intended function and deployment schedule.
• Validate whether privileged actions are controlled through PAM, RBAC, or JIT rather than standing access.

At minimum, teams should treat app identities as first-class assets: inventory them, classify them, rotate secrets, and remove unused permissions. If the app cannot explain its own access, it deserves immediate review. These controls tend to break down in large Microsoft 365 tenants with inherited admin delegation, shadow IT app registrations, or fragmented ownership because no single team can reliably prove who approved what and why.

Common Variations and Edge Cases

Tighter application identity review often increases operational overhead, requiring organisations to balance faster detection against slower change delivery. That tradeoff is real, especially in environments with heavy automation, SaaS integration sprawl, or legacy scripts that still depend on static secrets. There is no universal standard for this yet, but current practice is to prioritise applications that combine broad permissions, poor ownership, and evidence of recent anomalous access.

Edge cases matter. A benign integration can look suspicious if it runs only during batch windows, while a malicious app can hide inside a legitimate business process if consent was granted months earlier. Teams should also distinguish between app-only access and delegated access, because the remediation path differs: delegated grants may require user and admin review, while app-only abuse may require secret rotation, certificate replacement, or outright disablement. This is where NHI governance and incident response intersect.

For Microsoft 365, the strongest signal is often not a failed login but a successful token exchange followed by unusual mailbox, SharePoint, or Graph API activity. If the tenant lacks reliable app ownership records or consent auditing, the investigation should still start with the application identity because user-centric controls will miss the blast radius. In practice, many breaches become visible only after the service principal has already done the work, not when the human account first appears unusual.

Related resources from NHI Mgmt Group

• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?
• Should organisations track remediation speed or exposure reduction first?
• How should security teams govern consented Microsoft 365 applications?