rss.livelink.threads-in-node

What’s new in Microsoft Entra – March 2026

ShobhitSahay — Wed, 15 Apr 2026 17:13:19 GMT

From January through March 2026, Microsoft Entra introduced key updates to help organizations strengthen identity security, simplify governance, and improve user experience. This Q1 roundup highlights the latest feature releases and important changes—organized by product—so you can quickly see what’s new, what’s changing, and what actions you may need to take.

Microsoft Entra ID

New releases

Change announcements

Security improvements

Jailbreak detection in Authenticator app

[Action may be required]

Starting February 2026, Microsoft Authenticator introduced jailbreak/root detection for Microsoft Entra credentials in the Android app. The rollout progresses from warning mode → blocking mode → wipe mode. Users must move to compliant devices to continue using Microsoft Entra accounts in Authenticator. Learn more.

Microsoft Entra Agent ID

Change announcements

Simplifying agent management with Agent 365

[Action may be required]

We’re consolidating agent management experiences to make it easier to observe, govern, and secure all agents in your tenant. Agent 365 will be the single source of truth, offering a unified catalog, consistent visibility, and simplified management.

What’s changing

The Agent registry and Agent collections blades in the Entra admin center will be retired on May 1, 2026.
No action is required by administrators. Agent functionality and management remain unaffected. You can still access the agent inventory in the All agents view within the Microsoft 365 admin center (MAC).

With this change:

Agent 365 becomes the unified registry and control plane for agents.
Microsoft Entra continues to provide the identity foundation through Agent ID.
The existing registry Graph API will be deprecated and replaced by a new API powered by Agent 365. Agents registered via the current API will need to be re-registered. You'll be notified soon about the deprecation date and the availability of the new registry Graph API.
All agent access and governance capabilities remain fully available through Agent ID and Agent 365.

Learn more.

Microsoft Entra ID Governance

New releases

Change announcements

Identity Modernization

Microsoft Entra Connect security update to block hard match for users with Microsoft Entra roles

[Action may be required]

What is hard matching in Microsoft Entra Connect Sync and Cloud Sync?

When Microsoft Entra Connect or Cloud Sync adds new objects from Active Directory, the Microsoft Entra ID service tries to match the incoming object with a Microsoft Entra object by looking up the incoming object’s sourceAnchor value against the OnPremisesImmutableId attribute of existing cloud managed objects in Microsoft Entra ID. If there's a match, Microsoft Entra Connect or Cloud Sync takes over the source or authority (SoA) of that object and updates it with the properties of the incoming Active Directory object in what is known as a "hard match."

To strengthen the security posture of your Microsoft Entra ID environment, we are introducing a change that will restrict certain types of hard match operations by default.

What’s changing

Beginning June 1, 2026, Microsoft Entra ID will block any attempt by Microsoft Entra Connect Sync or Cloud Sync from hard-matching a new user object from Active Directory to an existing cloud-managed Microsoft Entra ID user object that hold Microsoft Entra roles.

This means:

If a cloud managed user already has onPremisesImmutableId (sourceAnchor) set and is assigned a Microsoft Entra role, Microsoft Entra Connect Sync or Cloud Sync will no longer be able to take over the Source of Authority of that user by hard-matching with an incoming user object from Active Directory.
This safeguard prevents attackers from taking over privileged cloud managed users in Microsoft Entra by manipulating attributes of user objects in Active Directory.

What’s not changing

Hard match operations for cloud users without Microsoft Entra roles are not affected.
Soft match behavior isn't affected.
Ongoing sync from Active Directory to Entra ID for previously hard-matched objects will not be affected.

Customer action required

If you encounter a hard match error after June 1, 2026, see our documentation for mitigation steps.

Learn more.

Microsoft Entra External ID

New releases

Global Secure Access

New releases

-Shobhit Sahay

Learn more about Microsoft Entra

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

MFA Options for Employees without Phones

FabianUni — Wed, 15 Apr 2026 12:00:35 GMT

Hello everbody,

we're currently trying to implement MFA in our company, but approximately 1/10 of our employees have a workphone and are not allowed to use their personal phone.

Since we also recently introduced Intune, the idea was to just use Windows Hello for Business, but when trying to provision it, we realized that you need to have MFA active for an account to be able to even activate it? Which kinda defeats the purpose.

So my question is, is there some way to circumvent the MFA requirement for WHfB? Or what other options do we realistically have?

Thanks in Advance!

Hybrid Join Lifecycle Model

Menahem — Tue, 14 Apr 2026 11:32:08 GMT

Microsoft Entra hybrid join is still a common reality in enterprise environments.

For many organizations, it remains necessary because legacy applications still rely on Active Directory machine authentication, Group Policy is still in use, and on-premises operational dependencies have not fully been retired. At the same time, the long-term direction for endpoint identity is increasingly cloud-native.

That creates an important architectural question:

Should hybrid join be treated as a permanent device state, or as a lifecycle stage in a broader modernization journey?

In practice, hybrid join is often discussed as a binary condition: the device is either hybrid joined or it is not. But from an operational perspective, that view is too limited.

In real enterprise environments, hybrid join behaves much more like a lifecycle.

A device moves through provisioning, registration, trust establishment, management attachment, steady-state operation, recovery, retirement, and eventually transition.

That distinction matters because most hybrid join issues do not fail loudly. They usually appear as stale objects, pending registrations, broken trust, inconsistent management ownership, and environments that remain temporarily hybrid far longer than intended.

Why a lifecycle model is useful

Treating hybrid join as a lifecycle helps explain why so many organizations struggle with it even when the initial implementation appears technically correct.

The challenge is usually not the first successful join. The challenge is everything that happens around it:

Provisioning quality
Trust validation
Management ownership
Drift detection
Stale object cleanup
Exit criteria for transition to Entra join

Without that lifecycle view, hybrid join often becomes a static design decision with no clear operational model behind it.

The eight phases

1. Provisioning

The lifecycle starts when the device is built, imaged, or provisioned.

This stage is more important than it looks. If the device is provisioned from a contaminated image, or if cloning and snapshot practices are not handled carefully, later identity issues are often inherited rather than newly created.

Provisioning should be treated as an identity-controlled event, not just an OS deployment task.

2. Registration

The device becomes known to Microsoft Entra.

This is where many environments confuse visibility with readiness. A device object may exist in the cloud, but that does not automatically mean the hybrid identity state is healthy or operationally usable.

3. Trust Establishment

This is the point where hybrid join becomes real.

A device should not be considered fully onboarded until both sides of trust are present and healthy. In operational terms, this means the device is not only registered, but also capable of supporting the expected sign-in and identity flows.

4. Management Attachment

Once trust exists, governance becomes the next question.

Many organizations still balance Group Policy, Configuration Manager, Intune, and legacy application dependencies at the same time. That is exactly why hybrid join often persists.

But if management ownership is not clearly defined, organizations end up with overlapping policy planes, inconsistent control, and unclear accountability.

5. Operational Steady State

Hybrid join does not stop at successful registration.

The device must remain healthy over time, and that means monitoring trust health, registration state, token health, line-of-sight to required infrastructure, and management consistency.

A device that was healthy once is not necessarily healthy now.

6. Recovery

Every real environment eventually encounters drift.

Pending states, broken trust, orphaned records, reimaged devices, and inconsistent registration scenarios should not be treated as unusual edge cases. They should be expected and handled with formal recovery playbooks.

Recovery is not an exception to the lifecycle. It is part of the lifecycle.

7. Retirement

Retirement is one of the weakest areas in many hybrid environments.

Devices are replaced or decommissioned, but their identity records often remain behind. That leads to stale objects, inventory noise, and administrative confusion.

A proper lifecycle model should include a controlled retirement sequence rather than ad hoc cleanup.

8. Transition

This is the most important strategic phase.

The key question is no longer whether a device can remain hybrid joined, but whether there is still a justified reason to keep it there.

Hybrid join may still be necessary in many environments today, but in many cases it should be treated as transitional architecture rather than the target end state.

Practical takeaway

Looking at hybrid join as a lifecycle creates a more useful framework for architecture decisions, operational ownership, troubleshooting, directory hygiene, governance, and transition planning toward Microsoft Entra join.

That is the real value of this model.

It does not replace technical implementation guidance, but it helps organizations think more clearly about why hybrid join exists, how it should be operated, and when it should eventually be retired.

Final thought

Hybrid join is still relevant in many enterprise environments, but it should not automatically be treated as a default destination.

In many cases, it works best when it is managed as a lifecycle-driven operating model with defined phases, controls, and exit criteria.

That makes it easier to stabilize operations today, while also creating a clearer path toward a more cloud-native endpoint identity model tomorrow.

Full article:

Hybrid Join Lifecycle Model

Microsoft Entra · Device Identity Hybrid Join Lifecycle Model Hybrid join is not a destination - it is a lifecycle stage. Understanding each phase, from provisioning to retirement, is what separates a stable identity posture from an environment full of stale objects, broken trust, and unresolved dependencies.

