Microsoft Entra ID
Service 32

Microsoft Entra ID

Identity

Microsoft Entra ID — formerly Azure Active Directory — is the cloud identity and access service behind every Azure sign-in. It holds users, groups, application registrations, and the policies that govern how they authenticate. On Azure, identity is the primary security perimeter, and Entra ID is where that perimeter is defined.

Most cloud breaches are identity failures, not network ones: a phished credential, a service principal with a leaked secret, a standing admin role nobody revoked. Getting Entra ID right — strong authentication, least privilege, conditional access — does more for security than any network control, which is why this chapter starts here.

Identities

Entra ID holds several kinds of identity. Users and groups are the human side. Application registrations define an app's identity and the permissions it requests; a service principal is the instance of that identity in a tenant — the non-human account an app authenticates as. Managed identities (the next service) are service principals Azure manages for you. Knowing which identity an actor uses is the first step in reasoning about access.

Authentication and MFA

Authentication proves who an identity is, and multi-factor authentication is the single highest-impact control — a stolen password alone cannot sign in. Passwordless options (FIDO2 keys, the Authenticator app, Windows Hello) raise the bar further and resist phishing. MFA on every privileged account is not optional; it is the baseline.

Conditional Access

Conditional Access evaluates signals at sign-in — user, group, device state, location, client app, and sign-in risk — and applies a control: allow, require MFA, require a compliant device, or block. It is how Entra ID enforces policy dynamically, such as requiring MFA from unmanaged devices while letting compliant ones through. Conditional Access requires Entra ID P1 or higher.

Conditional Access — Signals to Decision
Sign-in attemptuser, device, location, client app, risk
Evaluate policyconditions matched against the signals
Decisionallow · require MFA · require compliant device · block
The same user is allowed straight through from a compliant corporate device but challenged for MFA — or blocked — from an unmanaged device or a risky location.

Licensing Tiers

Entra ID comes in a Free tier (basic directory and SSO), P1 (Conditional Access, dynamic groups, self-service password reset), and P2 (identity protection with risk-based policies, Privileged Identity Management for just-in-time admin). Many of the controls this chapter recommends — Conditional Access, PIM, risk-based sign-in — require P1 or P2, so the tier is a security decision, not just a budget line.

Application Integration

Entra ID is an identity provider for your own and third-party applications via OAuth 2.0, OpenID Connect, and SAML, giving single sign-on across thousands of SaaS apps and your own code. Centralizing authentication here — rather than each app holding its own user store — is what makes consistent policy, MFA, and revocation possible across the estate.

Microsoft Entra ID vs Entra External ID

Microsoft Entra ID — Workforce identity — employees, contractors, internal apps, with Conditional Access and PIM. The corporate directory and security perimeter.

Entra External ID — Customer and partner identity — sign-up, social logins, custom-branded flows. Keeps customer identities out of the corporate tenant.

Common Mistakes
  • Leaving MFA off for privileged accounts — a single phished password then grants full access, and this is how most breaches start.
  • Granting standing admin roles instead of just-in-time elevation with Privileged Identity Management, leaving permanent high-value targets.
  • Assuming Conditional Access is available on the Free tier — it requires P1 or higher, and the license is part of the security design.
  • Storing app secrets for service principals in code or config instead of using managed identities or certificate credentials.
  • Mixing customer identities into the workforce tenant instead of using Entra External ID, blurring the security boundary.
  • Over-granting application permissions (especially admin-consented Graph permissions) far beyond what the app needs.
Best Practices
  • Require MFA for every account, and phishing-resistant passwordless methods for privileged ones.
  • Use Conditional Access to gate sign-in on device compliance, location, and risk (requires P1+).
  • Grant admin access just-in-time with Privileged Identity Management (P2) rather than standing roles.
  • Use managed identities or certificate credentials for applications; never store service-principal secrets in code.
  • Keep customer identities in Entra External ID, separate from the workforce tenant.
  • Apply least privilege to application permissions and review admin consents regularly.
Comparable servicesAWS IAM Identity Center / IAMGCP Cloud Identity

Knowledge Check

Why does Entra ID matter more for security than network controls on Azure?

  • Identity is the primary perimeter — most breaches are identity failures like phished or leaked credentials
  • Network controls such as NSGs, Azure Firewall, and private endpoints are simply not available anywhere on the Azure platform
  • Entra ID entirely replaces and removes the need for NSGs and firewalls in any deployment
  • Identity controls are entirely free of charge in every tier while network controls always carry an extra cost

A team wants to require MFA only when users sign in from unmanaged devices. Which feature does this, and what license does it need?

  • Conditional Access, which requires Entra ID P1 or higher
  • Multi-factor authentication, available only on the Free tier
  • Privileged Identity Management, available on the Free tier
  • A Network Security Group rule on the subnet

What does Privileged Identity Management (P2) provide?

  • Just-in-time, time-bound elevation to admin roles instead of standing permanent access
  • Customer sign-up, social identity login, and self-service profile management flows for external users
  • A fully managed secrets store for application keys, certificates, and database connection strings
  • DNS-based global routing of incoming sign-in requests to the nearest available regions

You got correct