Your AI agents are already acting inside your environment. The real question is whose identity they’re using to do it. Most teams stand up an agent in Copilot Studio or Azure AI Foundry, wire it to a few APIs with a shared secret or a borrowed service account, and move on. Then a security review lands and nobody can answer the basics: which agent did this, what is it allowed to touch, and how do we shut it off?

That’s not an AI problem. It’s an identity problem — and we already know how to solve those.

What we’re actually talking about

An AI agent that calls APIs, reads data, and takes actions is a workload. In Microsoft Entra, workloads are represented as workload identities — applications, service principals, and managed identities that authenticate and access resources without a human signing in. The trouble is that these non-human identities behave differently from user accounts. They can’t do MFA, they often have no formal lifecycle, and they need their credentials stored somewhere. That combination makes them both harder to manage and a juicier target.

When you bolt an agent onto a shared service account, you inherit every one of those weaknesses and add a new one: you lose attribution. If five agents share one principal, “who did this” has no answer.

The fix is to give the agent a real, governed identity of its own and apply the same Zero Trust discipline you’d give any workload.

Why this matters now

Agents are multiplying faster than the controls around them. Each one is a new set of permissions, a new credential, and a new path into your data. Get the identity layer wrong and a single compromised agent becomes lateral movement across everything that account could reach. Get it right and an agent is just another principal you can scope, monitor, and revoke — no new security model required.

Microsoft has been building toward exactly this. Microsoft Entra Agent ID is now generally available, extending Entra’s identity and security framework to AI agents. It gives each agent a first-class directory identity, supports agents built on Microsoft and non-Microsoft platforms, and brings the same identity-driven protections — adaptive access, real-time risk detection, lifecycle management, and full audit logging — that you already apply to users and workloads. That’s the foundation. The discipline below is how you use it.

The sequence that works

1. Give each agent its own identity

One identity per agent. Not a shared service account, not a human’s token. Entra Agent ID is built for this — a dedicated directory identity per agent so every action is attributable and revocable. If you can’t point at one principal and say “this agent, these actions,” you don’t have governance yet.

2. Scope permissions to least privilege

Grant the narrow API permissions the agent actually needs, and nothing else. Broad “just in case” access is how one compromised agent turns into lateral movement. Audit for unused permissions (granted but never called) and reducible ones (where a lower-privilege scope would do the same job), and strip them. The smaller the grant, the smaller the blast radius.

3. Kill standing secrets

A long-lived client secret sitting in a config file is the credential an attacker hopes you forgot about. Use managed identities where the agent runs in Azure, and workload identity federation where it doesn’t — so the agent exchanges a trusted token from an external provider for a short-lived Entra access token instead of holding a static secret. No secret to leak, no certificate to expire, nothing to rotate by hand.

4. Put Conditional Access on the workload

Conditional Access isn’t just for users. Conditional Access for workload identities lets you apply policy to service principals: block sign-ins from outside known public IP ranges, and respond to risk detected by Microsoft Entra ID Protection. That’s the same control plane you already run for people, pointed at your agents. Note that it applies to single-tenant service principals registered in your tenant and requires Workload Identities Premium — and that managed identities are governed through access reviews rather than CA policy.

5. Make it auditable and disposable

Log every action to the agent’s own identity so the audit trail is real. Run access reviews on your non-human identities the way you do for users — agents accumulate stale access too. And rehearse decommissioning: you should be able to kill an agent’s access in minutes, not file a ticket and wait weeks. If you can’t turn it off quickly, you don’t really control it.

How I’d approach a rollout

Don’t try to boil the ocean. Start with an inventory — find the agents already running and the identities they’re using. The shared-secret offenders are your first targets: re-platform them onto dedicated identities, swap the static credential for a managed identity or federated credential, and tighten the permission grant on the way. Wrap Conditional Access around them, turn on logging, and schedule the first access review. Then make “agent gets its own governed identity” a gate in your deployment process so the next wave is born compliant instead of retrofitted.

Bottom line

AI agents don’t need a brand-new security model. They need the identity-centric one you already have — applied before they hit production, not after the incident. Treat every agent as a non-human identity, give it least privilege, kill the standing secrets, and keep it auditable and disposable. The tooling is here. The discipline is the part you own.