www.modernendpoint.tech

Advice required for temp / agency staff

StuartK73 — Mon, 13 Apr 2026 15:05:38 GMT

Hi All

I hope you are well.

Anyway, I'm hoping someone can point me in the right direction.

We have Android devices in Entra Shared Device Mode (Multi App) which any of our employees with a valid UPN can logon to.

All good there.

What we need is a solution for temporary or agency staff. This would be staff that could be called on at very short notice and may not stay around for long.

For security and audit reasons, we'd rather not create "userless" accounts.

Is there anything in Entra / Entra Shared Device Mode that can achieve this?

Info greatly appreciated.

Understand Why a Service Principal Was Created in Your Entra Tenant

milgo — Thu, 09 Apr 2026 08:22:36 GMT

Are you a tenant admin or member of a security team in your organization and find yourself asking “Why was this service principal created in our tenant?”

Historically, answering this required correlating audit logs with Microsoft Graph queries or going through long investigations. Microsoft Entra now introduces enhanced audit log properties that make it significantly easier to understand the origin and intent behind newly created service principals directly from tenant audit logs. These new improvements surface additional insights within the Add service principal activity under the ApplicationManagement category—helping administrators determine whether a service principal was provisioned automatically by Microsoft services, triggered by a purchased subscription, or explicitly created by user or application activity.

What’s in it for me as an Admins or member of the Security Team
When a service principal is created, new metadata is now captured within Microsoft Entra audit logs that enables faster root‑cause analysis. These properties help distinguish between Microsoft‑driven provisioning processes and tenant‑initiated actions, allowing teams to quickly assess whether an event is expected platform behavior or something requiring deeper investigation.

For example, administrators can now:

Identify provisioning initiated by Microsoft services versus internal users or automation.
Determine which tenant subscription or service plan enabled just‑in‑time provisioning.
Recognize provisioning linked to Azure resource onboarding or managed identities.
Investigate service principal creation without relying on additional Graph lookups.

By leveraging these enriched audit logs, security teams can streamline investigations into newly created enterprise applications and reduce manual dependency on downstream data sources. This ultimately improves visibility into application onboarding events and supports faster decision‑making when assessing potential risk or unexpected provisioning activity within the tenant.

Learn more here- Understand why a service principal was created in your tenant - Microsoft Entra ID | Microsoft Learn

Entra CBA Preview Bug: Issuer Scoping Policy fails group claim (AADSTS500191)

alejlw — Sat, 04 Apr 2026 14:46:33 GMT

I am deploying a zero-trust, cloud-native Certificate-Based Authentication (CBA) architecture for a break-glass emergency access account in Microsoft Entra ID. I am intentionally bypassing Intune/MDM to prevent circular dependencies during an outage.

The PKI is generated via OpenSSL (Offline Root CA -> Client Cert). The cryptography is flawless:

- The OpenSSL chain verifies perfectly (openssl verify -CAfile...).

- The Root SKI and Client AKI are a perfect 1:1 hex match.

- The client cert EKU includes TLS Web Client Authentication.

- The client cert SAN includes othername: UPN::[break-glass-UPN].

- The Root CA and CRL are uploaded to Entra and publicly accessible via Azure Blob Storage.

The Issue:

When I attempt to restrict the Root CA using the "Certificate issuer scoping policy (Preview)" targeted to a specific Security Group (e.g., sg_cba), the TLS handshake drops and Entra throws:

Error: AADSTS500191: The certificate authority that issued your certificate has not been set up in the tenant.

Troubleshooting Performed:

1. Group Architecture: Verified via Microsoft Graph that the user is a direct, static member of sg_cba (Security Enabled, non-dynamic, not nested).

2. Micro-Group Bypass: Created a brand-new cloud-only micro-group with only the break-glass user. Waited for replication. Same 500191 error.

3. The Control Test (Success): If I completely remove the Preview scoping policy and move the targeting to the Generally Available (GA) tenant-wide trust ("All Users"), the login succeeds immediately. (I am securing this via High-Affinity binding matching the SKI to CertificateUserIDs).

The Ask:

Because the tenant-wide GA policy works perfectly, it mathematically proves the certificates, CRL, and bindings are correct. The failure is entirely isolated to the Preview scoping engine failing to correlate the incoming certificate to the Security Group claim fast enough.

- Has anyone successfully deployed the "Certificate issuer scoping policy (Preview)" using a targeted security group without it dropping the trust?

- Are there undocumented constraints on group evaluation during the CBA TLS handshake that cause this Preview feature to fail closed?

Introducing the Entra Helpdesk Portal: A Zero-Trust, Dockerized ITSM Interface for Tier 1 Support

jahmed_cloud — Fri, 03 Apr 2026 09:46:13 GMT

Hello everyone,

If you manage identity in Microsoft Entra ID at an enterprise scale, you know the struggle: delegating day-to-day operational tasks (like password resets, session revocations, and MFA management) to Tier 1 and Tier 2 support staff is inherently risky.

The native Azure/Entra portal is incredibly powerful, but it’s complex and lacks mandatory ITSM enforcement. Giving a helpdesk technician the "Helpdesk Administrator" role grants them access to a portal where a single misclick can cause a major headache.

To solve this, I’ve developed the Entra Helpdesk Portal (Community Edition)—an open-source, containerized application designed to act as an isolated "airlock" between your support team and your Entra ID tenant.

Why This Adds Value to Your Tenant

Instead of having technicians log into the Azure portal, they log into this clean, Material Design web interface. It leverages a backend Service Principal (using MSAL and the Graph API) to execute commands on their behalf.

Strict Zero Trust: Logging in via Microsoft SSO isn’t enough. The app intercepts the token and checks the user’s UPN against a hardcoded ALLOWED_ADMINS whitelist in your Docker environment file.
Mandatory ITSM Ticketing: You cannot enforce ticketing in the native Azure Portal. In this app, every write action prompts a modal requiring a valid ticket number (e.g., INC-123456).
Local Audit Logging: All actions, along with the actor, timestamp, and ticket number, are written to an immutable local SQLite database (audit.db) inside the container volume.
Performance: Heavy Graph API reads are cached in-memory with a Time-To-Live (TTL) and smart invalidation. Searching for users or loading Enterprise Apps takes milliseconds.

What Can It Do?

Identity Lifecycle: Create users, auto-generate secure 16-character passwords, revoke sign-in sessions, reset passwords, and delete specific MFA methods to force re-registration.
Diagnostics: View a user's last 5 sign-in logs, translating Microsoft error codes into plain English.
Group Management: Add/remove members to Security and M365 groups.
App/SPN Management: Lazy-load raw requiredResourceAccess Graph API payloads to audit app permissions, and instantly rotate client secrets.
Universal Restore: Paste the Object ID of any soft-deleted item into the Recycle Bin tab to instantly resurrect it.

How Easy Is It to Setup?

I wanted this to be universally deployable, so I compiled it as a multi-architecture Docker image (linux/amd64 and linux/arm64). It will run on a massive Windows Server or a simple Raspberry Pi.

Setup takes less than 5 minutes:

Create an App Registration in Entra ID and grant it the necessary Graph API Application Permissions (e.g., User.ReadWrite.All, AuditLog.Read.All).
Create a docker-compose.yml file.
Define your feature toggles. You can literally turn off features (like User Deletion) by setting an environment variable to false.

version: '3.8' services: helpdesk-portal: image: jahmed22/entra-helpdesk:latest container_name: entra_helpdesk restart: unless-stopped ports: - "8000:8000" environment: # CORE IDENTITY - TENANT_ID=your_tenant_id_here - CLIENT_ID=your_client_id_here - CLIENT_SECRET=your_client_secret_here - BASE_URL=https://entradesk.jahmed.cloud - ALLOWED_ADMINS=email address removed for privacy reasons # CUSTOMIZATION & FEATURE FLAGS - APP_NAME=Entra Help Desk - ENABLE_PASSWORD_RESET=true - ENABLE_MFA_MANAGEMENT=true - ENABLE_USER_DELETION=false - ENABLE_GROUP_MANAGEMENT=true - ENABLE_APP_MANAGEMENT=true volumes: - entra_helpdesk_data:/app/static/uploads - entra_helpdesk_db:/app volumes: entra_helpdesk_data: entra_helpdesk_db:

4.Run docker compose up -d and you are done!

I built this to give back to the community and help secure our Tier 1 operations. If you are interested in testing it out in your dev tenants or want to see the full architecture breakdown, you can read the complete documentation on my website here

I’d love to hear your thoughts, feedback, or any feature requests you might have!

Microsoft Entra expands SCIM support with new SCIM 2.0 APIs for identity lifecycle operations

Joseph Dadzie — Thu, 09 Apr 2026 18:38:08 GMT

Modern organizations rely on a growing ecosystem of applications, platforms, and services to run their business. Managing users and groups consistently across these systems is essential for security and operational efficiency. Many teams rely on the System for Cross-domain Identity Management (SCIM) standard to maintain predictable integrations, reduce custom provisioning work, and simplify lifecycle tasks across their environment.

