Microsoft Entra May 2026 GA — Part 2: Governance, Platform, and External ID

The other seven GA features

Part 1 covered the ten GA features in Global Secure Access and Certificate-Based Authentication. This post covers the remaining seven: three Identity Governance updates, three platform and infrastructure items, and one External ID native authentication GA that completes a significant feature set. If you're wondering why it's split across two posts rather than one, the short answer is that doing justice to each feature with actual technical detail rather than one-liner summaries takes space.

The preview features roundup is Part 3 — covering Explicit Forward Proxy, account discovery, the expanded SOC Security Operator role, per-app branding, OIDC federation, and Graph sign-in query counts.

Identity Governance

Three governance features reached GA this month: requestors can now see approver details in My Access, PIM role activation integrates with Conditional Access authentication contexts, and there's a new License Usage page in the admin center. Each of these has been in preview for a while — the GA release marks that they're feature-complete and production-ready rather than introducing new capabilities.

Approver visibility in the My Access portal

When a user submits an access package request through My Access, they can now see the approver's display name and email address while the request is pending. Before this change, the portal showed "Pending approval" with no information about who was reviewing the request. Users didn't know whether the request was waiting for their manager, an HR contact, or someone in IT they'd never interacted with.

This matters practically because access package approvals often have a business owner as approver — not IT. If the user has a deadline ("I need access to this project SharePoint site by Thursday for the client meeting"), they need to know who to follow up with. With the old flow, the standard path was to open a help desk ticket asking who the approver was, which created friction for the requester and volume for the help desk, even though the approver assignment was already configured and visible to admins.

The feature is on by default for members. You can control it at two levels:

Tenant level — in the Entitlement Management settings, under the "Requestors" section
Per access package — in the access package policy configuration under Approval settings → show approver details to requestors

The tenant-level setting controls the default. Per-package settings override the default for that package, so if you have access packages with sensitive approval chains (for example, a compliance team approving access to confidential financial data), you can turn off approver visibility for those specific packages while leaving it on everywhere else.

Entitlement management request access documentation.

PIM role activation with Conditional Access authentication contexts

This is the one I'd flag as the most structurally significant governance GA in this batch. Privileged Identity Management has had its own MFA requirement that runs at role activation time, independently of your Conditional Access policies. Two separate enforcement systems meant two separate audit trails, different configuration paths, and situations where a CA policy that required a specific authentication strength didn't apply during role activation because PIM's own mechanism ran instead.

Authentication contexts bridge the two systems. An authentication context is a named token that you can attach to a Conditional Access policy — the policy fires when that context is requested. You configure the PIM role settings to require a specific authentication context on activation, and the CA policy you've assigned to that context evaluates as normal. The same policy that enforces phish-resistant MFA for your other high-sensitivity operations now also enforces it during role activation.

The configuration path in practice:

In Entra admin center, go to Protection → Conditional Access → Authentication contexts and create a named context, e.g. "PIM-PrivilegedRoleActivation"
Create or update a CA policy: under Conditions, select Authentication context, choose the context you just created. Under Grant, configure your requirements — phish-resistant MFA, compliant device, or whatever your policy requires.
In PIM role settings for the role you want to protect (e.g. Global Administrator or Exchange Administrator), under Activation → Authentication context, select the context.
Save the role settings.

When a user activates that role, PIM triggers the authentication context, which fires the CA policy. The user goes through the standard CA evaluation — same experience as any other CA-protected resource. The audit log shows the CA policy that evaluated, the authentication method used, and the result, in the same sign-in log format as everything else.

The practical benefit beyond just "unified system" is that you can use the full power of CA conditions on role activation. You can require that the activating user is on a compliant device. You can require a specific named location. You can require a specific authentication method beyond what PIM's simpler settings allowed. If your security policy says Global Admin activation requires a FIDO2 key or certificate from a trusted device, you can now configure that precisely through CA rather than approximating it through PIM's built-in options.

Configure PIM role settings documentation.

License usage tracking in the admin center

The Entra admin center now has a dedicated License Usage page (under Identity → Licenses → Usage) that tracks feature adoption for Microsoft Entra P1, P2, and Suite licenses. The page shows six months of trend data and breaks down usage across six categories:

Multi-factor authentication usage (what percentage of users are using MFA)
Conditional Access policies applied (how many sign-ins had a CA policy evaluated)
Risk-based Conditional Access (CA policies using sign-in or user risk conditions)
Self-service password reset usage
Privileged role activations (PIM-managed role activations)
Identity Protection detections (risky users/sign-ins flagged)

Each metric is mapped to the license tier that enables the feature. MFA and basic CA policies are P1. Risk-based CA, Identity Protection, and PIM are P2. The page shows your licensed seat count alongside the active user count for each feature, which makes the right-sizing conversation concrete: if you have 5,000 P2 licenses but only 800 users have ever triggered a risk-based CA policy, there's a visible gap worth examining.