For more information

• Microsoft Entra Workload ID overview
• Conditional Access for workload identities
• What is Microsoft Entra Agent ID?
• Workload identity federation
• Securing workload identities with Microsoft Entra ID Protection

Users don’t always pick the strongest credential available to them. That isn’t a training failure as much as a default-path problem. If password is familiar and easy to find, many people will keep choosing it even after you’ve rolled out passkeys or other stronger methods.

System-preferred authentication in Microsoft Entra ID is now generally available for both first-factor and second-factor authentication when the setting is in Microsoft managed state. Entra evaluates the user’s registered credentials and prompts for the highest-ranked method at each step of the sign-in flow.

What it is

System-preferred authentication changes the prompt order. Instead of relying on a user’s personal default or habit, Microsoft Entra ID looks at the methods registered for that user and presents the most secure available option.

For example, if a user has both a password and a passkey, the system can prompt for the passkey first. The user can still choose another available method, but the secure option becomes the front door instead of the alternate route.

The important GA expansion is first-factor coverage in Microsoft managed mode. Previously, system-preferred behavior was associated with the MFA step. Now, in Microsoft managed state, the same idea applies to both the initial sign-in and the second factor. In the explicitly Enabled state, the feature applies to second-factor only. Disabled means no change to sign-in logic.

Why it matters

Security teams spend a lot of effort getting stronger methods registered. The value of that work drops if users continue signing in with weaker options because those options appear first.

This is especially relevant for passkeys, certificate-based authentication, Windows Hello for Business, Authenticator passwordless sign-in, and other stronger credentials. System-preferred authentication helps turn registration into usage. It also reduces the need to convince every user to make the best manual choice every time.

How it works

Microsoft documents a ranked order that starts with Temporary Access Pass for recovery, then phishing-resistant methods such as passkeys and certificate-based authentication, followed by Microsoft Authenticator notifications, external MFA, TOTP, telephony, QR code for frontline worker scenarios, and password.

That order can evolve as the security landscape changes. Conditional Access policies and authentication strength requirements still matter; system-preferred authentication does not override them. Also note the scope: this policy targets users and groups, not devices.

There are a few operational details worth calling out. Policy changes might not apply on the very next sign-in, but they apply to subsequent sign-ins. Conditional Access is validated for second-factor authentication and authorization after authentication. And if certificate-based authentication is high in the order but a user’s device can’t complete it, the user might need to choose another sign-in method.

How to enable it

By default, system-preferred authentication is Microsoft managed for all users. To review or change it, sign in to the Microsoft Entra admin center as at least an Authentication Policy Administrator. Go to Microsoft Entra ID, then Authentication methods, then Settings. Under System-preferred authentication, choose Microsoft managed, Enabled, or Disabled, and configure included or excluded users or groups as needed.

If you want first-factor and second-factor coverage, use Microsoft managed. If you want system-preferred logic only for MFA, use Enabled. If you need to pause the behavior for a rollout issue, use Disabled or exclude a group. Excluded groups take precedence over included groups.

You can also manage the setting through Microsoft Graph by updating the authentication methods policy and the systemCredentialPreferences configuration. That route is useful when you want change control, staged deployment, or repeatable configuration across tenants.

Bottom line

This is one of those changes that looks small in the UI but changes real behavior. If you’ve invested in passkeys or other stronger credentials, system-preferred authentication helps those methods become the path users actually take.

For more information, see System-preferred authentication in Microsoft Entra ID.

Agent identities are becoming part of the real identity estate. That means they need the same accountability model we expect for users, workload identities, applications, and privileged roles: someone has to own the access, review it, and answer for it when the context changes.

Agent Identity Sponsorship Transitions in Microsoft Entra ID Governance are now generally available. The feature adds sponsor-focused tasks to Lifecycle Workflows so agent ownership does not quietly go stale when the original human sponsor moves or leaves.

What it is

Microsoft Entra agent identity governance uses sponsors to keep a human accountable for an agent identity’s lifecycle and access decisions. Sponsorship is especially important because agents can act across services, workflows, and business processes. If the sponsor leaves the organization, changes teams, or no longer owns the business process, the agent should not sit in a governance blind spot.

