Microsoft Entra May 2026 — Part 3: Public Preview Features

Six things to watch in preview

This is Part 3 of the May 2026 Entra roundup. Part 1 covers the ten GA features in Global Secure Access and Certificate-Based Authentication. Part 2 covers the remaining GA features in Identity Governance, platform, and External ID. This post covers the six features that entered public preview — a couple of them are worth paying close attention to before they ship, because they'll affect how you architect internet access and identity operations.

Explicit Forward Proxy for Internet Access

This is the most architecturally interesting preview in the May 2026 batch. The problem it solves: Global Secure Access clients need to be installed on devices, which doesn't work for everything. Multi-session VDI environments can't use per-user agent installs. Kiosk machines run locked-down configurations. Linux desktops don't have a GSA agent. BYOD or lightly managed devices may have policy restrictions on agent installation.

The Explicit Forward Proxy handles these cases by acting as an HTTP/HTTPS proxy that browsers and apps can be pointed at. Traffic flows through the proxy into the Internet Access stack — web content filtering, AI Gateway inspection, prompt injection protection, threat intelligence — the same controls you'd get from the GSA client, reached through a different path. No agent installation on the endpoint.

Three specific device scenarios are called out in the preview docs:

• VDI and multi-session environments (Windows 365, AVD) where a single host serves many users simultaneously
• Kiosk and shared devices where the OS is locked and third-party software installs aren't allowed
• Linux desktops and browsers, plus BYOD devices with Microsoft Edge configured via Intune app policy

The EFP concept docs cover the architecture and prerequisites. Since this is preview, test it in non-production first — especially in VDI environments where proxy configuration can interact in unexpected ways with published applications.

How it actually works

When you enable Explicit Forward Proxy in the Entra admin center (under Global Secure Access → Connect → Traffic Forwarding Profiles), Entra provisions a proxy endpoint URL for your tenant. This is an HTTPS proxy address you configure in browsers or operating system proxy settings — the same way you'd configure any corporate proxy. Browsers that support PAC file distribution via Intune configuration profiles can receive the proxy settings automatically; devices you can't manage that way get configured manually.

Traffic sent through the proxy endpoint goes into the same Internet Access security policy stack as traffic from the GSA client. Web content filtering, AI Gateway inspection, and threat intelligence all apply. The policy is evaluated per your Global Secure Access web content filtering policies — no separate policy management for proxy traffic.

One important difference from the GSA client: with the agent, Entra knows exactly which user is generating the traffic because the agent authenticates with the user's Entra identity. With the Explicit Forward Proxy, the traffic arrives at the proxy without inherent user-level attribution. This is the core tradeoff:

• GSA client path: Full user identity context, user-specific policy evaluation, per-user sign-in log entries
• EFP path: No agent required, works in any browser/OS, but traffic is evaluated against broader policy rather than per-user policy. Conditional Access identity enforcement doesn't apply to EFP traffic the same way it does to client-authenticated traffic.

The VDI scenario in depth

Windows 365 and Azure Virtual Desktop with multi-session hosts are the clearest use case. Multi-session means a single Windows instance is shared by multiple users concurrently. You can't install a per-user GSA agent in that model — the agent would conflict across sessions. You could install it as a system-level service, but that creates its own complications with session isolation and user attribution.

With EFP, you configure the proxy at the VDI image level (Windows proxy settings or browser policy applied to the golden image). All browser traffic from any session on that host goes through the proxy endpoint. Web content filtering policies apply uniformly to all sessions. You don't get per-user traffic attribution in the sign-in logs, but you get policy enforcement — which for most VDI use cases (call centers, frontline workers, kiosk terminals) is the priority.

For Edge specifically, Intune can push the proxy configuration via a Managed Microsoft Edge device policy. This means you can configure EFP for managed BYOD or lightly managed devices through the Edge MDM policy without touching Windows proxy settings at all.

Current preview limitations

A few things EFP doesn't do yet in preview (these may change before GA):

