What Is Microsoft Entra ID? A Practical Guide to Azure AD’s New Name

Microsoft Entra ID is a cloud-based identity and access management service that acts as your organization’s central authority for verifying who is signing in and deciding what they can reach, typically deployed as part of Microsoft 365 or Azure and covering everything from employee accounts to application integrations.

What most readers actually want to understand is simpler than the product marketing suggests: Entra ID is what replaced Azure Active Directory. If you have a Microsoft 365 tenant, you already have it. The real questions are what it does, what the rename actually changed (less than you might think), how the sign-in process works, and whether your current licensing unlocks the controls your business actually needs.

This guide covers all of that: the Entra name and product family, how Entra ID compares to Azure AD, how sign-ins and access policies work, what the Entra admin center does, and how to read the Free, P1, and P2 licensing tiers without getting lost in Microsoft’s naming conventions.

Identity and access management is the business function of answering two questions at sign-in time: who or what is requesting access, and what is that identity permitted to use. Those sound like IT abstractions, but they translate directly to whether your employees can reach their email, whether a contractor can open a shared file, and whether an attacker who stole a password can get any further than the login screen.

Microsoft Entra ID is the current product name for the identity service that most readers still know as Azure Active Directory. The service manages identities for employees, administrators, guests, groups, devices, applications, and workloads. Application registrations and service principals represent applications inside the directory, while managed identities allow workloads to authenticate without requiring manually managed credentials.

Entra ID works across Microsoft 365, Azure, connected third-party SaaS applications, and supported on-premises web applications. That reach is what makes it the foundational layer of cloud security for most businesses, not a narrow Microsoft-only tool.

Attackers understand this. Credentials, administrator permissions, and application access are frequently targeted precisely because compromising an identity can bypass every other control you have put in place.

Microsoft Entra is the broader identity and network access family

Microsoft Entra is a wider product family for identity and network access. Microsoft Entra ID is its foundational cloud directory and access service, not just one product among equals.

The family includes related services with distinct purposes: Entra ID Governance extends identity lifecycle and access review capabilities; Entra Permissions Management addresses cloud permissions across multi-cloud environments; Entra Internet Access and Entra Private Access extend secure network access through a security service edge model. Each of these addresses a specific gap, but none of them replaces Entra ID’s core directory, authentication, and access-policy functions.

The boundary matters for buyers. You can adopt Entra Internet Access without changing your Entra ID configuration, and you can configure robust Conditional Access inside Entra ID without touching any of the network-access products. This guide stays focused on Entra ID because that is the foundation every organization in our client base touches first.

The core jobs Entra ID performs

Authentication is the process of verifying that a user or workload is the identity it claims to be at sign-in. Entra ID handles this for employees signing into Microsoft 365, for applications calling APIs, and for workloads running in Azure.

Authorization is what happens after authentication succeeds. It determines what an authenticated identity is allowed to access, whether that is a SharePoint site, an Azure subscription, an enterprise application, or an administrative function. The two steps are distinct, and both matter.

Single sign-on lets users access multiple supported applications with one organization account, without separate sign-in prompts for each service. From a productivity standpoint, it removes friction. From a security standpoint, it also centralizes authentication so that strong controls apply consistently rather than being patched together per application.

MFA adds a second verification requirement beyond a password. Role-based access control assigns administrator permissions based on job responsibilities, so users receive only the privileges their work requires. Both are worth calling out separately because they address different attack surfaces: MFA protects against stolen credentials, while role-based access limits the blast radius when an account is compromised.

Microsoft Entra ID is the new name for Azure Active Directory, commonly shortened to Azure AD. That is the full answer to the comparison. Microsoft announced the rename in July 2023, the new name began appearing across Microsoft experiences in August 2023, and service-plan display names changed on October 1, 2023.

No customer was required to migrate to a new tenant or rebuild their identity environment because of the rebrand.

Existing deployments, configurations, capabilities, licensing plans, and pricing did not change. Login URLs, APIs, PowerShell cmdlets, and Microsoft Authentication Libraries all remained in place. The change was a branding update, not a platform replacement.