The generally available sponsorship transition tasks plug into Microsoft Entra Lifecycle Workflows. The Microsoft Learn article lists three sponsor-related tasks:

• Send email to manager about sponsorship changes.
• Send email to cosponsors about sponsor changes.
• Transfer agent identity sponsorships to manager.

These tasks are classified as mover and leaver tasks. That detail matters. You add them to mover or leaver workflow templates, not to every workflow type.

Why it matters

A stale owner field is not just an administrative inconvenience. It creates an accountability problem. When an auditor, incident responder, or security architect asks who approves an agent’s access, “the sponsor left six months ago” is not an acceptable answer.

The practical value here is continuity. Managers can be notified when sponsorship changes are about to happen. Cosponsors can be informed so they are not surprised by ownership transitions. In the most direct pattern, sponsorship can transfer to the original sponsor’s manager, giving governance teams a reasonable default owner instead of an orphaned agent identity.

Here is what I would watch for: do not treat manager transfer as a substitute for policy. It is a safety net. You still need clear ownership criteria for which agents should exist, which access packages they can use, who reviews them, and what happens when the business process ends.

How to enable it

Start by confirming that your organization is using the Microsoft Entra capabilities required for agent identity governance. Microsoft Learn notes that Microsoft Entra Agent ID is available for all Microsoft Entra customers, while governance and security features for agents map to the relevant Entra licensing. For ID Governance for agents, Microsoft Entra ID P1 is listed. If agents integrate with Microsoft Agent 365, that integration requires Microsoft Agent 365 licensing for each user.

To configure sponsor workflow tasks:

1. Sign in to the Microsoft Entra admin center as at least a Lifecycle Workflows Administrator.
2. Go to ID Governance > Lifecycle workflows > Workflows.
3. Create a new workflow from a mover or leaver template, or edit an existing mover or leaver workflow.
4. On Basics, provide a display name and description, choose the trigger, and continue.
5. Configure the workflow scope so it catches the sponsor transitions you intend to govern.
6. On Tasks, add the sponsor task you need: notify the manager, notify cosponsors, transfer sponsorship to the manager, or a combination.
7. Review the workflow and select Create.

Be deliberate about scope. A workflow that is too narrow misses transitions. A workflow that is too broad creates noise and trains people to ignore notifications.

Design guidance

I would separate notification and transfer decisions. Notifications are low-risk and useful for visibility. Transfer is more consequential because it changes who is accountable for the agent. For higher-risk agents, use transfer as a bridge and follow it with a review process so the new sponsor explicitly confirms ownership.

Also document the expected behavior for cosponsors. If a sponsor leaves, should a cosponsor become the primary owner, or should the manager inherit it? The feature gives you workflow tasks; your operating model should define the policy.

Bottom line

Agent identities are only governable if ownership stays current. Sponsorship transitions make that easier by connecting agent ownership to lifecycle events you already manage. If your organization is building or adopting agents, configure this before you have a pile of agent identities with no accountable human behind them.

For more information, see Agent identity sponsor tasks in Lifecycle Workflows.

Deleting an app registration is a strong move. Sometimes it is the right move, but often you need something more measured: stop the app from getting new tokens, preserve the configuration, and give the team time to investigate dependencies or suspicious behavior.

App Deactivation in Microsoft Entra ID is now generally available, and it gives application owners and admins that middle path. You can deactivate an app registration to block new access token issuance while keeping the application metadata, permissions, and configuration available for review or reactivation.

What it is

App Deactivation sets the application’s disabled state so it cannot receive new access tokens. Users cannot sign in to the application, and the application cannot access protected resources with newly issued tokens. Existing access tokens are not instantly destroyed; they remain valid until their configured lifetime expires.

The important distinction is preservation. Deactivation keeps application configuration, permissions, metadata, and the service principal object. The application remains visible in the Enterprise applications list, and you can reactivate it later if the investigation or retirement plan changes.

That makes it different from deletion. Deletion is still available, but it is not always what you want during incident response or a controlled application shutdown.

Why it matters

Security teams often need a reversible containment action. If an app looks suspicious, you may not want to remove all evidence and configuration before you understand what happened. If an app is being retired, you may want to stop new use while owners confirm whether any workloads still depend on it.

Deactivation also helps with governance. It creates a visible state that says, “this app should not be used,” without pretending the object never existed. That is useful for app rationalization, owner cleanup, and post-incident review.

There is a subtle ownership point too. Microsoft Learn notes that if an app has assigned owners, those owners appear in the deactivation pane. If you want to prevent others from reactivating the app, review and remove other owners before deactivation. That is the kind of operational detail that matters in a real containment scenario.

How to deactivate an application

You need the right permissions before you start. Microsoft Learn lists Cloud Application Administrator or Application Administrator as built-in roles that can deactivate an app. A custom role can also work if it includes microsoft.directory/applications/disablement/update. For Microsoft Graph, the relevant permissions include Application.ReadWrite.All or Application.ReadWrite.OwnedBy for owned apps.

To deactivate from the Microsoft Entra admin center:

1. Sign in to the Microsoft Entra admin center as at least a Cloud Application Administrator.
2. Go to App registrations.
3. Find and select the app registration you want to deactivate.
4. Select Deactivate on the app registration page.
5. Review the impact in the Deactivate app registration pane.
6. Review app owners and remove owners if you need to prevent unauthorized reactivation.
7. Select Deactivate again to confirm.
8. Verify that the app registration state reflects the deactivated status.

Deactivation takes effect immediately for new token issuance. Existing tokens expire based on their lifetime and any token lifetime policies in place.

How to monitor and reactivate

You can view deactivated applications from the Deactivated applications tab under App registrations. You can also check an enterprise app’s activation status under Enterprise applications > Properties.

For automation, Microsoft Learn documents Microsoft Graph beta examples using the isDisabled property on the application object. For example, setting isDisabled to true deactivates the application, and querying applications where isDisabled eq true lists deactivated apps.

One caution: deactivation is performed on the app registration, which is the application object. The deactivated state is reflected on the enterprise app, which is the service principal object. You cannot deactivate the service principal directly. You can disable sign-in for a service principal in a tenant, but that is a different control.

Bottom line

App Deactivation is a practical control because it fits how teams actually work. You can contain, investigate, document, and decide without racing into a delete-or-keep choice. For incident response and app retirement, that reversible pause button is exactly what many tenants have needed.

For more information, see Deactivate an app registration.

Customer identity migrations are rarely blocked by a lack of architecture diagrams. They’re blocked by the risk of breaking sign-in for real users. If millions of customers suddenly need password resets, re-registration, or support calls, the migration has failed no matter how clean the target platform looks.

High Scale Compatibility mode, or HSC mode, is now generally available for Microsoft Entra External ID. It gives large Azure AD B2C customers a tenant-level coexistence path so applications can move toward External ID endpoints while existing B2C user credentials remain in place.

What it is

HSC mode is designed for established, high-scale Azure AD B2C environments that need to migrate to Microsoft Entra External ID without forcing a disruptive user directory migration first. In this mode, organizations can build new External ID applications, connect them to the existing B2C user base, and validate sign-in behavior before moving more apps.

The key idea is continuity. Existing users keep their credentials during coexistence, while teams rebuild or onboard applications against External ID endpoints. Microsoft’s guidance positions the standard migration path for smaller tenants, while HSC mode is intended for larger B2C tenants where user continuity and phased adoption are the priority.

This is not a casual toggle. The Learn documentation is clear that enabling HSC mode is a significant tenant-level change, and reversing it requires Microsoft support. Some advanced customization capabilities are limited in HSC mode and should be reviewed before rollout.

Why it matters

For consumer identity, the blast radius is external. A broken employee sign-in is bad. A broken customer sign-in can become a revenue, reputation, and trust problem in minutes.

HSC mode matters because it lets teams reduce migration risk. You can validate token claims, application behavior, custom domains, user flows, and sign-up/sign-in journeys before broad adoption. You can move applications incrementally rather than betting the business on a single cutover weekend.

How to enable it

Start with planning, not the API call. If your tenant is below the scale where a standard migration works, use the standard path. For larger B2C tenants, run the B2C Policy Analyzer and review HSC mode limitations, including gaps around some social identity providers, passkeys, age gating, admin portal experience, and Conditional Access scenarios.