The six-month trend data is more useful than a point-in-time snapshot because adoption often changes after policy rollouts. If you enabled a new CA policy in month 3 and you see the "CA policies applied" metric jump in the same period, that's direct evidence the policy is functioning. If you don't see a jump, either the policy scope is narrower than expected or something in the configuration needs checking.

Note: The License Usage page is read-only and informational — it doesn't make license assignment changes. Those still go through Microsoft 365 admin center or Entra admin center's license assignment flows.

License usage insights documentation.

Platform and infrastructure

Three platform items reached GA: configurable token lifetimes, MIM 2016 SP3, and a Workday provisioning fix for timezone-related termination delays. These are fairly different in nature — configurable token lifetimes is a developer/security platform feature, MIM SP3 is purely a supported platform update for organizations still running on-premises identity infrastructure, and the Workday fix is narrow but addresses a real operational problem.

Configurable token lifetimes

Token lifetime policies let you set custom expiration times for access tokens, ID tokens, and SAML assertions on a per-application basis. You create a policy object, define the lifetimes, then assign the policy to an application or service principal. Without a custom policy, Entra uses default lifetimes: access tokens default to 1 hour, SAML tokens to 1 hour. These defaults work for most applications, but there are legitimate cases where you want different behavior.

The PowerShell approach using Microsoft Graph:

# Create a token lifetime policy
$params = @{
    definition = @(
        '{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"00:30:00"}}'
    )
    displayName = "ShortLivedTokens-HighRiskApp"
    isOrganizationDefault = $false
}
$policy = New-MgPolicyTokenLifetimePolicy -BodyParameter $params

# Assign the policy to a service principal
$spId = "your-service-principal-object-id"
New-MgServicePrincipalTokenLifetimePolicyByRef `
    -ServicePrincipalId $spId `
    -OdataId "https://graph.microsoft.com/v1.0/policies/tokenLifetimePolicies/$($policy.Id)"

The practical use cases break into two directions:

Shorter tokens for high-risk applications — if an application handles payment processing or HR data and you want to reduce the window during which a stolen token could be used, cutting the lifetime from 60 minutes to 15 minutes reduces exposure. The tradeoff is more frequent token refreshes, which is transparent to users in most cases (the client silently gets a new token from the refresh token) but can cause noticeable re-authentication in applications that don't implement silent refresh correctly.
Longer tokens for specific integration patterns — some API-to-API integrations or legacy SAML apps have trouble handling token expiration cleanly and benefit from a longer lifetime. This isn't a security improvement, but it can stabilize applications while you fix the underlying integration issue.

A few important scope clarifications:

Token lifetime policies apply to access tokens, ID tokens, and SAML assertions. They do not control refresh token lifetimes or session cookie lifetimes — those are managed through Conditional Access session controls (sign-in frequency and persistent browser session settings).
There is a minimum lifetime of 10 minutes for access tokens. You can't set it lower.
If a CA policy with sign-in frequency is in effect, that takes precedence over token lifetime policy in terms of when users are asked to re-authenticate. The token lifetime policy controls when the token itself expires, not when reauthentication is required.

Configurable token lifetimes documentation.

MIM 2016 Service Pack 3

Microsoft Identity Manager 2016 Service Pack 3 updates the supported platform matrix and adds one new deployment option. If you're not running MIM, you can skip this section — this is for organizations still using on-premises identity infrastructure for synchronization, PAM, or certificate management.

The new supported platforms in SP3:

Component	New support in SP3
SQL Server	SQL Server 2022
SharePoint Server	SharePoint Server Subscription Edition (SE)
Exchange Server	Exchange Server Subscription Edition (SE)
System Center Service Manager DW	SCSM DW 2022

The more interesting addition is the new deployment option for MIM Synchronization Service using Azure SQL Database with managed identity authentication. The traditional MIM deployment requires a SQL Server service account with specific permissions on the MIM database. That service account needs to be managed (password rotation, permissions audits, break-glass procedures). The Azure SQL + managed identity option removes that dependency entirely — the MIM Sync service authenticates to Azure SQL using its managed identity rather than a service account credential.

This is specifically relevant for organizations that have modernized other parts of their infrastructure to Azure but still run MIM Sync on-premises (or in an Azure VM) for synchronization scenarios that Entra Cloud Sync doesn't yet cover. Moving the MIM database to Azure SQL reduces the on-premises SQL Server footprint and removes a service account from the credential management scope.

Note: If you're currently running Entra Connect Sync (formerly Azure AD Connect), Microsoft has announced migration tooling to Entra Cloud Sync starting in July 2026. MIM and Entra Connect Sync are separate products — MIM covers more complex synchronization scenarios and won't be sunset on the same timeline. But if you're using Entra Connect Sync and haven't looked at Cloud Sync migration yet, July 2026 is when that process starts.

