How should security teams detect phishing that comes from legitimate Microsoft identity workflows?

Why This Matters for Security Teams

Identity workflow phishing is dangerous because it borrows trust from a legitimate Microsoft service path instead of spoofing a random sender. Messages that come from SharePoint, Entra, Teams, or other Microsoft identity workflows can still carry malicious intent, which means SPF, DKIM, and DMARC often do not give defenders the signal they expect. Current guidance suggests treating the notification context as the primary detection surface, not the sender envelope alone, and mapping this to broader identity risk patterns discussed in the Ultimate Guide to NHIs and the 52 NHI Breaches Analysis. That matters because the abuse is often socially engineered through an authentic platform workflow, not through compromised mail authentication alone. Security teams also need to align this with broader detection planning in the NIST Cybersecurity Framework 2.0, especially where user notification, response, and detection are split across different teams. In practice, many security teams encounter the phish only after a user has followed the callback number or external link, rather than through intentional monitoring of the workflow itself.

How It Works in Practice

Detection works best when teams analyze the message as an identity event, not as ordinary email. A legitimate Microsoft workflow can be abused to send prompts that look like account verification, file access requests, shared document alerts, or compliance notifications. The malicious content usually hides in the body language of the message, such as urgency, a request to call a number, or subtle Unicode obfuscation that changes the visible brand or domain. Teams should build detections around the full message context, including tenant metadata, app registration source, callback destinations, and whether the workflow aligns with the user’s normal business activity. A practical detection stack usually includes:

• Rules for anomalous branding changes, logo substitutions, and unexpected Microsoft tenant identifiers.
• Parsing callback numbers, short links, and off-platform contact requests from the message body.
• Monitoring for unusual Microsoft identity workflow triggers, especially in apps that should not generate external outreach.
• Correlation with identity logs to see whether the notification came from a real tenant, a real app, and a normal user journey.
• Behavior-based scoring that weighs language patterns, urgency cues, and Unicode tricks over sender reputation.

The goal is to detect abuse where the platform is authentic but the workflow is not. That is consistent with the NHI risk model in Ultimate Guide to NHIs — Key Challenges and Risks, where visibility gaps and over-privilege make legitimate automation harder to trust. For response teams, the operational question is whether the notification originated from a sanctioned workflow, a sanctioned tenant, and a sanctioned business purpose, not just whether the email was signed. These controls tend to break down in large Microsoft 365 environments with many delegated apps and third-party connectors because the volume of legitimate workflow noise makes precision difficult.

Common Variations and Edge Cases

Tighter workflow inspection often increases alert volume and triage effort, requiring organisations to balance stronger detection against operational noise. Some environments will also find that strict brand and text matching creates false positives when business units use approved but poorly governed Microsoft templates. Best practice is evolving here: there is no universal standard for detecting identity workflow phishing, so teams should tune detections to tenant-specific norms and approved workflow inventories. Edge cases matter. A message may be legitimate but still high risk if it uses an approved Microsoft channel to request credentials, payment, or urgent callback action. Conversely, a message may be suspicious even when the sender is a valid Microsoft service account if the workflow originates from an unexpected tenant or an unapproved app registration. Where possible, pair mailbox detections with identity governance controls, alerting on newly consented OAuth apps, abnormal tenant activity, and workflow changes that bypass standard review. For deeper context on how these patterns are exploited across identity abuse campaigns, the Top 10 NHI Issues highlights why visibility and lifecycle controls matter, while NIST guidance remains useful for response prioritisation and continuous improvement. This guidance breaks down most often in highly delegated Microsoft tenants with many unmanaged automation paths, because defenders cannot easily separate sanctioned workflow behaviour from malicious lookalikes.

Related resources from NHI Mgmt Group

• How should security teams detect AI-generated social engineering that looks legitimate?
• How should security teams handle phishing as an identity problem rather than an email problem?
• How should security teams connect email detections to identity containment workflows?
• How should security teams handle AI-driven phishing in identity workflows?