• Private Access traffic (access to internal applications) doesn't route through EFP — that still requires the GSA client
• Microsoft 365 traffic optimization profiles don't apply to EFP-routed traffic
• Non-browser traffic (CLI tools, background apps, non-HTTP/HTTPS protocols) won't automatically route through the proxy unless explicitly configured

Account discovery for connected applications

Entra ID Governance can now generate discovery reports that show all accounts in a connected application — not just the accounts provisioned through Entra, but every account in the system including ones created manually, imported from another source, or left behind by users who departed. The report maps each discovered account to its Entra provisioning status: managed, unmanaged, or orphaned.

What "connected application" means here

A connected application in this context specifically means an application that has a provisioning integration configured in Entra — typically a SCIM-compatible SaaS app like ServiceNow, Salesforce, or Workday where you've set up the Entra provisioning connector. The account discovery feature calls the application's user list endpoint via SCIM and compares the response against what Entra's provisioning records show.

This is separate from access package governance or application registration. It's specifically about the provisioning surface — the accounts in the SaaS application's own user store and whether Entra created them, knows about them, or has lost track of them.

The three account buckets

The discovery report classifies accounts into three categories:

• Managed — provisioned through the Entra connector. These are in scope for normal governance: access reviews, lifecycle policies, automatic deprovisioning when the user leaves.
• Unmanaged — exist in the application but were not created by the Entra provisioning connector. Could be test accounts, service accounts created directly by an app admin, or accounts set up before the provisioning integration existed.
• Orphaned — no corresponding active Entra user. The person may have left the organization, their Entra account may have been disabled or deleted, or the provisioning connector missed a deprovisioning event.

The report is the starting point, not the end state. After discovery you have options: bring unmanaged accounts under governance by linking them to existing Entra identities (or flagging them for manual review), disable or delete orphaned accounts directly from the governance workflow, or scope access reviews to the unmanaged and orphaned populations so business owners can make the call rather than IT acting unilaterally.

Most organizations accumulate years of shadow accounts in SaaS applications — test accounts, service accounts created directly in the app, accounts for people who left before a formal offboarding process was in place. Getting a structured view of that in one report rather than a manual export-and-compare exercise across each application is the practical value.

Account discovery documentation.

Security Operator role expansion

The Entra Security Operator role is getting direct identity response capabilities. The current problem: during an active incident, a SOC analyst who spots a compromised account can't act on it directly in Entra. They have to escalate to an Entra administrator who holds the required roles. That escalation step — open a ticket, wait for the admin to notice, admin logs in, takes the action — introduces a delay that's measurable in minutes and can be 20 minutes or longer outside business hours.

For a credential-based attack that pivots quickly once it has a valid session, 20 minutes is the difference between containment and a full environment compromise.

What the expanded role can do

The preview extends Security Operator with five identity response actions:

• Disable user accounts — block sign-in immediately without deleting the account (preserves the audit trail and mailbox)
• Revoke active sessions — invalidate all current refresh tokens; forces reauthentication on next request across all apps
• Mark user as compromised — sets the user risk to "high" in Identity Protection, which triggers any risk-based Conditional Access policies you have configured (typically forces password change and MFA)
• Force password reset (cloud-only accounts) — directly resets the password on cloud-only accounts; does not apply to synchronized accounts (those need on-premises reset)
• Delete specific authentication methods — remove a registered FIDO2 key, phone number, or authenticator app that may have been registered by an attacker

Scope and constraints

The Security Operator role's new actions are scoped to non-admin users only. The role cannot act on accounts holding any Entra administrator role (including Global Administrator, Privileged Role Administrator, User Administrator, etc.). This prevents privilege escalation: a Security Operator can't disable or reset a Global Admin account, even during an incident.

The permissions surface for these actions is through Microsoft Defender unified RBAC, not through the Entra admin center role assignment. That means:

