Getting started with Entra ID in 2026 is a different exercise than it was even two years ago, because the part everyone used to start with is now done for you. Microsoft has moved the security baseline from a set of recommendations you implemented to a floor it enforces. The work that remains is not turning protections on. It is deciding everything the floor does not decide, and understanding what has quietly been switched on underneath you.
This is the anchor article for a series on Entra ID, the identity control plane that the entire endpoint estate hangs from. The Intune series that precedes it assumed identity on every page. Conditional Access got its own phase. Everything else, the directory itself, the way privilege is granted, the credentials people actually sign in with, was treated as substrate. This series makes the substrate explicit, and it starts here, with the shape of a well-run tenant in the current year and the decisions that still belong to you.
The floor is enforced now
Three shifts have converged to make the tenant baseline something you inherit rather than build. Multifactor authentication for the administrative control plane is no longer a policy you author; it is enforced by the platform. Beginning October 1, 2025, MFA enforcement gradually applied to Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tooling, and the REST API for any create, update, or delete operation, with read operations exempt. It follows the enforcement that already covered the Azure, Entra, and Intune admin centers. The important detail for anyone designing around it is that this enforcement applies to all user accounts, including break-glass and otherwise-excluded accounts, and the window to postpone it closed on July 1, 2026. There is no tenant left where an administrator signs into the control plane without a second factor.
Alongside that, Microsoft now deploys Conditional Access on your behalf. Microsoft-managed policies arrive in report-only mode and, if left there, enable themselves after a notice period rather than waiting for you: multifactor authentication for admins, multifactor authentication for per-user-MFA holdouts, and protection for risky sign-ins, among others. New tenants are created with security defaults already on. The consequence is architectural, not cosmetic. You are no longer building the first line of defense; you are building on top of one that already exists, and the correct posture is to treat these managed policies as the substrate and design deliberate policy above them rather than duplicating or fighting what is already running. The single most common way I see tenants get this wrong is authoring a policy that collides with a managed one and then spending a week working out why sign-in behaves strangely.
You are no longer building the first line of defense. You are building on top of one that already exists.
So the getting-started question in 2026 is not “how do I secure the tenant.” A meaningful part of that is answered before you arrive. The question is what the floor does not cover, and that is where the rest of this article lives.
Privilege is still yours to design
Nothing Microsoft enforces will decide how many people hold the keys to your directory, and this is the decision that separates a defensible tenant from a fragile one. The guidance has not moved and it is not soft: Global Administrator belongs to fewer than five people, privileged roles overall to fewer than ten, and the practical target most mature tenants land on is two to four global admins total. Standing privilege for humans should approach zero. Privileged Identity Management makes a person eligible for a role rather than permanently holding it, with activation gated by justification, approval, and a short window, and the access removed automatically when the window closes. Admin identities should be cloud-only accounts with no mailbox and no productivity licenses, never on-premises synced accounts, because a synced privileged account ties the security of your directory to the security of your weakest domain controller.
The reason this matters more than it used to is that the enforced floor has pushed attackers toward exactly the gaps the floor does not close. Security assessments through 2026 keep surfacing the same findings: multi-tenant enterprise applications holding directory-write permissions that amount to unnoticed shadow administrators, groups that grant privileged roles yet can be modified by ordinary users, and PIM configured with eligible roles that carry no approval requirement, no multifactor challenge on activation, and no activation limit. Granting a role is easy. Governing who can grant it, and proving it, is the actual work, and it is entirely on your side of the line.
Structure is governance, not housekeeping
How you name and shape the directory is not administrative tidiness; it is the substrate every access decision is written against, and it ages badly when it is improvised. The pattern I now design toward separates two kinds of groups cleanly. Population groups describe who someone is, built from stable attributes with dynamic membership as the default so that membership maintains itself. Entitlement groups describe what someone may reach, and they grant access. Keeping those two roles in separate objects is what lets you reason about access at all, because a group that both defines a population and grants a permission becomes impossible to review honestly. Assigned membership is the exception you document and review, not the default you reach for, and the sprawling all-of-department mega-group is a liability twice over, once as concentrated risk and once as token bloat against the limits a sign-in token can carry.
Administrative units earn a specific mention because their best use in 2026 is protective rather than merely organizational. A restricted management administrative unit can hold your break-glass and tier-zero objects so that ordinary administrators, however privileged, cannot touch them. That is a meaningful containment boundary, and it costs almost nothing to establish early. It is far harder to retrofit once the directory is full.
Break-glass, done the way 2026 requires
This is the single place where old guidance will most visibly date a tenant, so it deserves precision. The pattern many of us deployed for years, two emergency accounts with long random passwords held in a safe and excluded from all Conditional Access and all MFA, is now actively broken. It is broken because MFA enforcement at the control plane applies regardless of any Conditional Access exclusion, so an account whose only credential is a password can no longer sign in to the portal it exists to rescue. Locking your escape hatch inside the very enforcement it was meant to bypass is not a theoretical risk; it is the exact failure mode.
The current shape is different in every particular. Emergency access accounts should authenticate with a passkey, or with certificate-based authentication where a public key infrastructure already exists, rather than a password held outside MFA. They should be excluded only from Conditional Access policies that block or restrict sign-in, not from every policy indiscriminately, because a blanket exclusion strips away protections you actually want on those accounts. They should be validated at least every 90 days so you discover a broken credential during a drill rather than during an incident, and every sign-in to one should raise a critical alert. Register the credential the modern way, through a short-lived access pass, and you have an escape hatch that survives the enforcement rather than one the enforcement has quietly sealed shut.
Authentication is moving past the password by default
The direction of travel is unambiguous, and a tenant set up in 2026 should be built facing it rather than against it. System-preferred authentication is a Microsoft-managed default, and in that state it governs both the first factor and the second, evaluating a user’s registered credentials and steering them to the strongest one they hold. The first-factor behavior rolls out as a managed default through late July 2026. The practical effect is that a user who has registered a passkey simply stops being asked for a password. This is passwordless-preferred, not password-elimination, and the work it asks of you is to get strong credentials registered ahead of the prompt, which is precisely what the Windows Hello for Business family in the endpoint series was about.
Two pieces of hygiene follow directly. Legacy authentication should be blocked completely, because it cannot carry a second factor and the overwhelming majority of password-spray and credential-stuffing attacks ride protocols that predate MFA. And per-user MFA belongs in the past: since September 30, 2025, authentication methods can no longer be managed in the legacy per-user MFA and self-service password reset policies, and the converged Authentication methods policy is the way to manage them. A tenant still carrying accounts in the enabled or enforced per-user MFA state is carrying a defect, not a configuration. Phishing-resistant authentication for administrators, enforced through authentication strengths, is no longer an aspiration to schedule; it is a baseline to hold.
Access as a governed object, including the agents
The difference between a tenant that stays clean and one that decays into a mess of forgotten grants is whether access is treated as something that expires. Entitlement management is how you make that real: access packages bundle the resources a role needs, route requests through an owner who approves them, and, most importantly, attach an expiry so that nothing is open-ended. Guests are the sharpest case for this, because the contractor nobody remembered to offboard is the guest account with standing access and full visibility into your directory, and a connected-organization model with expiry closes that gap by construction. Access reviews recertify the high-risk entitlements on a schedule, delegated to the people who actually know whether the access is still needed rather than to an IT team guessing.
The newest population to govern this way is not human. Entra now issues first-class identities to AI agents, and the correct mental model is to govern an agent exactly as you would govern an employee: a named human sponsor who is accountable for its lifecycle, access granted through the same access packages with the same automatic expiry, and identity risk evaluated against it the way it is against a person. Treated casually, agent identities will become the service-principal sprawl of the next few years, the over-permissioned objects a future assessment flags. Treated as governed identities from the start, they are simply another population the machinery already handles.
Watch the exclusions, and watch the logs
Strong tenants rarely fail at the policy; they decay at the exception. Every exclusion is a small hole cut for a good reason, and the holes outlive the reasons. The service account excluded for a migration that finished a year ago, the pilot group that was never cleaned up, the trusted-location range that quietly exempts an entire office from multifactor challenges: these are where otherwise sound tenants come apart. Treat exclusions as governed objects with owners and review dates, the same way you treat privileged access, or they will accumulate until the policy they undermine is decorative.
Give yourself the evidence to see all of this. The Identity Secure Score and the Entra recommendations are the running scorecard of how far your configuration sits from Microsoft’s own baseline, and they are worth reviewing for the high-importance items rather than chasing a number. Sign-in, audit, and risk logs should be exported to a log platform or a security information and event management system, because the default retention in the portal is too short to investigate anything that matters, and the events worth alerting on are specific: role assignments, changes to Conditional Access, application consent grants, and every single sign-in to a break-glass account.
A note on currency
A getting-started article ages at its edges, so a few current facts are worth stating plainly. The old identity tooling is gone: the MSOnline and AzureAD PowerShell modules and the Azure AD Graph API have all reached retirement, and Microsoft Graph PowerShell and Microsoft Entra PowerShell, over the Microsoft Graph API, are the supported path for anything you script. Custom controls in Conditional Access are deprecated, with adding and editing stopping in September 2026 and full retirement scheduled for early 2027, replaced by external authentication methods. The last survivor of basic authentication, SMTP AUTH, is on a published clock: under the timeline Microsoft set in January 2026 it will be disabled by default for existing tenants at the end of December 2026 and unavailable for tenants created after that, with a final removal date to be announced in the second half of 2027. And Global Secure Access, the identity-network layer of Entra Internet Access and Private Access, is now generally available, which changes some of the network assumptions this series will return to.
That is the shape of a well-founded tenant in the current year: a floor you inherit and respect, a privilege model and a structure you design with care, break-glass built for enforcement rather than around it, authentication aimed past the password, and access, human and otherwise, that expires unless someone renews it. The articles that follow take these one at a time. Conditional Access itself is not among them, because the endpoint series already gave it a full treatment and this series builds on that rather than repeating it. We start next with the identities themselves, and how they come to exist in your directory in the first place.
Entra ID
Next: [E 2] Identities and How They Get There ›
