2.1.4. Application Identity: Enterprise Apps and App Registrations
💡 First Principle: Every non-human caller — an application, a script, a service — still needs an identity Entra ID can evaluate, and Entra ID represents that identity as two connected objects that are easy to conflate but serve different purposes.
An app registration is the global definition of an application — its name, supported account types, redirect URIs, and the permissions it's requesting (its "blueprint"). An enterprise application is the local instance of that app in your tenant — the service principal that actually gets assigned permissions, roles, and Conditional Access policy scope in your directory. A single app registration (say, a SaaS vendor's multi-tenant app) can have one enterprise application object created in every tenant that uses it.
| Object | Represents | Where Permissions Live |
|---|---|---|
| App registration | The application's global definition (one per app, in its home tenant) | Requested permissions (API permissions blade) |
| Enterprise application (service principal) | The local instance of that app in a specific tenant | Granted/consented permissions, assigned users/groups, Conditional Access scope |
⚠️ Exam Trap: Deleting or modifying an app registration in your tenant when the actual problem is a misconfigured enterprise application (or vice versa) is a common wrong answer on scenario questions. If the issue is "which users can sign in to this app" or "what permissions were actually granted," you're working with the enterprise application object, not the registration.
Reflection Question: A third-party SaaS vendor's application appears in your tenant's Enterprise Applications list, but you never created an app registration for it. Why is that expected?
