Microsoft Entra Tenant Governance and User-centric Access Reviews are now generally available, according to Microsoft’s September 2026 Entra roundup. That designation matters, but it should not be read as a guarantee of an immediate security improvement. General availability means the services are available as products; whether they reduce risk depends on how an organization scopes relationships, establishes configuration baselines, assigns responsibility, and acts on what the tools reveal.
At the same time, Microsoft has put a hard deadline on one preview-era dynamic-membership capability, announced a correction to the effective reach of a widely used Graph permission, and expanded incident-response actions for Security Administrators. Those changes can affect Windows and Microsoft 365 environments even when the work is carried out in Entra rather than on a Windows endpoint.
Tenant Governance addresses tenant sprawl, not just app discovery
Tenant Governance reached general availability on August 10, 2026, and Microsoft includes it among the capabilities that became generally available since August. Its purpose is multi-tenant governance: helping an organization gain visibility across Entra tenants and assess whether they meet security and compliance expectations.
That description is important because it corrects a tempting but incomplete interpretation of the feature. Tenant Governance is not chiefly an inventory of applications and services connected to a primary tenant. Application-related signals can help identify a relationship, but the core unit of governance is the Entra tenant itself.
Microsoft describes related tenants as potentially including internally created tenants, shadow-IT tenants, development tenants, and partner or customer tenants. Discovery provides situational awareness, however, rather than ownership or enforcement. In practical terms, seeing a tenant relationship does not give a central IT team administrative authority over that tenant, prove that the tenant is corporate-owned, or automatically remediate a configuration problem.
The distinction is useful for organizations that have accumulated separate tenants through mergers, regional operations, testing, independent business units, or employees starting cloud trials outside established procurement. A discovered tenant should begin a governance conversation, not trigger an assumption that it can be centrally controlled.
Microsoft frames the feature around several associated tasks: discovering related and shadow-IT tenants, setting governance relationships, monitoring configuration drift against a baseline, and controlling the creation of new add-on tenants. A sensible deployment sequence therefore starts with validation:
- Identify which discovered tenants are genuinely related to the organization and which are external partners or customers.
- Assign a business owner and technical contact to each internal tenant.
- Define which settings constitute a minimum security and compliance baseline before interpreting drift as a defect.
- Decide which tenant types may be created and who may approve them.
- Establish an escalation path for tenants that are related but outside direct administrative control.
This is governance work as much as it is identity work. A security team can identify a shadow tenant, but legal, procurement, privacy, and business owners may be needed to determine whether it should be brought under corporate administration, retired, or treated as an external entity with a more limited relationship.
There is also a counterargument to broad discovery initiatives: an expansive list of loosely associated tenants can create noise, false assumptions, and extra operational burden. Microsoft’s own point that related-tenant information is awareness rather than ownership supports a measured approach. Organizations should prioritize tenants that have shared users, shared administration, business data, production workloads, or a plausible path for privileges to cross boundaries.
GA access-governance features still require process discipline
User-centric Access Reviews is also listed as generally available. The name and placement make the direction clear: Microsoft is adding another access-governance capability at a time when organizations are under pressure to reevaluate who retains access as job roles, projects, and tenant relationships change.
But organizations should separate product availability from demonstrated outcomes. The available material supports the feature’s availability and Microsoft’s governance rationale; it does not establish that deploying it will, by itself, reduce excessive permissions, lower incident rates, or deliver a measurable least-privilege result in every environment.
The difficult parts of access review remain organizational. A reviewer needs enough business context to judge whether access is still justified. An application owner must be accountable for the outcome. Review campaigns need a defined cadence and escalation policy. And removals must be tested against operational dependencies, particularly for shared Windows administration, line-of-business applications, service identities, and emergency access arrangements.
For Windows administrators, this is especially relevant where Entra roles and groups influence access to Microsoft 365, Azure resources, device-management systems, or cloud-integrated applications. A review that merely collects approvals can create a paper trail without meaningfully changing authorization. A review designed around high-impact groups, privileged roles, stale project access, and inactive guest relationships is more likely to find material risk.
A practical first phase is to focus on a small number of high-value scenarios rather than attempting a tenant-wide recertification immediately. Examples include privileged cloud roles, groups granting access to sensitive collaboration sites, accounts associated with departed contractors, and guest access to business-critical resources. The goal should be reliable ownership and timely decisions before expanding the scope.
A November deadline can leave dynamic access stale
The most urgent announced change is the retirement path for configurations using the MemberOf rule operator in dynamic membership groups, dynamic administrative units, and entitlement-management auto-assignment policies. Organizations must remove or replace these configurations before November 3, 2026.
After that date, affected configurations do not merely produce a warning or lose an optional enhancement. They stop updating and remain in their last known state.
That behavior creates two opposite but equally serious risks. A person who should gain access after a qualifying group change may not receive it, interrupting onboarding, transfers, project access, or administrative delegation. Conversely, a person who should lose access may remain in a group, administrative scope, or auto-assigned entitlement because the rule no longer reevaluates. The latter is a direct least-privilege concern; the former can drive hurried manual exceptions that become security debt of their own.
The MemberOf operator was a preview capability, and it was not a sound foundation for production access paths with strict reliability requirements. The migration should be treated as a controlled identity change, not a last-minute rule edit. Administrators should inventory every affected dynamic group, dynamic administrative unit, and entitlement-management policy; document the business purpose and downstream access impact; identify a supported replacement design; and validate the replacement using representative joiner, mover, and leaver scenarios.
It is also worth checking whether multiple systems depend on the same dynamic objects. A single Entra group can affect Teams membership, SharePoint permissions, application assignment, device-management targeting, or conditional administrative processes. Changing the rule may preserve one intended use while inadvertently changing another.
Organizations should retain a record of the final MemberOf-driven state and establish monitoring for unexpected membership changes during migration. Since affected configurations will otherwise remain frozen at their last known state, teams need a clear way to distinguish a deliberate static exception from a formerly dynamic object that is no longer processing.
Graph permission correction calls for app-impact testing
Microsoft has also said that User.ReadBasic.All unintentionally permits reading users’ app-role assignments and license details, and that it will remove that access. Its permissions documentation describes User.ReadBasic.All as limited to basic profile properties for other work or school accounts, such as names, identifiers, email-related profile data, and a photo.
The announced correction brings the effective behavior closer to that documented scope. Microsoft advises applications that need app-role assignments to use User.Read.All, and those that need license-detail access to use LicenseAssignment.Read.All. Where an application genuinely needs both types of data, Microsoft says User.Read.All is sufficient.
The security logic is straightforward: an application granted a basic-profile permission should not depend on access to role-assignment or licensing information that exceeds the stated purpose of that permission. But the operational impact can be awkward. Internally developed scripts, reporting tools, help-desk workflows, provisioning connectors, and SaaS integrations may have been built around the existing behavior without requesting the permissions that reflect their actual data needs.
Microsoft has not provided, in the material available here, a specific enforcement date, public vulnerability identifier, or evidence of exploitation. That uncertainty is a reason to prepare rather than panic. It is not a reason to postpone assessment.
Application owners should identify workloads consented to User.ReadBasic.All, determine whether they read app-role assignments or license details, and test their behavior with the permissions Microsoft now recommends. Administrators should not automatically add broader permissions everywhere. Each request should be justified against the app’s function, consent model, data exposure, and ownership. In many cases, the correct response may be to reduce the data the application collects rather than to expand its Graph authorization.
Security Administrator gains faster identity-response actions
Microsoft is expanding the Security Administrator role with actions for non-privileged users: disabling or enabling accounts, revoking active sessions, and forcing password resets. Microsoft said rollout was planned to complete by the end of September 2026; as of the September 2 announcement date, that does not establish that every tenant has the change already.
The expansion can shorten the response loop when a security analyst identifies suspected account compromise. Previously, a handoff to a separate identity-administration team might delay containment. Revoking sessions and disabling a standard user account are often among the first steps in a cloud identity incident.
The limits are as important as the benefit. The stated scope is non-privileged users, so organizations should not assume Security Administrators receive unrestricted authority over powerful administrative identities. Role assignment should still follow separation-of-duties principles, with logging, incident procedures, and periodic review of who can take disruptive account actions.
For help desks and security operations teams, a clear runbook should distinguish a password reset from session revocation, account disablement, and account re-enablement. A reset may not instantly invalidate every established session; a session revocation may be required in a suspected token-theft or active-session scenario. Conversely, disabling an account can disrupt an employee’s access to Windows-integrated cloud services and other business tools, making communication and recovery procedures important.
Preview features: useful to evaluate, risky to assume
Two other additions require a more cautious label. Enhanced synchronization of sAMAccountName from onPremisesSamAccountName into Microsoft Entra Domain Services is in public preview. It requires Enterprise or Premium Entra Domain Services SKUs. Existing managed domains must enable the behavior, while new-domain behavior is documented separately.
For hybrid organizations, consistent account-name behavior can matter for legacy applications and environments still dependent on traditional Windows naming conventions. Yet the preview status and SKU requirements mean this should be evaluated in a controlled setting before it becomes part of a production identity design. Teams should test naming collisions, application dependencies, directory synchronization effects, rollback options, and the differing behavior between an existing managed domain and a newly created one.
The Global Secure Access MCP firewall is also in preview. Microsoft describes it as providing centralized visibility, policy enforcement, and runtime protection for Model Context Protocol traffic between AI agents and remote MCP servers. The company explicitly warns that the prerelease product may change substantially before release.
This is a notable signal for organizations experimenting with AI agents that call external tools or services. Identity and network controls must increasingly account for machine-driven requests, delegated access, and tool connections that may not fit older application patterns. Still, a preview firewall should not be treated as the sole protection for agent workflows. Teams should maintain conventional safeguards: narrow credentials, explicit service ownership, logging, approval gates for sensitive actions, and careful evaluation of what data or commands an agent can reach.
Passwordless shared spaces need a staged migration plan
Microsoft is also enabling passwordless Teams shared-space resource accounts through secure device-bound credentials rather than stored username-and-password credentials. This can reduce the risk associated with a static account password used by a shared meeting-room device.
The detail that matters for deployment is that migration is administrator-initiated and optional. It is not a password-free initial provisioning model: devices must initially be deployed through the existing username-and-password approach before transition to the new credential model.
Facilities, endpoint, collaboration, and identity teams should coordinate before changing room systems. Inventory which devices use shared-space resource accounts, confirm the existing deployment process, schedule conversion during a maintenance window, and ensure there is a recovery procedure for a failed credential transition. In a meeting-room context, reliability remains a security concern: an account model that is safer but leaves rooms unusable without a documented recovery path will encourage unmanaged workarounds.
The immediate priority is configuration hygiene
The Entra announcements point to a broad transition: identity governance is expanding from reviewing users and groups to governing tenant relationships, application permissions, device credentials, and emerging AI-agent connections. That does not mean every organization should deploy every new control at once.
The sensible near-term order is clearer. First, find and replace every MemberOf-based dynamic configuration before the November deadline. Second, assess applications that may be relying on User.ReadBasic.All beyond its intended basic-profile scope. Third, verify whether Security Administrator’s new response actions have reached the tenant and update incident runbooks accordingly. Then use Tenant Governance and the generally available access-governance capabilities to build sustainable ownership, baselines, and review processes.
The preview features merit structured evaluation, particularly where hybrid identity or AI-agent projects are already underway. But they should remain pilots until an organization has tested their operational implications and accepted the possibility of product change. In identity security, the largest gains often come not from enabling the newest feature, but from ensuring that existing permissions, groups, tenants, and response roles behave exactly as administrators think they do.