Before enabling, contact your Microsoft account team or open a support ticket to request allowlisting for HSC mode. That allowlisting is required before Stage 1. Also check custom attributes: every custom attribute needs a nonempty description, because the enable API syncs custom attributes into the External ID context and can fail when descriptions are missing.

Once allowlisted, enable HSC mode through Microsoft Graph by calling the beta externalIdHybridModeConfiguration endpoint under policies/authenticationFlowsPolicy. The caller needs the Policy.ReadWrite.AuthenticationFlows permission. After enablement, allow up to one hour for changes to take effect.

Next, review token claims for coexistence. Pay close attention to apps that depend on email, sub, or oid. In External ID, sub is not set to the same value as oid, so applications that assumed they matched need to be adjusted. Then register the first External ID application, configure user flows, optionally configure native authentication, custom URL domains, Azure Front Door, or custom authentication extensions, and validate end to end.

My recommendation: migrate one representative application first, inspect tokens, verify sign-in logs, test existing and new users, and only then expand.

Bottom line

HSC mode is valuable because it accepts reality: high-scale customer identity migrations need coexistence. It gives teams a safer path from Azure AD B2C to Microsoft Entra External ID without asking customers to pay the price for backend modernization.

For more information, see Enable External ID High Scale Compatibility mode.

Multi-tenant environments are normal now. Subsidiaries, mergers, regional tenants, regulated business units, and partner operations all create the same identity problem: access needs to cross tenant boundaries, but group management often gets duplicated and messy.

Cross-tenant group synchronization is now generally available. It extends Microsoft Entra cross-tenant synchronization so organizations can synchronize security groups and memberships from a source tenant into one or more target tenants, supporting cleaner shared application access and authorization decisions.

What it is

Cross-tenant synchronization already helps automate creating, updating, and deleting B2B collaboration users across tenants in an organization. With group synchronization, the same model can include security groups. A group managed in the source tenant can be made available in a target tenant so apps and resources there can use consistent group-based controls.

Microsoft’s documentation describes cross-tenant synchronization as a push process from the source tenant. Users and groups in scope are configured in the source tenant, attribute mapping is configured there, and the target tenant uses inbound cross-tenant synchronization settings to allow synchronization. Target tenant administrators can stop synchronization at any time.

The GA announcement notes that cross-tenant group synchronization requires Microsoft Entra ID Governance licensing. Existing licensing requirements for cross-tenant user synchronization remain unchanged.

Why it matters

Without this, many organizations end up rebuilding the same groups in multiple tenants or relying on manual processes to keep access aligned. That is fragile. Membership drift becomes normal, deprovisioning depends on someone remembering every copy of a group, and authorization decisions vary by tenant.

Centralizing group ownership in a source tenant gives admins a clearer source of truth. Target tenants can still enforce their own policies, but they can base access on synchronized group objects and memberships instead of duplicate local constructs.

This is especially useful for shared applications, resource authorization, and governance scenarios where accountability needs to stay with one team even though access spans multiple tenants.

How to enable it

Start by confirming licensing and scope. Cross-tenant group synchronization requires Microsoft Entra ID Governance or Microsoft Entra Suite licensing for the group sync capability. Then identify the source tenant that owns group membership and the target tenant or tenants where those groups need to be available.

In the target tenant, configure cross-tenant access settings for the partner/source tenant. The cross-tenant synchronization settings are inbound organizational settings and include controls to allow user synchronization and group synchronization into the tenant. The automatic redemption setting is also important for cross-tenant synchronization because it suppresses invitation and consent friction when configured correctly on both sides.

In the source tenant, configure cross-tenant synchronization. Assign the users and security groups in scope, review attribute mappings, and test provisioning into the target tenant. Because this uses the Microsoft Entra provisioning engine, treat it like any other provisioning rollout: start narrow, validate objects and memberships, check provisioning logs, and then expand.

A practical pilot might include one source security group, one target tenant, and one application that uses the synchronized group for access. Confirm that membership changes in the source tenant appear in the target tenant, that removed users are deprovisioned as expected, and that the target application evaluates the synchronized group correctly.

Also decide who owns ongoing operations. Source tenant admins manage membership. Target tenant admins control whether synchronization is allowed and can stop it. That split is healthy, but it needs to be documented.

Bottom line