This distinction matters because I still talk to IT managers who assume they need to “move to Entra ID” and are budgeting migration time. They don’t. What they may genuinely need is a review of whether their current Conditional Access policies are adequate, whether their licensing covers the controls they want to enforce, or whether their hybrid identity configuration needs modernizing. Those are real improvement projects worth doing. None of them were created by a name change.

A good example of what an actual tenant-architecture migration looks like: we worked with a client whose Microsoft 365 environment had been provisioned through GoDaddy and operated as a federated tenant. That federation blocked customizations and third-party integrations across mailboxes, SharePoint, OneDrive, and Teams. We migrated them to their own tenant and implemented automation workflows that the old setup made impossible. That is a necessary migration driven by architectural constraints. Our Microsoft 365 tenant migrations typically take 2 to 5 days depending on tenant size, and the value is full control over identity and licensing decisions going forward. The Azure AD-to-Entra ID rename had nothing to do with why that client needed to move.

Also worth noting: our managed Microsoft 365 services practice handles tenant setup, licensing validation, and ongoing administration, which means these architecture questions surface before they become expensive problems.

Understanding how a sign-in actually works helps explain why identity is a security control, not just an IT convenience. The sequence goes like this:

1. 1
   A user attempts to open Microsoft 365, Azure, or a connected business application.
2. 2
   Microsoft Entra ID authenticates the identity.
3. 3
   Applicable controls, including MFA and Conditional Access policies, evaluate the sign-in against configured rules.
4. 4
   The service allows access, blocks access, or requires an additional verification step before granting access.

A password alone does not complete an access decision when Conditional Access is in place. Identity, authentication strength, policy conditions, device compliance status, and application sensitivity all feed into the outcome. That layering is what separates a basic cloud directory from a functioning identity security posture.

Businesses use this process to protect Microsoft 365 access, Azure resources, SaaS applications, remote work, administrator accounts, and controlled guest collaboration. The same policy engine that blocks a sign-in from an unrecognized country can also require a compliant device before allowing access to a finance application, or step up to MFA only when a risk signal appears.

MFA, single sign-on, and access policies solve different problems

SSO is a convenience and productivity control that reduces repeated sign-ins across supported applications. It is not a security upgrade on its own. SSO centralizes authentication, which creates a natural place to enforce strong controls, but it does not remove the need for them.

MFA adds a verification requirement beyond the password, helping reduce the risk posed by stolen or guessed credentials. It is one of the most effective controls available because it raises the cost of a credential attack significantly.

Conditional Access determines when MFA or other requirements should apply, such as for sensitive applications, unfamiliar sign-in conditions, or selected users. Without Conditional Access, MFA may be an all-or-nothing setting. With it, you can apply requirements precisely where risk justifies the friction.

Self-service password reset lets users reset passwords without calling the help desk when the relevant licensing and configuration requirements are met. That reduces support volume and gives IT a documented, policy-driven reset process instead of an informal one.

Identity Protection is Microsoft’s capability for detecting risky sign-ins and risky identities based on signals across the Microsoft network. Risk-based Conditional Access, which takes action automatically when Identity Protection flags a suspicious sign-in, requires P2-level licensing. It is worth understanding that distinction before assuming the feature is available on your current plan.

Hybrid identity connects on-premises Active Directory to the cloud

Hybrid identity is an arrangement where an organization keeps its on-premises Active Directory running while synchronizing identity data to Microsoft Entra ID so those same accounts can be used for cloud access. Most of the SMBs we work with across New Jersey, New York, and Pennsylvania are either fully cloud-native or running some form of hybrid configuration.

Microsoft Entra Connect Sync and Microsoft Entra Cloud Sync can both synchronize identity data between on-premises environments and the cloud. Cloud Sync is Microsoft’s stated strategic direction, using a lightweight provisioning agent and cloud-managed configuration. Connect Sync remains fully documented and may still be the right choice depending on the feature set an organization requires.

The buying nuance here is real: you should assess compatibility before assuming you can switch synchronization methods. Some features available in Connect Sync are not yet supported in Cloud Sync. Making the wrong call without an assessment creates identity synchronization problems that are disruptive to fix.

