3.1.2. Types of Identities

💡 First Principle: Not every identity in Microsoft Entra ID represents a human — it also represents software that needs to authenticate and act, and choosing the right identity type matters because each is managed, secured, and governed differently.

Microsoft sorts identities by what they're assigned to: people, devices, or software.

Device identities can be set up three ways. A Microsoft Entra registered device is typically personally owned (bring your own device), used to reach work resources. A Microsoft Entra joined device is organization-owned and signed in to with an organizational account. A Microsoft Entra hybrid joined device is joined to both on-premises Active Directory and Microsoft Entra ID.

Groups let you grant access once to many identities with the same needs. A security group manages access to shared resources and can contain users, devices, other groups, service principals, and agent identities; a Microsoft 365 group is for collaboration (a shared mailbox, calendar, files, and SharePoint site) and contains users only. Membership is either assigned by hand or dynamic, where rules add and remove members automatically based on their attributes.

Managed identities are worth pausing on: they let an Azure resource (like a VM or Function App) authenticate to other Azure services without a developer ever storing a password or secret in code — Entra ID manages the credential automatically behind the scenes. Agent ID is a newer identity type reflecting the rise of AI agents that take autonomous action — rather than sharing a human's credentials, an agent gets its own identity, so its actions can be governed, audited, and access-scoped independently.

Microsoft groups these types into two families. Human identities represent people — employees and external users such as partners or customers. Machine (non-human) identities represent software and devices, and the software half has its own name: workload identities. In Microsoft Entra, workload identities are applications, service principals, and managed identities. They need their own protection because a workload can't answer an MFA prompt and often holds long-lived credentials, so Microsoft Entra Workload ID extends Conditional Access, ID Protection risk detection, and access reviews to them. Agent identities for AI agents are treated as a distinct category of machine identity with extra governance, such as a required human sponsor.

External identities are handled by Microsoft Entra External ID. B2B collaboration lets business partners sign in to your workforce tenant with their own organization's credentials; they appear in your directory as guests, and you hold no password for them. B2B direct connect creates a mutual trust between two Microsoft Entra organizations for Teams shared channels, and those users aren't added to your directory as guests. For apps aimed at consumers or business customers, an external tenant provides customer identity and access management (CIAM): self-service sign-up, social sign-in, and account management.

⚠️ Exam Trap: A service principal and a managed identity are not the same thing — a managed identity is a special, credential-free type of service principal that Azure creates and rotates automatically; not every service principal is a managed identity.

Reflection Question: Why would giving an AI agent its own agent ID, rather than letting it reuse a human employee's credentials, make that agent's actions easier to audit and govern?