Microsoft Entra has long supported SCIM‑based provisioning to SaaS applications and API‑driven inbound provisioning from HR systems. Today, we’re extending our support for standards‑based identity lifecycle automation by introducing Microsoft Entra SCIM 2.0 APIs, which allow external SCIM‑compatible identity sources to provision users and groups directly into Microsoft Entra. In this model, Microsoft Entra acts as the SCIM service provider (server), allowing external SCIM‑compatible clients—such as orchestration tools or custom automation frameworks—to provision and manage users and groups in Entra using standard SCIM operations. This is particularly valuable for customers who already use SCIM‑based automation frameworks or identity governance platforms and want to reuse their existing SCIM provisioning patterns when integrating with Microsoft Entra.

What you can do with Microsoft Entra SCIM 2.0 APIs

Microsoft Entra SCIM 2.0 APIs let identity teams, developers, and partners manage user and group lifecycle operations using a standards‑based approach that aligns with existing SCIM tooling.

With these APIs, you can:

Provision and deprovision users in Microsoft Entra from HR systems, SaaS platforms, or custom applications.
Update user attributes using the SCIM schema and supported extensions.
Manage Microsoft Entra ID security groups and Microsoft 365 groups, including membership.
Integrate with existing SCIM clients and automation frameworks, reusing established provisioning patterns.
Discover supported schemas and capabilities through standard SCIM endpoints.

A common scenario is synchronizing users from an HR system into Microsoft Entra, mapping attributes using the SCIM schema, and managing group membership based on role or department. Teams already using SCIM for other SaaS integrations can extend those same patterns to Microsoft Entra with minimal changes.

Get started

Follow the Microsoft Learn documentation to enable SCIM APIs and begin integrating with your SCIM client.

Licensing model

The Microsoft Entra SCIM 2.0 APIs follow a consumption-based pricing model. Refer to the pricing page for eligibility and pricing details.

Learn more

The Microsoft Entra SCIM 2.0 APIs are now generally available in the Microsoft Entra public cloud and will be available in Microsoft Entra ID for US Government by the end of June 2026.

To explore Microsoft Entra SCIM 2.0 APIs in more detail, review the following resources on Microsoft Learn:

-Joseph Dadzie

Vice President, Product Management

Additional resources

Learn more about Microsoft Entra

Evolving identity security: How the Conditional Access Optimization Agent helps you adapt

Swaroop Krishnamurthy — Tue, 31 Mar 2026 20:17:05 GMT

Organizations are expanding Zero Trust across more users, applications, and now a growing population of AI agent identities, making it even more challenging to maintain visibility and control at scale. As environments grow more complex and change daily, static best-practice approaches can’t keep up. Security teams are left trying to reason across dozens of access policies, shifting conditions, and evolving risks, often without clear visibility into where gaps exist.

That’s exactly what we’re hearing from customers.

“The recommendations are great, but they don’t always match how our organization works.”

With this latest set of enhancements, the Conditional Access Optimization Agent moves beyond static guidance to continuous, context-aware identity posture optimization. The agent now understands your organization’s business context, surfaces gaps that manual reviews miss, helps you act on insights safely, and proves the impact of your improvements—all as part of a new operating model for identity security.

Here’s a quick look at what’s new in the Conditional Access Optimization Agent, now in public preview:

Context-aware recommendations tailored to your environment.
Continuous deep gap analysis to identify persistent or emerging policy gaps.
Automated least-privilege enforcement to reduce unnecessary permissions.
Enhanced phased rollout for gradual, controlled deployment.
Passkey deployment campaigns that streamline phishing-resistant authentication rollout.
Zero Trust posture reporting that helps demonstrate measurable improvements.

These new capabilities are designed to work together as part of a continuous operating model for identity security.

To make this concrete, let’s walk through how the agent works in practice across four key steps – from tailoring recommendations to your environment, to identifying gaps, safely deploying changes, and measurable impact.

This is a view of the agent overview dashboard, showing analyzed coverage, identified gaps, and recommended actions to strengthen your access policies.

Step 1: Make recommendations match your reality

Every organization runs Conditional Access a little differently. Naming conventions, policy design patterns, and exception processes – these all vary across environments.

Until now, the agent's recommendations were based on industry and Microsoft best practices, sign-in data, and your Conditional Access policies. However, guidance needs to reflect how your organizations actually operate.

Context-aware policy recommendations – teach the agent your standards

With context-aware policy recommendations, you can upload internal documentation directly to the agent. Think about the guidance your team already relies on, such as documents that outline authentication strength requirements, device compliance baselines, and internal or external policy standards. These often live as PDFs, wiki pages, or long policy docs that admins manually cross-reference during periodic reviews.

The agent securely uses that context to tailor recommendations for your organization, so they align with how your team designs and manages Conditional Access.

For example, the Australian government publishes Conditional Access guidance for organizations operating in regulated environments. The agent is able to reason over this guidance and produce recommendations aligned to Australian compliance standards.

In the agent’s settings page, you can upload organization-specific policies and guidance so the agent can tailor recommendations to your environment

Step 2: Surface gaps humans can’t easily see

As environments grow more complex, Conditional Access policies become increasingly difficult to reason over. Organizations often manage dozens, or even hundreds, of policies across user groups, applications, authentication strengths, and device requirements, making it hard to fully understand how they interact.

Continuous deep gap analysis

Enterprise customers average 83 Conditional Access policies. The number of possible interactions between those policies – layers, overlaps, and coverage gaps – is challenging to reason over. Manual review typically focuses on recently changed policies. But some of the most critical gaps have been there all along. They are persistent configuration issues that have existed for years.

The agent evaluates how policies interact with one another, understands how authentication requirements are enforced across the policies, and identifies gaps where coverage falls short. This means it can detect:

newly introduced gaps caused by policy changes or configuration drift
persistent structural gaps cause by policy overlap, constantly evolving exceptions, and more

Instead of reviewing policies one by one, the agent evaluates the entire access control system as a whole.

The agent identifies uncovered users and policy gaps by analyzing how Conditional Access policies interact across your environment.

Zero Trust least-privileged enforcement for agent identities

Nowadays, access is no longer just about people. Gartner stated that by 2029, most secure access requests will come from non-human identities—up from less than 5% today.

As AI agents become a rapidly growing part of the workforce, they also introduce new risks. Many of these identities can be over-privileged, making them attractive targets for attackers!

The Conditional Access Optimization Agent identifies agent identities with excessive or unused permissions and recommends least-privilege adjustments.

This extends continuous Zero Trust enforcement beyond workforce identities to the fastest-growing population in your environment.

Step 3: Turn insight into action without breaking things

Finding gaps is important. Fixing them safely is where the real operational challenge begins.

We all know the risk of making access policy changes without understanding their real-world impact. A single misconfigured policy can lock out users or disrupt critical applications.

These enhancements help your teams move from insight to execution with confidence.

Phased rollout for any Conditional Access policy

With our updated Phased Rollout capability, you can now deploy any Conditional Access policy gradually, not only agent-recommended ones like in our previous release.

For each rollout, the agent proposes low-impact phases, monitors real user impact at every stage, and intelligently suggests progression or roll back so you can easily deploy policies while minimizing end-user impact. This means your team no longer needs to manually move policies from report only to enabled. The agent handles that progression for you.

This allows your team to strengthen access protections in a way that works for your business, without widespread lockouts, helpdesk spikes, or disruption to critical workflows.

The agent creates a phased rollout plan, allowing policies to be deployed gradually while monitoring user impact and minimizing disruption.

Passkey deployment campaigns – structured adoption of phishing-resistant authentication

Phishing-resistant authentication is one of the most important steps organizations can take to strengthen identity security – and passkeys deliver both security and usability. The challenge isn't whether to adopt passkeys, but how to roll them out without creating operational friction.

Microsoft data shows consumer users are 3× more successful signing in with passkeys compared to legacy authentication methods. That's where the agent's passkey campaign experience comes in, helping you run structured adoption campaigns across your organization.

Start with your highest-impact users such as administrators, executives, or employees most targeted by phishing. The agent tracks registration progress, identifies users that haven’t enrolled yet, communicates with them via teams, and helps you expand adoption wave by wave.

No more ad hoc enforcement or spreadsheet-driven tracking across teams.

The agent guides passkey adoption with structured campaigns, targeting users, tracking progress, and expanding rollout in stages.

Step 4: Prove progress and communicate impact

Closing gaps is only just a piece of the whole story. Security leaders increasingly need to demonstrate measurable progress, to both internal stakeholders and your executive leadership.

The built-in reporting dashboard provides a clear summary of posture improvements driven by you and the agent. You can track:

Exactly how many Conditional Access policy gaps the agent has discovered
Users, Apps, and Agent IDs you have improved policy coverage for
Remaining users, apps, and agent IDs requiring additional coverage