Hybrid identity can help organizations preserve existing user accounts and internal directory dependencies while enabling cloud services. It also requires deliberate planning around synchronization scope, authentication method, and recovery procedures. Getting the initial design right is significantly cheaper than repairing a misconfigured sync.

The Microsoft Entra admin center is the web portal used to administer Microsoft Entra products and core Entra ID functions. Think of it as the operational dashboard where identity policy becomes reality.

The portal replaces much of the routine use of older Azure AD administration screens. Administrators can accomplish the following day-to-day tasks from a single interface:

• Create, update, disable, and organize users and groups.
• Configure authentication methods and MFA settings.
• Create, test, and manage Conditional Access policies.
• Connect and manage enterprise applications for SSO.
• Manage guest users and external collaboration settings.
• Assign and review administrative roles.
• Review application access and identity governance settings where licensed and configured.

Sign-in logs and audit logs are available through Entra ID > Monitoring & health, giving administrators a view into access activity and policy changes. Those logs are where you go when an employee can’t sign in, when a Conditional Access policy behaves unexpectedly, or when you want to confirm that MFA is being enforced as intended.

The practical use cases run across the organization’s lifecycle. A new employee needs Microsoft 365 access after onboarding. A contractor needs time-limited guest access to a shared project folder. An administrator needs to enforce MFA before access to a sensitive financial application. A business wants SSO configured for a connected SaaS tool. All of that happens here.

An administrator’s available actions depend on the permissions assigned to their role. This matters in practice: a helpdesk technician with User Administrator rights can reset passwords and manage basic user attributes, but cannot modify Conditional Access policies or change authentication methods. Getting role assignments right is both a security and an operational decision.

The Entra admin center is not simply a user-creation screen. It is where organizations translate identity policy into enforced controls, and where the gap between “we have MFA” and “MFA is actually required for the accounts that matter” becomes visible.

As of November 5, 2026, Microsoft describes three main Microsoft Entra ID editions: Free, P1, and P2. The edition determines which features are available to your users, and understanding the tier boundaries is what prevents you from spending money on a plan that doesn’t cover the controls you need, or running P1 features while only licensing Free.

Entra ID P1 and P2 US annual pricing

Pricing shown is Microsoft’s US annual-subscription pricing on November 5, 2026. Contract terms, region, currency, tax, applicable discounts, and bundled Microsoft 365 plans can all affect actual cost.

The buyer decision simplifies once you frame it correctly. Free works when basic cloud identity functions meet the organization’s needs. P1 becomes relevant the moment Conditional Access is required, which for most businesses happens as soon as they want to enforce different access rules for different users, applications, or sign-in contexts. P2 is the right answer when the organization needs risk-based Conditional Access, Identity Protection, or Privileged Identity Management. One point that gets missed: confirm licensing for the users benefiting from a feature, not only the administrator who configures it.

Microsoft Entra External ID has separate usage-based pricing for customer-facing and other external-identity scenarios. Its core offer includes the first 50,000 monthly active users free, with premium add-ons billed separately. This is not a substitute for P1 or P2 workforce licensing, and confusing the two creates gaps in both coverage and budget.

On configuration: most of the managed IT clients we run at On-Site Technology have MFA and EDR deployed as a baseline. That pairing covers credential attacks and endpoint-level threats, but it only holds when enforcement is actually configured in Entra ID, not just enabled in name. The most common gap we find is MFA that is technically turned on but not enforced through Conditional Access, meaning a user who dismisses the prompt or uses a legacy authentication method can still get through.

Practical configuration priorities worth working through:

• Require MFA for all users, with administrator accounts as the starting point.
• Apply least privilege through appropriate administrative roles and review those assignments regularly.
• Test Conditional Access policies using report-only mode before broad deployment. Microsoft documents a limit of 240 Conditional Access policies per tenant, including policies in on, off, or report-only states.
• Maintain protected, monitored emergency administrator accounts and test recovery procedures. Losing access to your own tenant is a recoverable but genuinely painful situation.
• Review guest accounts, enterprise applications, application permissions, sign-in logs, and audit log responsibilities on a regular schedule.

The operational priority is pairing the right license with enforceable policies and regular review. An Entra ID subscription is not a security control by itself. The controls are what you configure inside it.