On July 11, Microsoft made two identity announcements in the same week, and only one of them showed up on a roadmap slide. The first: Azure Active Directory was being renamed Microsoft Entra ID, folded into a wider Entra product family alongside several products most IT managers had never had reason to open. The second: Microsoft disclosed that a China-based actor tracked as Storm-0558 had spent weeks forging authentication tokens to read mail out of Exchange Online at roughly two dozen organizations, several of them government agencies. We wrote about the token-forgery story when it broke. This note is about the other announcement — the one that generated far more internal tickets for us this quarter and far less actual risk.
Ten weeks on, we have closed out the audit we opened the week of the announcement: every runbook, diagram, training deck, and client-facing document across our practice that still said "Azure AD" or "Azure Active Directory." The answer to "what do we need to change" turned out to be almost entirely cosmetic. The answer to "what does this mean" turned out to be more interesting than the cosmetics, worth writing down separately.
The short version, and the theme of everything below: nothing about how Microsoft Entra ID authenticates a user, evaluates a Conditional Access policy, or behaves during an outage changed on July 11. What changed is the label on the box, and the shape of the box sitting next to it. Confusing those two things — treating a rebrand like an architecture change, or dismissing a strategy signal as "just marketing" — is how identity teams either waste a quarter on busywork or miss where a vendor is actually headed.
What actually changed when Azure AD became Microsoft Entra ID
Azure Active Directory the product name is retired; Microsoft Entra ID is the new name for the same directory service, and nothing that makes it a directory moved. The tenant ID is the same GUID it was in June. Every user, group, device, and service principal object is untouched. The Microsoft Graph endpoint is still graph.microsoft.com. The sign-in endpoint is still login.microsoftonline.com. Conditional Access policies evaluate in the same order, against the same signals, with the same session controls. Multifactor registration, Windows Hello for Business, and certificate-based authentication are unchanged. If a break-glass account worked on July 10, it still works today — we checked, because that is the kind of thing you verify rather than assume.
What did change, concretely: the left-hand navigation label in the Azure portal now reads "Microsoft Entra ID" instead of "Azure Active Directory." Some Microsoft Learn documentation moved to new URL paths; the redirects mostly work, and we hit two dead links updating our own bookmarks. The product family also got wider — the more consequential change, and the subject of the next section.
One thing worth flagging because it trips people up: renaming the product did not rename the service plan strings you are actually licensed under. Run a subscribed-SKU query today and the old names are still there:
PS> Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits
SkuPartNumber ConsumedUnits
------------- -------------
AAD_PREMIUM_P2 300
AAD_PREMIUM 1200
ENTERPRISEPACK 1500
Your invoice, your Microsoft 365 admin center product list, and your licensing partner's billing platform all still key off "AAD_PREMIUM_P2," not "Entra ID P2." If any of your automation or license-reconciliation scripts pattern-match on product display names instead of SKU part numbers, this is a good prompt to confirm they never did.
The rest of the family Microsoft moved in alongside it
The bigger change on July 11 was not relabeling the directory. It was Microsoft using "Entra" as an umbrella for a set of products that previously shared no branding, some of which most of our clients have never had a reason to open:
| Product | What it actually does | Status, September 2023 |
|---|---|---|
| Microsoft Entra ID | Directory, authentication, Conditional Access — what everyone means when they say "Azure AD" | GA, renamed |
| Microsoft Entra ID Protection | Risk-based sign-in and user risk detection | GA, renamed |
| Microsoft Entra Permissions Management | Cloud infrastructure entitlement management across Azure, AWS, and GCP | GA |
| Microsoft Entra Verified ID | Issuing and verifying decentralized identity credentials | GA |
| Microsoft Entra Workload ID | Conditional Access-style governance for service principals and managed identities | GA, Premium tier |
| Microsoft Entra Internet Access | Secure access to Microsoft 365 and the open internet | Public preview |
| Microsoft Entra Private Access | Zero-trust access to private apps; a VPN alternative | Public preview |
Two of those seven rows are previews, not shipping product, so don't let a slide with all seven logos turn into a procurement conversation this quarter. Permissions Management is the CloudKnox acquisition wearing a new name; Verified ID already existed as a standalone play. The rename gave Microsoft a reason to put both on the same page as the directory. Internet Access and Private Access are the newest and least proven of the group: worth tracking, not worth piloting yet, and not worth unwinding a working VPN or ZTNA estate to chase.
Where the churn actually shows up this quarter
The naming inconsistency is the tedious part of this quarter, not the consequential part, but it is real. Azure AD Connect and Azure AD Connect Health, the on-premises sync tooling most of our hybrid-identity clients depend on, were not renamed at all. The legacy AzureAD and MSOnline PowerShell modules still expose cmdlets like Connect-AzureAD and Get-AzureADUser; the newer Microsoft Graph PowerShell SDK uses an entirely different Mg-prefixed cmdlet set — three naming schemes, one directory. Support-ticket categories in the Microsoft 365 admin center still file some issue types under "Azure Active Directory." And inside client environments, the artifacts nobody budgets time to rename: distribution lists called something like "azuread-admins," Teams channels, a Visio diagram three revisions deep, a security-awareness training deck due for its annual refresh.
None of that is a security or availability risk. All of it is the kind of paper cut that becomes a support ticket the day a junior admin cannot find "Azure Active Directory" in the portal search box and assumes something broke. We added one line to the onboarding documentation for every managed-services client this month: old name, new name, same product, stop searching for a blade that moved.
Why we read this as a strategy signal, not a paint job
Here is our read, not something Microsoft said in these words: bundling cloud entitlement management, decentralized identity, workload identity governance, and network access under one identity brand bets that identity becomes the control plane customers keep buying into, not the sign-in box they licensed years ago and rarely revisit. Permissions Management now competes with cloud infrastructure entitlement management vendors who previously had no Microsoft-branded rival inside the directory a customer already pays for. Internet Access and Private Access, even at preview quality, put Microsoft in the same conversation as the secure service edge and zero-trust access vendors who have spent years selling against the corporate VPN. None of those products needed the word "Entra" to function on their own. They needed it to eventually be sold together.
We would not be surprised if this ends in a single bundled license within a year or two of this note. Microsoft doesn't build seven adjacent product names without eventually wanting one purchase order to cover them. That is a prediction, not a fact, and we will happily be wrong. What we are confident about today: if your Microsoft account team opens a conversation about "the Entra portfolio," they are reading the same tea leaves we are, and it is worth asking exactly what is licensed today versus what is preview with a price tag already attached.
What we changed in our own documentation, and what we deliberately left alone
We treated our documentation debt as a triage exercise, not a mass find-and-replace. Client-facing material — proposals, statements of work, anything a prospective client reads before signing — got updated within the first two weeks, because a document that still says "Azure Active Directory" in September reads as stale even when every technical detail in it is correct. Deep internal runbooks, including the recovery procedures for a 700-plus-server estate we operate for one long-standing client, are being updated opportunistically: the next time a runbook gets touched, the vocabulary gets fixed as part of that edit, not before. Mass-editing hundreds of files purely for terminology produces diff noise, invites merge conflicts, and fixes nothing an auditor or an on-call engineer cares about at two in the morning.
The naming-convention lesson we are carrying forward: nothing we name from here on out should bake in a vendor's product brand, because vendors rename things on their own schedule, not ours. Our Conditional Access policies were never called "AAD-Block-Legacy-Auth," for exactly this reason:
CA001-Global-BlockLegacyAuth-Grant
CA010-AllUsers-RequireMFA-AllApps
CA050-AllUsers-RequireCompliantDevice-M365
Numbered, scoped, and named for what the policy does rather than which product happens to run it. Every client whose Conditional Access policies, security groups, or Log Analytics workspaces were named directly after "Azure AD" is doing the mass-rename exercise we managed to avoid. That is not smugness on our part — we have made the equivalent mistake with other vendors' names often enough to have finally learned from it.
The one place the rename actually creates paperwork
The single spot where we told clients this was not purely cosmetic: compliance documentation for auditors and contracting officers who care about exact, current product names. Several of our public-sector clients operate under contract language, system security plans, or control narratives that name "Azure Active Directory" as the identity provider of record. The rename does not change the underlying control, but it can trigger a legitimate question from an assessor about why a security document names a product Microsoft no longer sells under that name. For a state agency, or any regulated enterprise with an external auditor, that is genuine, billable work this quarter: updating control narratives, data-flow diagrams, and vendor-name references — and confirming with the assessor that it is a documentation update, not grounds for a control re-test. We have had exactly that conversation with two clients so far this month; in both cases the fix was an afternoon of editing, not a re-authorization.
If you're facing this
If your Conditional Access policies, security groups, or client-facing documentation still hard-code a vendor brand name that has already changed once this year, assume it changes again before it changes back. We help Microsoft-centric identity teams sort the cosmetic churn from the parts of a rename that are actually telling you where a platform is going, and put the real hours where they belong: the compliance and documentation debt that does not fix itself. If you want a second opinion on what in your tenant genuinely needs attention this quarter versus what just needs to be logged and left until the next natural edit, reach out.