This makes it easier to demonstrate the value of your Zero Trust investments and communicate progress to your leadership.

The reporting dashboard tracks Conditional Access posture improvements, showing gaps closed, coverage gained, and remaining areas to address.

The new operating model for identity security

These enhancements aren't incremental improvements to a recommendation engine.

They represent a shift in how identity security operations work. Moving from static rule management to continuous, context-aware optimization leveraging the power of AI.

Identity security is no longer a periodic audit exercise. It becomes a continuous operational capability - helping you secure both human and non-human identities across authentication, access, and risk.

Get started today

If you have Microsoft 365 E5, the Conditional Access Optimization Agent will become available through a phased rollout. Once available in your tenant, you can enable it directly in the Microsoft Entra admin center and start using it right away.

We are continuing to expand these capabilities and will evolve the agent based on your feedback.

Enable the Conditional Access Optimization Agent → Security Copilot agents - Microsoft Entra admin center

Swaroop Krishnamurthy

Principal Product Manager, Microsoft Entra

Swaroop Krishnamurthy | LinkedIn

Additional resources

Learn more about Microsoft Entra

Microsoft Entra Tenant Governance: Secure and manage multi-tenant environments at scale

Joseph Dadzie — Tue, 31 Mar 2026 20:18:20 GMT

Managing identity across multiple tenants is a growing challenge for organizations of all sizes. Mergers, acquisitions, and the rise of shadow IT often lead to a fragmented tenant landscape—creating security and compliance blind spots that attackers are quick to exploit. Even a single poorly secured tenant can put your entire organization at risk.

Many of these shadow tenants may lack critical controls like MFA, Conditional Access, or privileged role protections. Recent high-profile incidents have reinforced an important reality: attackers can move laterally from an unmanaged tenant into production environments, bypassing controls organizations assumed were in place.

Microsoft Entra Tenant Governance addresses this challenge by providing a centralized, risk-informed way to discover, govern, and continuously secure all related tenants—without relying on custom scripts or fragmented administrative models. From small tenant estates to large enterprises, Entra Tenant Governance enables least-privilege access, enforces configuration baselines, and maintains continuous visibility from a single control plane.

Why Tenant Governance Matters

Built on Microsoft’s own experience securing a large and complex tenant estate, Entra Tenant Governance is designed to make tenant relationships visible, governance enforceable, and security posture continuously verifiable—at scale. Tenant Governance provides a centralized model for managing tenants with different workloads, security requirements, and operational owners, enabling consistent governance across tenants without forcing a one-size-fits-all approach.

With Entra Tenant Governance, organizations can:

Discover and inventory all related tenants, including production, non-production, and employee-created tenants.
Establish governance relationships for least-privilege cross-tenant access.
Monitor and enforce consistent tenant policies to maintain a strong security and compliance posture.
Securely create new tenants with governance applied from day one.

So what does this look like in the real world? Let’s walk through four scenarios.

Real-World Scenarios

1. Discovering Related Tenants

An organization is trying to reduce tenant-to-tenant risk across a growing identity estate shaped by mergers, acquisitions, and shadow IT. The security team recognizes that effective mitigation starts with visibility, so they begin by identifying which other tenants are connected to their production tenant and what exposure those connections might create.

Related Tenants experience automatically generates a continuously updated list of tenants that have observable connections to the organization’s tenant. This is not intended to be a definitive ownership or organizational inventory, but a risk-informed discovery view designed to surface tenants that may warrant governance attention. The tenant governance service keeps this inventory current by detecting relationships based on discovery signals for B2B access, multi-tenant applications, and Microsoft billing. In practice, the organization finds that tenants requiring governance attention typically leave these discoverable “traces” in production environments, making it possible to identify and prioritize them without relying on a manual inventory.

Screenshot of related tenants discovery view.

Next, the organization uses the metrics associated with each discovery signal to triage. These metrics help determine which related tenants should be brought into governance and whether any existing relationships represent immediate security exposure that needs to be mitigated.

When the team drills into a specific related tenant, the experience consolidates signals into a single view that clarifies how the tenant is connected and what risks the relationship may introduce. For example, the organization may see users using B2B to access administrative experiences in the related tenant. The team may also see a Microsoft billing relationship indicating that a billing account in the organization’s tenant is paying for an Azure subscription in the other tenant. Together, these signals suggest the tenant should likely be governed as part of the organization’s tenant landscape. If the related tenant also hosts a multi-tenant app with access to the organization’s tenant data, that becomes a priority indicator. The team can then validate and strengthen security controls to reduce the risk of data exposure if the related tenant or its applications are not adequately secured.

Screenshot of related tenants discovery signals.

Learn more about related tenants.

2. Creating Tenant Governance Relationships

After identifying tenants that require governance, an organization needs reliable administrative access across those tenants to perform resource management and governance tasks. The identity team wants to avoid the overhead and risk of managing separate local admin accounts or managing permissions of B2B accounts in every tenant.

Using Microsoft Entra Tenant Governance, the organization establishes tenant governance relationships between its central governing tenant and each governed tenant. Each relationship is set up through a request and approval workflow that formalizes which tenant is governing and which is governed, and the degree of access that the governing tenant has to the governed tenant. This approach scales so that as the organization’s tenant landscape grows, the governing tenant can manage relationships with many governed tenants with different security, compliance, and organizational requirements.

Screenshot of governed tenants view.

Once relationships are established, the organization assigns least-privilege delegated administration by mapping security groups in the governing tenant to built-in Entra roles in each governed tenant. Administrators can then sign in from the governing tenant and manage resources in governed tenants across Microsoft administration experiences, without requiring a B2B guest account or a local user account in those tenants. This creates a more streamlined and consistent admin experience across environments.

Centralized access administration also improves control. The organization can view, audit, and manage administrative access in one place, and keep permissions aligned to job changes by updating group membership in the governing tenant.

Screenshot of tenant governance policy template details.

Learn more about tenant governance relationships.

Administrators of Microsoft Defender and Sentinel are also able to leverage delegated access in the Defender multi-tenant management experience. To learn more about this, read the Defender blog post.

3. Tenant Configuration Management

An organization has established administrative access to the tenants it governs, and the next priority is keeping those tenants aligned with security and compliance requirements over time. The challenge is consistency. Settings often drift as admins make changes, new policies are introduced, or service configurations evolve. The identity and security teams need a repeatable way to define what “good” looks like across different tenants in its estate, and to detect when a tenant deviates.

With tenant configuration management, the organization defines a configuration baseline that represents the desired state of tenant resources. The baseline is expressed in a standard .json format and can cover more than 200 resource types across Microsoft services, including items like Conditional Access policies in Entra and transport rules in Exchange, as well as supported resources in Intune, Defender, Purview, and Teams. The organization can use different configuration baselines depending on the workloads and requirements in a particular tenant.

Screenshot of tenant configuration baseline view.

To accelerate adoption, the organization uses configuration snapshots to capture settings from a known-good tenant and uses that output as a starting point for the baseline, rather than authoring everything from scratch.

Screenshot of tenant configuration monitors.

The organization then sets up configuration monitors that run automatically on a schedule and validate the actual state of resources against the baseline. The results provide recent run summaries, and a configuration drift report highlights where configurations differ from the desired state so teams can prioritize remediation.

Screenshot of tenant configuration drift report.

To match operational ownership, the organization creates up to 30 monitors and commonly aligns them by service, such as one monitor for Entra and another for Exchange. Each monitor can include as many resources as the organization is licensed to monitor.

Organizations that are currently leveraging the open-source Microsoft365DSC solution can easily migrate to Entra tenant configuration management. The Entra solution offers several improvements over the open-source project, is fully supported by Microsoft, and is the recommended approach for organizations looking to manage their tenants’ configuration with declarative code.

Learn more about configuration management. To see the full list of resource types that are supported for tenant configuration management, see our documentation: Entra, Exchange, Intune, Defender and Purview, and Teams.

4. Secure Tenant Creation

Now that the organization has discovered its related tenants and brought them under governance, the next priority is ensuring that any new tenants created in the future follow the same governed pattern from day one. The organization still needs flexibility to support real business needs, so the identity team designs a controlled process that allows only approved users, in the engineering group, to create add-on tenants for testing new capabilities in a test environment.

With secure tenant creation, the organization can enable this delegated creation model while helping ensure governance from the start. When an approved user creates a new tenant, it is configured to be well-governed from day one. The new tenant is created with a built-in tenant governance relationship to the organization’s governing tenant, ensuring the governing tenant has the cross-tenant administrative access needed to apply governance and perform ongoing management without delay.

Newly created tenants are also linked to the organization’s Microsoft billing account at creation time. This provides proof of commercial ownership and reduces operational risk. If administrative access to the tenant is lost, the billing linkage helps streamline tenant recovery, so the environment does not become orphaned.

Screenshot of secure tenant creation process.

Learn more about secure tenant creation.

Licensing and Availability

