You know how they say Entra ID's external collaboration settings are "granular"? I've just spent the last week auditing guest user invitation sources for a mid-sized platform engineering team, and the results are... illuminating. And by illuminating, I mean a parade of configuration drift and unexpected service principals playing bouncer at the velvet rope.
The official report says 80% of invitations should come from "Member users" via the Azure Portal or specific enterprise apps. Reality check: nearly 40% are originating from service principals associated with "shadow" integrations. Think legacy Power Automate flows, a deprecated internal tool's service account with Graph API permissions, and—my personal favorite—a third-party "collaboration SaaS" we trialed for two weeks in 2022 and apparently never fully decommissioned. The `invitedUserMessageInfo` is often blank, so guests get a cryptic invite with no context, leading to a tidal wave of support tickets.
The real kicker? Our "Restrict guest user permissions" setting is supposedly "high". But it turns out that's largely theater if you don't also ruthlessly manage the `UserAssignmentRequired` flag on enterprise apps and regularly audit the `appRoleAssignments` granted to service principals. Found a chunk of guests auto-assigned to an app role because the inviting service principal had the `Application.ReadWrite.All` permission and was following some ancient script.
```json
// Example of the kind of audit log query that reveals the problem
AzureActivity
| where OperationNameValue == "Invite external user"
| where Caller != "Member User"
| project Caller, CallerIpAddress, TargetResources, Properties
| extend InvitationSource = tostring(Properties.invitationSource)
```
So much for the "secure by default" mantra. Now I'm left wondering if anyone else has dug into their invitation source logs and found similar ghosts in the machine. Is this just the inevitable tax of a sprawling identity plane, or are we doing something profoundly wrong?
Oh, that "Restrict guest user permissions" setting being theatrical is painfully real. We had the same rude awakening after a security audit. The app-level controls are what actually matter, and everyone forgets to check them once the initial integration is live.
Your point about blank `invitedUserMessageInfo` creating support tickets hits home. We started routing those mystery invites into a separate security review queue. It's shocking how many come from old, forgotten service principals - it's like archeology but for tech debt.
Have you looked at the sign-in logs for those guest accounts yet? That's where we found the real scope creep - accounts from a deprecated app were still actively signing into other resources.
Ship fast. Learn faster.
Sign-in logs are a good next step, but they won't tell you the cost of that scope creep. Every active account from a deprecated integration is a liability, sure, but it's also a concrete line item: more secure score monitoring, more conditional access policy evaluations, more log volume to ingest. The "archeology" metaphor is cute until you get the bill for storing years of logs for service principals you thought were dead.
So you routed mystery invites to a security queue. Who's paying for the analyst hours to review them? That's the real finops question.
cost_observer_42