Cross-tenant group synchronization is not just a convenience feature. It reduces identity drift across tenants and gives organizations a cleaner way to apply group-based access in multi-tenant environments without copying the same administrative work everywhere.

For more information, see What is cross-tenant synchronization in Microsoft Entra ID?.

Device cleanup always carries a little tension. Delete the wrong object and you might lose more than a stale record; you can lose recovery data and create extra work for endpoint teams. Device soft delete adds a safer recovery model for Microsoft Entra device objects.

This feature is in Public Preview, so use it to validate your operational process before you depend on it for production recovery.

What it is

Device soft delete moves deleted Microsoft Entra device objects into a suspended, recoverable state instead of hard deleting them immediately. During the preview, supported Microsoft Entra joined, hybrid joined, and Microsoft Entra registered devices can remain recoverable for up to 30 days.

While a device is soft deleted, it is removed from active device lists and can’t authenticate to cloud resources protected by Microsoft Entra ID. Microsoft Entra preserves important device data in the soft-deleted container, including BitLocker recovery keys, LAPS passwords, device identity, and key material. After 30 days, or after an explicit permanent delete, the device is hard deleted.

Devices without a recognized trust type (for example, objects created directly via Microsoft Graph) and certain specialty device types — secure VMs with managed identities, non-persistent VDI instances, and printers — aren’t supported in preview and are hard deleted immediately.

Why it matters

The value is simple: accidental deletion becomes recoverable. That matters for portal mistakes, cleanup scripts, and sync scope changes that remove more devices than intended. It also matters because device objects often carry security artifacts that are painful or impossible to recover after a hard delete.

There is a useful governance angle too. Soft-deleted devices still count toward directory object quota, though Microsoft documents tombstone objects as counting less than active objects. That means cleanup still matters, but admins get an undo window.

How to test it in preview

Use test devices first and involve both identity and endpoint administrators.

1. Pick a Microsoft Entra joined or Microsoft Entra registered test device.
2. Delete the device using an approved role. Cloud Device Administrators, Intune Administrators, and Global Administrators can soft delete, restore, and permanently delete devices; device owners can delete their own device but can’t restore it.
3. Query deleted device objects with Microsoft Graph beta deleted items endpoints or Microsoft Graph PowerShell.
4. Restore the device and confirm it returns to the active directory container.
5. Validate the operational after-effects: the device might need sign-in or reboot, and compliance remains false until the device checks in with its management authority and completes a fresh compliance evaluation.

During preview, Microsoft documents restore through Microsoft Graph API or PowerShell. A portal experience for viewing and restoring soft-deleted devices is planned for general availability, so build your pilot process around the available tools.

What to watch during the pilot

Measure the full recovery path, not just the restore command. Confirm who can find the soft-deleted object, who can restore it, how long the restored device takes to appear in operational tools, and what endpoint action is needed afterward. I would also test a near-miss scenario with a cleanup script in a lab tenant, because automation is where accidental deletions usually become painful at scale.

Bottom line

Device soft delete is a practical safety net. It doesn’t replace disciplined device lifecycle management, and it doesn’t make hard delete safe. But it gives admins a recoverable path when cleanup goes sideways. Test it with real endpoint workflows now, especially if your organization relies on BitLocker recovery keys or LAPS data tied to device objects.

For more information, visit Device soft delete in Microsoft Entra ID.

Partner federation is rarely as tidy as the architecture diagram. One company might use a shared identity provider, another might route authentication through a parent organization, and the email domain you see on the invitation might not match the IdP endpoint that actually owns sign-in. Domainless SAML federation gives Microsoft Entra External ID a more flexible way to handle those cases.

This capability is in Public Preview, so treat it as something to test with a controlled partner scenario before you make it a broad onboarding pattern.

What it is

Domainless SAML/WS-Fed federation lets external users authenticate with credentials managed by their own identity provider, even when their email domain isn’t pre-matched to an IdP domain in your tenant. The user can redeem an invitation or sign in to an app or resource, get redirected to the external IdP, and return to Microsoft Entra after successful authentication.

The important shift is practical: federation can follow the partner’s authentication reality, not only the visible email suffix. That matters when partners have acquisitions, shared services, subsidiaries, or identity platforms that don’t map one-to-one with mail domains.

Why it matters

