Entra November 2026 Changes: Turn Off Agent Blueprints

Any user can start creating AI agent blueprints in Entra from November 4. One toggle stops it. Two more Entra changes to check this month.

For your IT person: starting November 4, 2026, any regular user in Microsoft Entra can create agent blueprints, the templates behind AI agent identities, unless an admin turns that off. The fix is one setting. In the Entra admin center, go to Entra ID, then Users, then User settings, and set Users can create agent blueprints to No.

Two other Entra changes land around the same time. Self-service password reset stops accepting contact details users never registered, and the old ID Protection risk policies already stopped working on October 1. Here is what each one means and what to check.

Turn Off Agent Blueprint Creation

Microsoft announced the change in message center post MC1506733. From November 4, default users can create agent blueprints, with the rollout finishing in late November. You can change the setting now, and it applies once the rollout reaches your tenant.

Sign in to the Microsoft Entra admin center as at least a Cloud Application Administrator. Browse to Entra ID, then Users, then User settings. Set Users can create agent blueprints to No and save.

With the setting off, only administrators and users holding the Agent ID Developer role can create new agents. That is the cleaner model for most organizations: the people building AI agents get the role on purpose, and everyone else stays out.

Turning the setting off does not remove anything a user already created. If you want to see what exists, review your app registrations and agent identities in the Entra admin center after the rollout reaches your tenant.

What It Means for the Business

An agent blueprint is the starting point for an AI agent that can sign in and act inside your Microsoft 365 tenant. Letting anyone create one is a governance question rather than an emergency. Most small businesses want a short list of people who can build these, and a record of who did. The setting gives you that with no cost and no effect on staff who are not building agents.

Password Reset Now Needs Registered Methods

Microsoft is changing self-service password reset so it only accepts verification methods a user registered themselves. Phone numbers and email addresses that an admin typed in, or that sync from on-premises Active Directory, stop counting. The registration campaign started October 5, and enforcement begins in early November 2026 per message center post MC1325414.

Staff who never registered a method will hit a dead end on the reset page and call the help desk instead. The check takes a few minutes: in the Entra admin center, open Entra ID, then Authentication methods, then Activity, select User registration details, and filter SSPR Registered to Not Registered.

Step by step, with a PowerShell export of who is affected: Users Can’t Reset Their Password in Entra: SSPR Fix.

Old Risk Policies Stopped on October 1

The legacy user risk policy and sign-in risk policy configured inside Microsoft Entra ID Protection retired on October 1, 2026. If your tenant relied on them to force a password change or block a risky sign-in, that protection is gone until you rebuild it in Conditional Access.

Microsoft’s migration path is short. Create equivalent user risk and sign-in risk policies in Conditional Access, starting in report-only mode. Once the sign-in logs show they behave as expected, switch them to On. Then go to ID Protection, then Dashboard, and set Enforce policy to Disabled on the old user risk and sign-in risk policies.

Risk-based Conditional Access needs a Microsoft Entra ID P2 or Microsoft Entra Suite license, and the Conditional Access Administrator role is enough to create the policies. Tenants on Business Premium alone do not have risk conditions, so if the legacy policies were never there, nothing changed for you.

Quick Checklist

Set Users can create agent blueprints to No unless you have a reason to allow it. Pull the user registration details report and get every Not Registered user to aka.ms/mysecurityinfo before enforcement. Confirm your risk policies live in Conditional Access, not in the retired ID Protection settings.

If an account does get locked out after too many failed sign-ins, our guide to sign-in error code 50053 shows how to get the account back.