• You assign the expanded Security Operator permissions in Microsoft Defender XDR → Settings → Microsoft Defender XDR → Permissions → Roles
• The actions are available in the Defender portal's incident timeline and user entity pages, as well as the Entra admin center once the role has been assigned
• SOC analysts don't need Entra admin center access at all to use these capabilities — they stay in Defender's incident workflow

What the Security Operator can and cannot do

Security Operator role permissions reference.

Per-app branding themes

Entra now supports multiple named branding themes, each assignable to a specific application. The existing tenant-wide branding configuration stays in place as the default, but you can create per-app themes that override it for specific application sign-in experiences.

What you can customize

Each theme can configure the following independently:

• Logo (shown on the sign-in page and in the top-left corner)
• Favicon
• Background image or solid color
• Header/banner color
• Sign-in page text (headline and body copy above the sign-in form)
• Footer text
• Error page text

Themes are created in Entra admin center under Company Branding → Branding Themes. The portal includes a Live Preview panel that shows what the sign-in page will look like as you edit, without having to save and test-sign-in each time.

How to assign a theme to an application

Once you've created a theme, you assign it to an application through the app registration or Enterprise Application blade. Under Branding → Branding Theme, select the named theme. From that point on, any sign-in that routes through that application uses the theme you've configured instead of the tenant default.

This applies to both workforce tenant applications and External ID external tenants. For workforce tenants, the common use case is distinguishing between internal tooling (which uses the corporate IT branding) and a customer-facing portal or partner portal (which should look like your product, not your IT department). For External ID, the use case is having a single external tenant serve multiple consumer products with distinct brand identities.

Practical example: a company runs two consumer products — a subscription service and a loyalty program — both backed by the same External ID tenant. Before per-app branding themes, both products showed the same generic tenant-level sign-in page. With themes, the subscription service sign-in shows that product's logo, color scheme, and sign-in text, while the loyalty program shows its own branding. The user experience is fully product-specific even though the underlying identity infrastructure is shared.

Per-app branding themes docs.

OIDC federation between workforce and external tenants

External Entra ID tenants can now federate with a workforce Entra ID tenant using OIDC. The scenario: your employees need to sign in to a customer-facing application (hosted in your external tenant) using their existing corporate credentials from your workforce tenant. Without federation, you'd need to create a separate account in the external tenant for each employee who needs access — a second identity that needs to stay synchronized with the source in your workforce tenant.

How this differs from B2B guest access

B2B guest access is a different mechanism for the same general problem. With B2B, you invite the employee as a guest user into the external tenant. A guest account is created in the external tenant that points back to the source. The guest account is a real object that has its own lifecycle — you have to manage invitations, redemptions, and removal when the person leaves.

OIDC federation is lighter. There's no guest account object created. Instead, you configure the external tenant to trust the workforce tenant as an OIDC identity provider. When a user signs in to the external-tenant-hosted application, they're redirected to the workforce tenant for authentication. The workforce tenant issues a token, the external tenant validates it through the OIDC trust, and the user gets access. The external tenant never needs to know about each individual user — it just trusts the workforce tenant's assertions.

Configuration path

The setup is done in the external tenant's admin center:

1. In the external tenant, go to External Identities → All identity providers
2. Add a new identity provider and select "Entra ID workforce tenant"
3. Enter the workforce tenant's domain or tenant ID
4. The external tenant discovers the workforce tenant's OIDC configuration automatically from the well-known metadata endpoint
5. Save, then assign the federation to the relevant user flows or authentication policies

Claims from the workforce tenant's token are mapped to the external tenant's user profile attributes. You configure which claims to accept and how to map them (display name, email, UPN, etc.) in the identity provider settings.

The combined scenario this enables: a single application that serves both external customers (who have accounts in the external tenant) and internal employees (who authenticate via OIDC federation through the workforce tenant). No duplicate accounts, no synchronization jobs.

Configure Entra ID federation for external tenants docs.

Microsoft Graph $count for sign-in log queries