Without this flexibility, admins often spend too much time on domain plumbing before a partner can get to the app they actually need. That can lead to awkward workarounds: extra accounts, manual exception handling, or invitation flows that create confusion for the guest user.

With domainless federation, you can keep the user anchored to the partner’s own IdP-managed account while reducing the dependency on a perfect domain match. You still need to configure the federation correctly, validate claims, and work with the partner on DNS requirements where needed. But the design gives you a cleaner path for B2B access when identity ownership is more complicated than the email address suggests.

How to test it in preview

Start small. Pick one partner, one app, and a test user that can validate the full redemption and sign-in path.

1. In the Microsoft Entra admin center, go to External Identities and add a SAML/WS-Fed identity provider.
2. Review whether the partner’s passive authentication endpoint requires a DNS TXT record because the authentication URL doesn’t match the target domain.
3. Configure the IdP issuer, passive authentication endpoint, certificate, and required claims. For SAML, make sure the response includes the required email claim and persistent NameID format.
4. Ask the partner to configure the relying party trust or equivalent configuration on their IdP.
5. Invite a test user and confirm the redemption or sign-in flow redirects to the external IdP and returns to Microsoft Entra.

Because this is preview, I wouldn’t start with a high-risk production app. Use a noncritical access path, document each assumption, and make sure the partner can support claim troubleshooting quickly.

What to watch during the pilot

The pilot should prove more than a successful redirect. Capture the issuer value, the passive authentication endpoint, the claims released by the partner, and the exact user experience during invitation redemption. If DNS TXT validation is needed, document who owns the partner-side change and how long it takes to propagate. Those details become your repeatable checklist for the next partner, and they help support teams troubleshoot without guessing.

Bottom line

This is one of those features that removes a small but persistent source of identity friction. If your B2B federation designs have been blocked by domain-to-IdP mismatch, this preview is worth testing now. Keep the pilot narrow, validate the claims and DNS path, and use what you learn to standardize partner onboarding later.

For more information, visit Add a SAML/WS-Fed identity provider.

Azure RBAC access needs process. Who requested Contributor? Who approved it? When does it expire? Those questions get harder as subscriptions, resource groups, and management groups multiply across an estate.

Microsoft Entra ID Governance now has a Public Preview that lets teams manage Azure RBAC role assignments through Entitlement Management access packages. Test it carefully, because it changes how platform access can be requested and governed.

What it is

Entitlement Management can assign Azure RBAC roles through access packages and catalogs. Administrators can add Azure resources at Management Group, Subscription, or Resource Group scope, then configure an access package so approved users receive an Azure role assignment automatically.

The feature supports both active and eligible role types. Active assignments grant the role directly. Eligible assignments require activation through Privileged Identity Management when access is needed, which is usually the better pattern for high-impact roles.

Microsoft documentation also notes support for built-in and custom Azure roles, and for employees and guests. That makes this useful for internal platform teams and controlled partner access.

Why it matters

Most organizations already have some kind of process for Azure access. The problem is that process is often split across tickets, spreadsheets, scripts, PIM assignments, and periodic reviews. Access packages bring the request, approval, assignment, expiration, and review model closer to the resource access itself.

That helps with least privilege. Instead of granting standing access because the approval process is too slow, teams can make role access requestable and time-bound. It also gives identity governance teams a clearer view of a person’s entitlements, including Azure roles assigned through packages.

How to test it in preview

Start with a low-risk subscription or resource group and a role that has clear business ownership.

1. Confirm licensing for Microsoft Entra ID Governance or Microsoft Entra Suite.
2. Make sure the administrator onboarding the Azure resource has Azure RBAC permissions to read, write, and delete role assignments at the selected Management Group or Subscription scope.
3. In the Microsoft Entra admin center, go to ID Governance > Catalogs and open the target catalog.
4. Add Azure Resources (Preview) to the catalog and select the Management Group or Subscription.
5. Open or create an access package, add the Azure resource, choose the scope, select Active or Eligible, and pick the Azure RBAC role.
6. Configure request, approval, assignment duration, and review policy, then test with a pilot user.

Pay attention to ownership. The cleanest pilots have a catalog owner, an Azure resource owner, and a reviewer who all agree on what access means and when it should expire.