MIM 2016 documentation.

Workday termination prefetch for APAC timezone scenarios

This is a narrow fix, but if you've been dealing with it, it's been frustrating. The problem is specific to organizations using Workday-to-Entra provisioning in Asia-Pacific and Australasia time zones.

Workday defines a "reporting day" based on its own timezone configuration. When the Entra provisioning connector queries Workday for termination events, it looks at workers whose termination date matches the current date. The problem: for workers in APAC time zones whose last working day ends before midnight UTC (which is still daytime in APAC), the termination record appears on a different "reporting day" in Workday than the worker's actual last day. The provisioning cycle that runs the deprovisioning logic either misses the termination entirely on the correct day, or catches it on the following cycle — which could be 24 hours later.

The termination look-ahead setting fixes this by prefetching termination data ahead of the actual termination date. You configure a look-ahead window in hours (the documentation suggests 24–48 hours depending on how far your APAC offices are ahead of UTC). The provisioning connector pulls termination records that will become effective within that window and queues the deprovisioning actions to run at the right time, regardless of when Workday's reporting day boundary crosses relative to UTC.

The configuration is in the Workday provisioning app settings in Entra admin center, under the provisioning job configuration. The setting is called "Termination look-ahead window (hours)". There's no impact on employees in other time zones — the look-ahead only affects when data is fetched, not when actions are executed.

Workday termination look-ahead configuration.

External ID: social identity providers in native authentication

Social identity providers — Apple, Facebook, Google, and custom OIDC providers — are now GA in native authentication flows for External ID. If you're not building customer-facing apps on External ID, this section probably isn't relevant. But if you are, this closes what was the last significant gap in the native auth stack.

External ID supports two approaches for embedding sign-in into your application. The first is the redirect approach: you redirect the user to Entra's hosted sign-in page, auth happens there, and the user comes back to your app with a token. Standard OAuth2/OIDC flow, well-established, works everywhere.

The native authentication approach is different. Instead of redirecting the user out of your app, you build the sign-in UI directly into the app using Microsoft's MSAL SDK and a set of REST APIs. The user never leaves your app's visual context — the sign-in screen looks like part of your product, not like a Microsoft login page. The MSAL SDK communicates with External ID on the backend, but from the user's perspective they're interacting with your branded experience throughout.

Native authentication has been building out its feature set incrementally. Client credentials (M2M auth) went GA in January 2026. Username/alias sign-in and device code flow went GA in February 2026. Social identity providers are the latest addition. The combination means you now have a complete native authentication stack:

Email/password with SSPR
Passwordless email OTP
Social IdPs (Apple, Facebook, Google, custom OIDC)
Machine-to-machine (client credentials)
Device authorization flow (for smart TVs, IoT devices, etc.)
Username aliases (customer IDs, membership numbers, etc.)

All of these can be delivered without the user ever seeing a hosted Entra page.

When a user selects "Sign in with Google" (or Apple, or Facebook) in your native app, the MSAL SDK triggers a browser-delegated web-view rather than a native in-app experience. This is intentional and enforced by Conditional Access: social IdP sign-in must go through a secure system web-view because the social provider's SDK and the OAuth2 handshake require a full browser context. What changes compared to the traditional redirect approach is that your app initiates and controls the web-view — the user sees your branded context around the web-view frame rather than being fully redirected to a Entra hosted page, and your app receives the callback within the native SDK flow.

After the social IdP authentication completes, External ID receives the social provider's identity assertion, creates or looks up the corresponding External ID user account, and issues the External ID token to your app. Your app only ever deals with External ID tokens — you don't need to handle Apple, Google, or Facebook tokens or SDKs directly. External ID abstracts all of that.

The configuration is the same as social IdP setup in the redirect flow: in the External ID admin center, add the social identity provider under External Identities → All identity providers. The difference is that your native authentication user flow (or MSAL SDK configuration) now includes the social IdP option alongside email/password.

Native authentication concept documentation.

The preview batch

Part 3 covers the six features in public preview this month: Explicit Forward Proxy for Internet Access (the main new architectural addition for VDI and kiosk scenarios), account discovery for connected apps, the expanded SOC Security Operator role, per-app branding themes for External ID, OIDC federation between workforce and external tenants, and Microsoft Graph $count support for sign-in API queries.

There are also two operational announcements worth flagging from this month. First, Microsoft Entra Connect Sync migration to Cloud Sync starts in July 2026 — if you're still running Connect Sync, start reviewing the migration guidance now. Second, SCIM-based application provisioning is moving away from OAuth Authorization Code grant to client credentials and Workload Identity Federation. If you have provisioning integrations using the Authorization Code flow, check those before the deprecation date.