Microsoft Entra Tenant Governance capabilities are available in Entra ID P1 (also included in Microsoft 365 E3), Entra ID P2 (also included in Microsoft 365 E5), and Microsoft Entra ID Governance (also included in Entra Suite and Microsoft 365 E7). See the Microsoft Entra licensing page for more details.

Tenant configuration management APIs are generally available. Other tenant governance experiences are in public preview. These new capabilities are now rolling out, with deployment expected to complete over the next few days.

How to Get Started

To get started, read our Tenant Governance documentation to learn more about these features and how they enable you to address important security and compliance scenarios.

High-quality tenant governance tooling and operational processes are foundational for organizations to achieve their security and compliance objectives. We’re eager to get your feedback on these new Entra capabilities that empower you to achieve your goals – feel free to drop a note below in the comments section of this article.

-Joseph Dadzie
Vice President, Product Management

Additional Resources

Learn More About Microsoft Entra

Prevent identity attacks, ensure least-privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

Strengthen identity resilience: Recover with confidence using Microsoft Entra Backup and Recovery

Joseph Dadzie — Tue, 31 Mar 2026 20:31:16 GMT

Identity is the backbone of modern security. When identity systems fail, access breaks down, productivity stops, and security controls weaken across the organization. That is why Microsoft invests deeply in resilience across Microsoft Entra, designing the service not only to meet a 99.99% availability SLA, but also to continue supporting sign-ins even when parts of the cloud experience disruption.

This resilience is built into the foundation of the service. Microsoft Entra is hardened at the core, supported by a parallel backup authentication system, and reinforced through resilient SDKs and applications. Together, these layers help ensure that critical identity scenarios continue to function during service level incidents.

However, resilience is not only about keeping the service available. It is also about recovering when changes inside your tenant do not go as planned. Identity environments evolve constantly as policies are updated, integrations expand, and administrative responsibilities shift. Without a reliable way to understand, validate, and recover those changes, even routine updates can introduce significant risk.

A misaligned policy can block user or administrator access. A provisioning error can overwrite thousands of user attributes leading to increased support calls. A compromised privileged account can quietly modify critical group memberships in ways that are difficult to detect and even harder to reverse at scale. While service resilience keeps Microsoft Entra available, Microsoft Entra Backup and Recovery helps organizations recover when changes inside their environment introduce risk or disrupt users.

Microsoft Entra Backup and Recovery now available in Public Preview

Microsoft Entra Backup and Recovery helps you build identity resilience into daily operations using an always‑on, Microsoft‑managed solution that rapidly restores critical identity objects to a known‑good state. It provides automatic backups, point‑in‑time visibility into configuration changes, and backups are protected by a built‑in safeguard that prevents them from being disabled, deleted, or altered. This helps reduce recovery time and maintain business continuity.

For Public Preview, we are announcing new capabilities that help you recover with confidence: Restoring core directory objects 1 backup a day within the last 5 days, including users, groups, applications, service principals, Conditional Access policies, authentication method policy, authorization policy, and named locations.

Entra Backup and Recovery strengthens the core of your identity resilience strategy, helping you minimize downtime, protect your tenant, and recover quickly from both accidental changes and security compromises while maintaining confidence in the integrity of your environment.

Note: Microsoft Entra Backup and Recovery is available today and requires an Entra ID P1 or P2 license. Learn more on the Microsoft Entra Backup and Recovery learn docs page.

Get started today by navigating to Microsoft Entra Backup and Recovery under the Entra ID blade in the Microsoft Entra admin center.

Next, let’s explore how Entra Backup and Recovery helps organizations respond quickly and confidently by examining three common disaster recovery scenarios. These include an erroneous Conditional Access update that blocks user access, widespread user‑attribute corruption caused by an HR system issue, and malicious modifications to identity configurations.

Scenario 1: Recovering from an erroneous Conditional Access change that locks out users

Conditional Access policies are central to enforcing Zero Trust, and many organizations rely on them to control access across users, applications, and locations. While safeguards such as report-only mode and change validation help reduce risk, organizations need a reliable way to quickly recover from mistakes that can have an outsized impact.

In this scenario, an identity team is updating an existing Conditional Access policy as part of routine maintenance. During the update, an exclusion group is unintentionally removed from the policy assignments. The change applies right away. Some users are no longer able to sign-in, authentication failures increase, and helpdesk tickets begin to spike.

To restore access without prolonged disruption, the identity team turns to Microsoft Entra Backup and Recovery. Using the Backup and Recovery experience in the Microsoft Entra admin center, they review available backups and select a recent snapshot that reflects the last known-good configuration.

Identify the right backup to restore

You can easily view available backups in the Microsoft Entra Admin center and take action on accidental changes.

Next, the team generates a Difference Report scoped to Conditional Access policies. The report clearly shows what changed, including the removal of the exclusion group from the affected policy. This allows the team to confirm the root cause before taking action and to ensure no unrelated policies are included in the recovery scope.

After validating the changes, the team runs a targeted recovery job to restore the affected Conditional Access policy to its previous state. Within minutes, access is restored for impacted users, without requiring manual policy edits or custom scripts.

By using Microsoft Entra Backup and Recovery to identify the exact change and revert only the affected configuration, the organization resolves the incident quickly, limits disruption, and maintains confidence in its identity controls.

Scenario 2: Restoring user attributes after an HR system error pushes incorrect data at scale

Many organizations rely on an HR system as the authoritative source for user identity data. Attributes such as job title, department, and manager name often flow automatically into Microsoft Entra and downstream applications to power access decisions, workflows, and reporting.

In this scenario, a configuration issue in the HR system causes incorrect attribute values to be pushed to multiple user accounts during a scheduled provisioning cycle. Job titles and departments are overwritten at scale, reporting structures become inaccurate, and applications that depend on consistent identity data begin to behave unpredictably. To prevent further impact, the identity team pauses inbound provisioning while they assess the situation.

To investigate, the identity team uses Microsoft Entra Backup and Recovery to compare the current state of user attributes with a backup taken two days prior.

Validate configuration changes with a Difference Report

Admins can use the Difference Report to gain visibility into attribute changes, with a clear, itemized view across affected users.

The generated Difference Report clearly shows which users were affected and exactly which attributes changed, giving the team an immediate, actionable view of the impact.

To ensure the correct scope before recovery, the team applies granular filters to narrow the recovery to the affected users and attributes. This allows them to precisely target the recovery job without overwriting unrelated or valid updates made elsewhere in the directory.

You can apply granular filters in the difference report to quickly pinpoint the exact object that needs recovery.

After examining the changes and applying the right filters, administrators initiate the recovery job. Throughout execution, they monitor progress from the recovery history page, which surfaces real‑time status through the modified objects column, giving teams clear visibility into recovery progress and scope.

Once the HR system configuration is corrected, inbound provisioning is resumed with confidence, knowing the directory has been returned to a previously known good state and the organization can trust the accuracy of its identity data going forward, and normal operations continue without prolonged disruption.

Scenario 3: Recovering after malicious changes to identity configurations

In this scenario, a compromised privileged account is used to make malicious changes to identity configurations. MFA requirements are weakened and sensitive group memberships tied to critical applications are altered. Security teams detect suspicious activity and escalate the incident for investigation and remediation.

Once the immediate threat is contained, the identity team must determine exactly what changed and restore trusted configurations as quickly as possible. Manually reviewing and rebuilding identity settings across multiple objects would be time consuming and increases the risk of missing subtle but impactful changes. In addition to malicious configuration changes, malicious actors may also delete critical identity objects, which Microsoft Entra Backup and Recovery can restore by integrating with soft‑deletion as part of the same recovery process.

To assess the impact, the team uses Microsoft Entra Backup and Recovery to compare the current tenant state with a backup that reflects the last known good configuration prior to the compromise.

Execute the recovery job with confidence

You can quickly verify configuration changes and execute the recovery job with Microsoft Entra Backup and Recovery.

Once admins identify which directory object they want to recover, they select Recover this object, to remove the attacker’s malicious modifications and restore the trusted configuration. After running the recovery job, trusted configurations are reinstated and malicious modifications are removed, and the team verifies that MFA enforcement, access conditions, and group memberships have been returned to their expected state without requiring manual cleanup or reconstruction.

By using Microsoft Entra Backup and Recovery to quickly identify and revert malicious changes, the organization limits the blast radius of the incident, restores confidence in its identity environment, and resumes normal operations with minimal disruption.

Getting started with Microsoft Entra Backup and Recovery

Microsoft Entra Backup and Recovery is available today in Public Preview. If you’re a Microsoft Entra customer with Entra ID P1 or P2 license, you can start using these capabilities immediately in the Microsoft Entra admin center.

Microsoft Entra Backup and Recovery is built as an API‑first, extensible platform that gives customers the flexibility to design backup and recovery workflows aligned to their operational needs. These same APIs enable independent software vendors (ISVs) to integrate and deliver complementary solutions that extend Entra with their domain expertise.