The Microsoft Graph sign-in API (/auditLogs/signIns) now supports the $count query parameter in preview. This is a smaller but genuinely useful developer-facing change: you can get a count of sign-in records matching a filter without fetching the full result set.

How to use it

The $count parameter on advanced query APIs in Graph requires the ConsistencyLevel: eventual request header. Without it, the server returns an error. The eventual consistency caveat means the count may be slightly stale — the index that powers count queries is eventually consistent with the underlying data store, so you might see a count that's off by a small number for very recent data.

A sample request:

GET https://graph.microsoft.com/v1.0/auditLogs/signIns?$count=true&$filter=userPrincipalName eq 'user@contoso.com' and createdDateTime ge 2026-05-01T00:00:00Z
ConsistencyLevel: eventual

The response includes an @odata.count property alongside the first page of results (or just the count if you add $top=0 to suppress result data). You can combine $count with $filter, $select, $orderby, and $top.

Why this matters for tooling

Before this, if you wanted to know "how many failed sign-ins did this user have in the last 7 days?", you had to either: pull all matching records page by page and count them in application code, or use the $top=1&$count=true workaround that returned a count alongside a single record. That worked for some queries but wasn't reliable across all filter combinations and was obviously a workaround.

The practical use: building dashboards or monitoring tools that show sign-in volume metrics without downloading gigabytes of log data. Count the events server-side, pull full records only when you need them for detail.

Advanced query capabilities in Microsoft Graph.

Two operational announcements

May 2026 also included two forward-looking announcements that aren't new features but affect existing configurations — worth flagging because both have action items.

Entra Connect Sync migration to Cloud Sync starts July 2026

Microsoft is beginning the migration from Entra Connect Sync to Cloud Sync starting in July 2026. If you're still running Connect Sync, you should start reviewing what the migration path looks like for your specific topology now, rather than when the migration tooling arrives.

Things to check before migrating:

• Attribute write-back — Cloud Sync supports group write-back and device write-back, but the coverage isn't identical to Connect Sync. Verify that the attributes you write back from Entra to on-premises AD are supported in Cloud Sync.
• Complex sync rules — if you have custom attribute flow rules or transformation expressions in the Connect Sync rule editor, check whether Cloud Sync's attribute mapping expressions cover the same logic.
• Unsupported topologies — Connect Sync supports multiple on-premises AD forests connecting to a single Entra tenant. Cloud Sync also supports this, but specific multi-forest configurations may have limitations in the current Cloud Sync version.
• Exchange hybrid — if you're running Exchange hybrid, verify the hybrid configuration requirements for Cloud Sync before migrating.

Migration guide from Entra Connect Sync to Cloud Sync.

SCIM provisioning: Authorization Code grant retiring

SCIM-based application provisioning is moving away from the OAuth 2.0 Authorization Code grant flow to client credentials and Workload Identity Federation. The Authorization Code flow requires a user to authenticate interactively to authorize the provisioning connector, which creates issues with token expiration, re-authorization requirements, and service accounts. Client credentials and Workload Identity Federation are better suited for service-to-service provisioning scenarios.

To check whether you're affected: in Entra admin center, go to Enterprise Applications, find each application with a provisioning job configured, and check the provisioning connector's authentication method under Provisioning → Admin Credentials. If any show OAuth Authorization Code flow as the authentication method, those will need to be updated before the deprecation deadline.

What shipped GA

Part 1 covers Global Secure Access (network content filtering, prompt injection protection for AI traffic, iOS client GA, Cloud Firewall, external user access controls, and branch office remote network configuration) and Certificate-Based Authentication (issuer hints, iOS native auth, PRT support on iOS, and CA group scoping). Part 2 covers Identity Governance (approver visibility in My Access, PIM + Conditional Access authentication contexts, license usage tracking), platform (configurable token lifetimes, MIM 2016 SP3, Workday termination prefetch), and External ID native authentication with social identity providers.

Share this: