Here’s the core mental model: both are identities for apps and services — not humans. The difference is who manages the credentials and where the workload runs.

Managed Identity is Azure saying: “I’ll handle the identity for you — no passwords, no secrets, no expiry dates.” You just enable it on your resource (a VM, App Service, Function, etc.), assign it an RBAC role, and your code authenticates automatically. Nobody — not even you — ever sees the underlying credential. Microsoft rotates it silently in the background.

Service Principal is the more traditional model: you register an application in Microsoft Entra ID, generate a client secret or certificate, store that secret somewhere (like Key Vault), and your app uses it to authenticate. You own the full lifecycle — rotation, expiry monitoring, access revocation. It’s more flexible but carries more risk and operational overhead.

The simple rule of thumb is:

• Running inside Azure? → Use Managed Identity, always.
• Running outside Azure (GitHub Actions, on-prem server, another cloud)? → You have to use a Service Principal, since Managed Identity only works on Azure-hosted resources.

One nuance worth knowing: Managed Identity is actually implemented as a special type of Service Principal under the hood — it’s just one where Azure controls the credential lifecycle instead of you. So they’re not completely different systems, just different levels of management responsibility.