To get started, sign-in to the Microsoft Entra Admin center as an Entra Backup Administrator role. In the left navigation, select Backup and Recovery to explore your automatic backups, generate Difference Reports, and run recovery jobs. From here, you can review your snapshot history, investigate configuration changes across your directory, and begin restoring objects as needed.

Identity resilience isn’t optional—it’s essential. With Microsoft Entra Backup and Recovery, you can minimize downtime, protect your tenant, and recover confidently from accidental changes or security compromises. Start using Entra Backup and Recovery in Public Preview today and join the conversation in the Microsoft Entra Tech Community.

-Joseph Dadzie

Vice President, Product Management

Additional resources

Learn more about Microsoft Entra

External MFA in Microsoft Entra ID is now generally available

Swaroop Krishnamurthy — Tue, 31 Mar 2026 20:33:33 GMT

Multifactor authentication remains a foundational control for securing user identities, especially as organizations adopt Zero Trust and respond to increasingly targeted identity attacks.

Microsoft’s research shows that MFA reduces the risk of account compromise by more than 99 percent. Microsoft Entra ID already offers a broad set of native MFA options.

Now, with the GA of external multifactor authentication (external MFA)—previously known as external authentication methods—you can integrate trusted third-party MFA providers while continuing to rely on Microsoft Entra ID as your central identity control plane.

Why External MFA matters

External MFA is designed for organizations that:

Use a third-party MFA solution to meet regulatory or business requirements
Need to support specific scenarios, such as mergers and acquisitions
Want to unify MFA experiences under a modern identity system

Built on the OpenID Connect (OIDC) standard, external MFA allows you to integrate your preferred MFA provider into Microsoft Entra ID without sacrificing security or policy enforcement.

Figure 1: Configure external MFA in Microsoft Entra ID

How it works

Once configured, external MFA is managed alongside native Microsoft Entra ID authentication methods—giving administrators a single pane of glass for all authentication methods.

Every sign-in still goes through full policy evaluation, including real-time risk assessment and Conditional Access.

Figure 2: Sign-in with external MFA

Integrating external MFA with Conditional Access allows administrators to align authentication prompts with their organization’s security and business objectives by using sign-in frequency and session controls. When these policies are properly tuned, they strike the right balance between reauthentication and user productivity. However, overly frequent reauthentication can degrade user experience and can even increase phishing risk by conditioning users to approve prompts without careful review. To avoid these issues, we recommend following Microsoft’s reauthentication guidance when configuring your Conditional Access policies.

Migration from Custom Controls

External MFA replaces Custom Controls, which will be deprecated on September 30, 2026. Existing configurations will continue to work during the transition period. We’ll share detailed migration guidance soon to help you move to external MFA before the retirement date.

Start integrating external MFA today by following our step-by-step guide on Microsoft Learn.

Thank you to our customers and MFA solution partners for your feedback during the preview phase. Your input helped shape this release.

-Swaroop Krishnamurthy

Principal Product Manager
Microsoft Entra ID

Additional resources

How to manage external MFA in Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn

Learn more about Microsoft Entra

⁠Microsoft Entra News and Insights | Microsoft Security Blog

⁠⁠Microsoft Entra blog | Tech Community

⁠Microsoft Entra documentation | Microsoft Learn

Microsoft Entra discussions | Microsoft Community

Entra ID Private Access - data flow

Stefan31 — Tue, 24 Mar 2026 13:47:12 GMT

Hello,

I am successfully testing Entra Private Access. From outside, I can easily access my shared permissions.

However, I have one more question. What happens if I my device on the internal network? If I access the shares directly, I get about 1GB/s. What happens if the "Global Secure Access" client is active? Do all the data go through the Entra portal, or just the authentication? If all the data go through the Entra portal, there could be challenges with the internet connection (all data in and out).

Thank you for your support

Stefan

Microsoft Entra innovations announced at RSAC 2026

Irina_Nechaeva — Mon, 30 Mar 2026 15:54:53 GMT

Agentic AI is reshaping how organizations work, and it is fundamentally changing how we must think about protecting identity and access. As AI accelerates innovation, the number of users, devices, apps, and agents is exploding, creating an unprecedented number of digital identities across disparate systems. Every new identity, whether human or non-human, represents another potential entry point for attackers and another potential gap in visibility. In the 2026 Secure Access report, 97% of organizations experienced an identity or network access incident in the past year, and 70% reported incidents tied to AI-related activity.

The attack surface is growing faster than traditional security approaches can keep up, forcing organizations to rethink how they protect their identities and data at scale. This is why security must start with an access fabric, which creates a common identity foundation for employees, workloads, and AI agents, continuously shares signals and evaluates risk, and enforces access decisions in real time across every identity and session.

The latest Microsoft Entra innovations advance this vision, so you can protect access for people and agents and strengthen your Zero Trust posture. With those new capabilities you can:

Protect agent identities with the same rigor as users, apps and devices, using familiar protections like identity governance and Conditional Access in Microsoft Entra Agent ID, the identity foundation of Microsoft Agent 365.
Secure employee access in the AI era, from shadow AI discovery and prompt injection protection to strong phishing-resistant authentication enabled by flexible passkey deployments, extensibility to the broad range external MFA providers, and adaptive risk remediation.
Strengthen your identity foundation by protecting your multi-tenant environments with Tenant governance, adding a layer of resilience with Backup and Recovery, making it possible to restore critical identity objects with confidence and accelerating Identity Security by improved identity risk detection, analytics and remediation, connecting identity and SecOps team to respond faster and proactively improve your identity security posture.
Supercharge your identity team with new Conditional Access agent capabilities, including context-aware recommendations, phased rollout for any policy, and automated least-privilege enforcement. You can also discover and extend identity integrations with Microsoft Security Store.

Throughout the week at RSAC, we’ll be demonstrating these capabilities and sharing practical guidance on how to build a more resilient, comprehensive identity and access security strategy. Below is a closer look at the innovations and where to see them in action at the RSAC.

Protect agent identities

As organizations adopt AI agents at scale, many are deployed without consistent controls. As shared earlier this month, Microsoft Entra Agent ID, the identity foundation of Microsoft Agent 365, helps secure agent identities and their access to resources by assigning a unique ID to AI agents built with Microsoft Foundry, Microsoft Copilot Studio and our Agent 365 ecosystem partners. This gives identity teams a consistent way to apply the same rigor they use for users, apps and devices identities.

With that foundation in place, we are integrating ID Governance access packages into Microsoft Agent 365 Security Policy Templates, so agents can start secure as they are onboarded. We are also extending existing Conditional Access user policies to secure agents that work on behalf of users. These protections help make real-time access decisions based on risk signals and custom security attributes. Together, they help prevent compromise and reduce the risk of misuse by malicious actors.

Secure employee access in the AI era

As AI becomes embedded in daily work, organizations need consistent controls governing access to apps, data, and AI services. Microsoft Entra Suite unifies identity and network access under a single policy framework to help deliver Zero Trust access to any resource, including AI applications and agents.

Microsoft Entra Internet Access extends identity-based Zero Trust controls to web, SaaS, and AI traffic. It provides visibility into AI tools and agents and helps secure employee access as usage grows.

Key innovations in Internet Access include:

Shadow AI detection complementing Microsoft Defender for Cloud Apps to discover and monitor unsanctioned AI applications, track usage, and instantly enforce Conditional Access to allow or block those apps (generally available).
Prompt injection protection to block malicious AI prompts (generally available).

Microsoft Entra continues to advance passwordless authentication experiences, strengthening how users prove who they are and ensuring secure, low‑friction access as AI usage accelerates:

Synced passkeys and passkey profiles to enable seamless, phishing‑resistant sign‑in and deployment across your organization (generally available).
Microsoft Entra Passkeys on Windows to extend Windows Hello experiences, making passkeys even more seamless for users on Windows devices (preview).
External MFA (formerly called External Authentication Methods) to enable integration of MFA providers directly with Microsoft Entra ID and your existing Conditional Access policies (generally available).
Adaptive risk remediation enables passwordless users to securely regain access without help-desk friction. Entra ID Protection supports appropriate automatic self-remediation across all authentication methods, passwordless and those that still use passwords, adapting to where customers are in their modern authentication journey (generally available in April 2026).

These updates help protect identities and access points while moving organizations closer to a passwordless future.

Strengthen your identity foundation

Organizations require the ability to proactively govern multi-tenant environments and recover quickly from misconfigurations or compromises. To address this need, we're introducing new capabilities that strengthen identity resilience and minimize risk of managing complex, multitenant environments:

Microsoft Entra Backup and Recovery enables confident recovery of critical directory objects to a known good state after accidental changes or security compromises. Automated, high-performance backups and point-in-time restore capabilities help reduce recovery time and support operational continuity (preview).
Microsoft Entra Tenant Governance helps you centrally govern multi-tenant environments, reduce risk from shadow IT tenants, and enforce a consistent security posture. You can discover and inventory tenants, establish governance relationships, monitor tenant configurations, and securely create new tenants (preview). The tenant configuration API helps you simplify and standardize how tenant settings are managed across Microsoft workloads with JSON-based configuration baselines (generally available).
Microsoft Entra cross-tenant group synchronization helps organizations securely manage access across related tenants by enabling governed, policy-driven group sharing without duplicating identities or increasing administrative overhead. By centralizing group lifecycle management and enforcing consistent governance controls across tenants, organizations can reduce access sprawl, simplify collaboration, and maintain least‑privilege access in complex multi-tenant environments (preview).

Accelerate your identity security

But resilience alone isn’t enough. Modern identity security means stopping attacks before they escalate. And, as identities expand beyond human users, organizations need to extend their identity security tools to protect users, apps, and agentic identities across their identity fabric.

We're advancing identity security with unified risk and enhanced detections across Entra and Defender. Powered by trillions of signals across Microsoft Security, risk-based Conditional Access can now make more informed and intelligent access decisions based on aggregated risk across identity accounts. This improves identity protection for high-impact scenarios like lateral movement and privilege escalation and strengthens protection across cloud and hybrid environments. With shared visibility across Identity and Security Operations teams, admins gain a deeper understanding of their risky identities and can respond more efficiently across their cloud and hybrid infrastructure.

Supercharge your identity team

Conditional Access is central to Zero Trust architecture, but policies can drift as environments change. The Conditional Access Agent in Microsoft Entra helps continuously analyze access policies and deliver recommendations aligned to your unique environment. It identifies persistent gaps and helps strengthen protections without disrupting productivity.

We’re introducing new capabilities that make the Conditional Access Agent more intelligent, personalized, and actionable (preview):

Context-aware recommendations tailored to your environment.
Enhanced phased rollout for gradual, controlled deployment.
Continuous deep gap analysis to identify persistent or emerging policy gaps.
Automated least-privilege enforcement to reduce unnecessary permissions.
Zero Trust posture reporting that helps demonstrate measurable improvements.
Passkey deployment campaigns that streamline phishing-resistant authentication rollout.

Discover and extend identity integrations with Microsoft Security Store

Security Copilot agents help teams optimize and act, while the Microsoft Security Store helps them extend and scale. As identity environments expand, organizations increasingly rely on partner capabilities to address specialized needs. By bringing the Microsoft Security Store directly into Microsoft Entra, teams can now find trusted, Microsoft Entra‑ready agents and integrations within the product experience.

The Microsoft Security Store helps customers discover identity solutions from Microsoft and partners, including integrations with Entra External ID and Entra Verified ID, plus more than 15 identity agents powered by Security Copilot that surface identity posture gaps, strengthen identity verification, reduce fraud across workforce, consumer, and external identities, and more. This centralized discovery and purchasing experience reduces friction and helps teams deploy solutions more quickly through the Microsoft Security Store. Read more.

Where to find Microsoft Entra at RSAC 2026

Before RSAC begins, Microsoft Security product leaders will host a pre-day session on Sunday, March 22 at 4:00pm PST in the Palace Hotel to share how security is the foundation of Frontier Transformation. Learn more about our security vision, top threat intelligence trends, and product demos ahead of the event. Secure your spot today.

During the week, come connect with the Microsoft Entra team at RSAC. Visit the Microsoft booth #5744 to experience live product demonstrations and participate in our expert-led theater sessions.

Executive Lunch and Learn Session at the Palace Hotel

Session Title

Session Description

Date & Time (PT)

Microsoft Entra Secure Access Lunch

Join us for a special lunch and learn focused on Microsoft Entra and how it helps organizations modernize identity and network security and move toward a more resilient access fabric. This discussion will provide insights on how to secure access for all identities across your Zero Trust journey – whether human or agentic. You don’t want to miss this! Sign up for the session here.

· Date: March 23, 2026

· Time: 12pm – 1:30pm

· Location: Twin Peaks Room in the Palace Hotel

Microsoft Entra Theater Sessions in booth #5744

Session Title	Session Description	Date & Time (PT)
Control agent sprawl and secure access with Microsoft Entra	Learn how to control agent sprawl and secure AI agent access to apps, resources and other agents. This technical review and real-world demo of Microsoft Entra Agent ID—the identity foundation of the Microsoft Agent 365 control plane for agents—demonstrates how familiar tools like Conditional Access, access governance, and lifecycle workflows extend to agent identities, enforcing least privilege access (or Zero Trust access) for AI agents in your enterprise.	· Date: March 23, 2026 · Time: 6:40- 7:00PM · Location: Booth #5744
From Crisis to Control: Governance, Backup, and Recovery with Microsoft Entra	Learn how to protect your organization from service misconfigurations, operational errors, and security compromises using Microsoft Entra. This session shows how Microsoft Entra Tenant Governance enables continuous discovery, configuration insight, and tenant‑level oversight, while Microsoft Entra Backup and Recovery provides rapid restoration of critical identity objects including users, groups, and Conditional Access policies and more.	· Date: March 24, 2026 · Time: 11:30-11:50 AM · Location: Booth #5744
Accelerate your Identity Security for Modern Identity Defense	Identity underpins every interaction in the modern enterprise but protecting the vast ecosystem of human users, non-human entities and agents can be a daunting task. Join our experts to hear how Microsoft is leveraging its expertise in identity (IAM) and security (XDR) to provide seamless Identity Security protection comprehensively across our customers unique identity footprint.	· Date: March 25, 2026 · Time: 3:30-3:50pm · Location: Booth #5744
Secure Workforce Access to AI with Microsoft Entra Suite	Your workforce is already using AI. In this theater session, see how Microsoft Entra Suite secures access to AI so your workforce can stay productive while protected from new risks like prompt injection and unsanctioned AI tools. We will show unified identity and network controls and risk‑based session policies, plus how Global Secure Access and AI Gateway expose and block risky connections in real time.	· Date: March 25, 2026 · Time: 4:30-4:50 PM · Location: Booth #5744
Defend identity autonomously with agentic AI in Microsoft Entra	Learn how agentic AI is transforming identity security workflows from investigation to remediation. This review and real-world demo of Security Copilot in Microsoft Entra and agents shows how identity teams are using AI to surface risk, close policy gaps, and continuously govern access across users, apps, and devices, reducing manual effort while strengthening Zero Trust at scale.	· Date: March 26, 2026 · Time: 12-12:20 PM · Location: Booth #5744

We look forward to seeing you in March at RSAC 2026. Visit the Microsoft booth, join our theater sessions, and explore how Microsoft Entra helps secure your access fabric in the age of AI.

-Irina Nechaeva

General Manager, Identity and Network Access Product Marketing

Additional resources

Learn more about Microsoft Entra

As AI adoption scales, is your access strategy still viable?

Kaitlin_Murphy — Thu, 09 Apr 2026 16:19:33 GMT

As AI moves from experimentation into everyday workflows and AI agents begin operating more autonomously across systems, access environments are changing in scale, complexity, and speed. Our latest research, Secure access in the age of AI , looks at how security leaders are navigating one of the fastest shifts in enterprise technology adoption, and where existing access models are starting to show strain.

For organizations, AI brings meaningful opportunity. But every new AI tool or agent also introduces additional identities, permissions, and access paths. As a result, identity and network access are no longer just foundational controls. They are central to how organizations manage risk in the age of AI.

AI Is Expanding the Access Landscape

Every AI tool, integration, or agent introduces new identities, permissions, and pathways to systems and data. In many cases, these identities don’t behave like traditional users. They operate continuously, interact with multiple systems, and often require broad access to function as intended.

Security leaders are already seeing the effects of this expansion. In our research, 97% of organizations experienced an identity or network access incident in the past year, and 70% reported incidents tied to AI‑related activity. Threats such as AI‑assisted phishing and agent privilege escalation are now part of the real‑world threat landscape, not edge cases.

What’s notable is that these incidents aren’t always driven by novel attack techniques. Just as often, they stem from environments that have grown complex faster than governance and controls can keep up. As AI adoption scales, that gap becomes increasingly visible.

6 in 10 leaders anticipate more access incidents due to AI agents and employee use of GenAI.

Fragmentation Was Already a Challenge. AI Raises the Stakes.

Long before AI entered the picture, many organizations were already managing fragmented identity and network access environments. Multiple identity providers, overlapping network access tools, and point solutions from different vendors are common, especially in large enterprises.

The research shows that this fragmentation is persistent. On average, organizations use five identity solutions and four network access solutions, often from different vendors. Nearly half of security leaders say they are overwhelmed by vendor sprawl, a figure that has increased year over year.

That fragmentation has real consequences:

Visibility becomes partial and delayed
Policy changes take longer to propagate
Gaps emerge between tools, creating opportunities for misuse and attack

These gaps don’t just create operational overhead. They slow decision‑making and make it harder to respond consistently as risk changes. In an environment where AI systems and attackers alike can move quickly, those delays matter more than they used to.

32% of organizations say their access management solutions are duplicative, 40% say they have too many different vendors.

Access Incidents Are Not Always Malicious