What to watch during the pilot

The most important design choice is not the portal flow; it is the access model. Decide which Azure roles are safe to request, which should only be eligible, and which should stay outside access packages entirely. Then test expiration and removal as carefully as assignment. A governance process that grants access cleanly but fails to remove it on time just moves the risk to a different place.

Bottom line

This is a strong governance pattern for Azure privilege. It doesn’t remove the need for good role design, and it doesn’t make every role safe to request. But it brings Azure RBAC into a lifecycle model many identity teams already understand. Preview is the right time to test eligible assignments and decide where access packages can replace ad hoc access processes.

For more information, visit Assign Azure Role-based access control roles in Entitlement Management.

Passkeys are one of the better answers we have for phishing-resistant sign-in, but the rollout problem is real. A method can be secure, standards-based, and user friendly, and still fail if people never register it.

Microsoft Entra registration campaigns now support passkeys as a generally available target method. Instead of relying on email reminders, intranet posts, or manager escalations, you can nudge eligible users during sign-in after they complete multifactor authentication.

What it is

A registration campaign is an interrupt in the Microsoft Entra sign-in flow that prompts a user to register a stronger authentication method. The same capability has been used for Microsoft Authenticator adoption. With passkey support, the campaign can target Passkey (FIDO2), including synced passkeys and device-bound passkeys.

The timing is important. Users go through their normal sign-in, complete MFA, and then see a prompt to set up the targeted method. That is much better than asking them to remember a separate security task later. They are already in the authentication context, and the value is easier to explain.

Microsoft Learn calls out one important constraint: a registration campaign can target only one authentication method at a time. You cannot run a campaign for both Microsoft Authenticator and passkeys simultaneously in the same tenant.

Why it matters

Passwordless programs often stall in the gap between policy and behavior. The admin enables passkeys, publishes instructions, and sees adoption rise for the early adopters. Then it plateaus.

Registration campaigns give you a policy-driven adoption lever. You can include and exclude users or groups, define whether users can skip the prompt, and decide whether to use Microsoft managed behavior or explicit configuration. That makes the rollout measurable instead of voluntary and messy.

There is also a Zero Trust angle. If your target state is phishing-resistant MFA, you need a way to move users away from phishable and weaker methods without making the help desk the main adoption engine. A campaign does not replace communications and readiness, but it puts the prompt where the user can act on it immediately.

How to enable it

First, check prerequisites. Your organization must have Microsoft Entra multifactor authentication enabled. Microsoft Learn states that registration campaigns have no license requirements. For passkey campaigns, the Passkey (FIDO2) authentication method must be enabled in the Authentication methods policy, and Allow self-service setup must be enabled in the Passkey (FIDO2) method configuration.

To enable a passkey registration campaign in the Microsoft Entra admin center:

1. Sign in as at least an Authentication Policy Administrator.
2. Go to Entra ID > Authentication methods > Registration campaign.
3. Select Edit.
4. Set State to Enabled if you want to configure campaign settings yourself, or Microsoft managed if you want Microsoft-recommended defaults.
5. If you choose Enabled, set Authentication method to Passkey.
6. Configure snooze behavior. You can allow users to skip for a defined period, and you can choose whether limited snoozes are enabled.
7. Configure included and excluded users or groups.
8. Select Save.

When the state is Microsoft managed, Microsoft controls recommended settings, while you can still configure include and exclude targets. Microsoft Learn notes that Microsoft managed behavior is incrementally rolling out changes that target passkeys for MFA-capable users, with specific snooze defaults.

What users experience

A targeted user signs in, completes MFA, and gets prompted to set up a passkey if they do not already have an eligible local passkey for the current device and browser combination. That last point is easy to miss. The passkey nudge is evaluated per device and browser experience, not simply at the account level.

Users can select Skip for now if your policy allows it. If an error occurs during passkey registration, the user sees an error screen with a skip option, and those skips do not count toward the limited skip count.

Bottom line

Passkey adoption needs more than a policy toggle. Registration campaigns give admins a clean way to meet users in the sign-in flow and turn “we support passkeys” into actual registrations. Start with a focused pilot group, watch registration activity, tune exclusions, and then expand.

For more information, see Run a registration campaign to set up passkey or Microsoft Authenticator.