Another important takeaway from the research is that access‑related incidents are not solely the result of attacks. Organizations report a near‑even

split between malicious incidents (53%) and accidental ones (47%).

This points to risk driven by complexity, unclear ownership, and misaligned controls, not just adversarial behavior. As employees adopt generative AI tools and teams deploy agents faster than policies can be updated, unintentional misuse becomes more likely.

AI doesn’t create these conditions on its own, but it does amplify them. When permissions are broad, visibility is limited, and enforcement is inconsistent, even small mistakes can escalate quickly.

Top causes of identity and network access incidents. 97% of organizations have had an incident in the past 12 months.

Why an Access Fabric Matters Now

As access environments grow more complex, security leaders are rethinking how access decisions are made and enforced across the enterprise. The research suggests that organizations using fewer, more integrated access tools have better visibility into activity and can respond more quickly as risk changes.

This shift is often described as moving toward an access fabric. An access fabric is not a single product or control layer. It is an architectural approach that treats access as a continuous, end‑to‑end system – using identity as the consistent decision point and enforcing those decisions across environments in near real time.

In practice, an access fabric enables:

A common identity foundation for employees, workloads, and AI agents
More immediate enforcement of access decisions across the network
Continuous signal sharing across identity, network, and security tools
Faster propagation of policy and risk changes without manual stitching

This model matters because AI systems and automated attacks operate at machine speed. Static access decisions or delayed enforcement create gaps that are difficult to detect and harder to close.

As a result, 64% of security leaders say they are consolidating identity and network access tools, citing complexity, visibility gaps, and slower response times in fragmented environments. Fewer, better‑integrated tools make it easier to apply consistent policy and adapt as new identities and access paths are introduced.

64% of organizations are consolidating tools across identity and network access. 94% of organizations prefer a comprehensive and integrated identity and access management platform.

Read the full report

To explore the full research, including practical insights and recommendations for building a unified access strategy, read the Secure access in the age of AI report.

- Kaitlin Murphy

Learn more about Microsoft Entra

Challenges with custom data provided resource reviews

ritmo2k — Tue, 17 Mar 2026 18:53:12 GMT

I was thrilled to see the ability to review disconnected applications in Entra, and even more thrilled to see that the permission and its description are available to the reviewer, which addresses a significant gap present in group-based reviews.

However, the current decision-tracking approach does not adequately replicate the closed-loop remediation model typically found in traditional IGA access reviews for integrated applications.

Requiring reviewers to upload confirmation that revocations have been completed is problematic. This approach does not mitigate the core risk: access may remain in place due to fulfillment errors or be incorrectly retained, and the reviewer may unknowingly validate an inaccurate state. This can lead to a compliance incident or audit finding.

A more effective solution would allow reviewers to upload a current export of access data, enabling the review system to reconcile intended revocations against the actual state. Any discrepancies could then be flagged for remediation where revocations were missed or have failed, or for validation where access was revoked and immediately reinstated (e.g., due to reviewer misjudgement), ideally supported by corresponding ticketing or justification.

There are currently a lot of gaps in Entra ID access reviews, and while this new feature arguably resolved the worst one, I think it's headed down the wrong path.

I am curious about other people's thoughts.

Entra ID Object Drift – Are We Measuring Tenant Health Correctly?

Menahem — Tue, 10 Mar 2026 05:35:20 GMT

In many enterprise environments:

Secure Score is green.

Compliance dashboards look healthy.

Yet directory object inconsistency silently accumulates.

Stale devices.

Hybrid join remnants.

Intune orphan records.

Over time, this becomes governance debt.

In large tenants this often leads to inaccurate compliance reporting and Conditional Access targeting issues.

I recently wrote a breakdown of:

• Entra ID drift patterns

• Hybrid join inconsistencies

• Intune orphan objects

• Lifecycle-based cleanup architecture

Curious how others approach object hygiene at scale.

Full article:

https://www.modernendpoint.tech/entra-id-cleanup-patterns

One pattern I keep seeing is duplicate device identities after re-enrollment or Autopilot reset.

Curious how others handle lifecycle cleanup in large Entra ID environments.

Cloud Kerberos Trust with 1 AD and 6 M365 Tenants?

heinzelrumpel — Tue, 03 Mar 2026 13:32:22 GMT

Hi,

we would like to enable Cloud Kerberos Trust on hybrid joined devices ( via Entra connect sync)

In our local AD wie have 6 OUs and users and devices from each OU have a seperate SCP to differnt M365 Tenants. I found this Article to configure the Cloud Kerberos Trust .

Set-AzureADKerberosServer
1
2
The Set-AzureADKerberosServer PowerShell cmdlet is used to configure a Microsoft Entra (formerly Azure AD) Kerberos server object. This enables seamless Single Sign-On (SSO) for on-premises resources using modern authentication methods like FIDO2 security keys or Windows Hello for Business.

Steps to Configure the Kerberos Server

1. Prerequisites

Ensure your environment meets the following: Devices must run Windows 10 version 2004 or later. Domain Controllers must run Windows Server 2016 or later. Install the AzureADHybridAuthenticationManagement module: [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12 Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

2. Create the Kerberos Server Object

Run the following PowerShell commands to create and publish the Kerberos server object:

Prompt for All Credentials:

$domain = $env:USERDNSDOMAIN
$cloudCred = Get-Credential -Message 'Enter Azure AD Hybrid Identity Administrator credentials'
$domainCred = Get-Credential -Message 'Enter Domain Admin credentials'

Set-AzureADKerberosServer -Domain $domain -CloudCredential $cloudCred -DomainCredential $domainCred

As I understand the process, a object is created in local AD when running

Set-AzureADKerberosServer

What happens, if I run the command multiple times, for each OU/Tenant. Does this ovveride the object, or does it create a new objects?

Priority between CIDR and FQDN rules in Microsoft Entra Private Access (GSA)

Kandrik — Sat, 28 Feb 2026 14:27:17 GMT

Hello

Question about prioritization between CIDR and FQDN rules in Microsoft Entra Private Access (GSA) Question: Hello everyone, I have a question about how rules are prioritized in Microsoft Entra Private Access (Global Secure Access). In my environment, I configured the following: I created an Enterprise Application using a broad CIDR range (10.10.0.0/16) to represent the entire data center. Within the same environment, I created other Enterprise Applications using specific FQDNs ( app01.company.local, app02.company.local) with specific ports. All rules are in the same Forwarding Profile. I noticed that in the GSA client rules tab there is a “Priority” field, and apparently the rules are evaluated from top to bottom. My question is: When there is an overlap between a broad CIDR rule and a more specific FQDN-based rule, which one takes precedence? Is there some internal technical criterion (DNS resolution first, longest prefix match,), or is the evaluation purely based on the order displayed? Is there a risk that the CIDR rule will capture traffic before the FQDN rule and impact granular access control? I want to make sure my architecture is correct before expanding its use to production. Could someone clarify the actual technical behavior of this prioritization?

Priority Handling in GSA Client Forwarding Profile Rules

Shuji_Noguchi — Fri, 27 Feb 2026 02:50:53 GMT

Hello,

I would like to provide feedback and propose a functional improvement regarding priority control for forwarding rules in Global Secure Access (GSA).

In our environment, we are using Microsoft Entra Private Access with a combination of CIDR-based rules and FQDN-based rules.

We understand that it is not possible to create Enterprise Applications with overlapping IP address ranges. Based on this limitation, our current operational model is as follows:

Administrators create Enterprise Applications using CIDR ranges that broadly cover entire datacenter networks.
Access for application owners to specific servers and ports is defined using FQDN-based rules.

With this type of configuration, when reviewing the list of rules shown in the GSA Client → Forwarding Profile → Rules tab, we can see that each rule is assigned a Priority, and the rules appear to be evaluated sequentially from top to bottom.

From this behavior, it is clear that:

DNS rules are evaluated first
Enterprise Application rules are evaluated next
Quick Access rules are evaluated last

However, between CIDR-based Enterprise Application rules and FQDN-based Enterprise Application rules, there does not appear to be a clear or explicit priority model. Instead, the position — and therefore the evaluation order — seems to depend on the order in which the Enterprise Applications were created.

As a result, even when we intend to apply a more specific FQDN-based rule for a particular host, the broader CIDR-based administrative rule may be evaluated first. In such cases, access can be unintentionally blocked, preventing us from achieving the intended access control behavior.

After understanding this mechanism, we have been working around the issue by carefully controlling the creation order of Enterprise Applications — creating host-specific FQDN-based applications first, followed by broader CIDR-based rules. While this approach avoids the issue, it significantly increases administrative complexity and makes long-term management more difficult.

Based on this experience, we would strongly appreciate enhancements such as:

The ability to manually control rule evaluation order in the UI, or
More intelligent and predictable automatic prioritization between FQDN-based and CIDR-based rules

Such improvements would greatly enhance usability, predictability, and maintainability of GSA forwarding rule configurations.

Thank you for considering this feedback.