What breaks in Entra ID this November: MemberOf, the PIM beta APIs and agent permissions

Microsoft is retiring or tightening several Entra ID features within a few days of each other, and two of them fail quietly. Find every MemberOf rule in your tenant and every script still calling the old PIM beta API, today. After that, deal with the agent identity permission change, check the Conditional Access policy that switches itself on, and plan for the dates further out.

The MemberOf change is the one to worry about. A group built on MemberOf doesn't vanish on 3 November. It freezes. Whoever was in it stays in it, and nobody new gets added. If that group hands out licences, Teams and SharePoint access or a Conditional Access exclusion, new hires go without and leavers keep what they had.

The PIM change has already happened. A script, runbook or reporting tool still calling the old beta endpoint for role assignments has been getting nothing back since 28 October. If a weekly report of eligible admins came back empty this week, start there.

The agent change mostly hits teams building their own agents with app-only authentication. Microsoft's own documentation hasn't caught up with it yet, which we come back to below.

There's a detail in Microsoft's own preview notes worth knowing. Even before the retirement, removing someone from a child group didn't take them out of the MemberOf group until the rule was edited, and only direct members of the source groups ever counted. So a MemberOf group may already hold people who left its source groups months ago. Check the membership, not just the rule.

Microsoft's reason for dropping MemberOf is performance. Learn says it can slow dynamic membership processing for every group in the tenant, and the Message Center notice adds that a single rule is enough. Microsoft says it's working on an alternative but hasn't given a date, so plan with what exists today. Either rewrite the rule on user attributes, or turn the group into an assigned group that someone actually maintains.

Assigned groups need an owner and a process, or the list rots. An access package with an approver, or a lifecycle workflow driven by HR data, usually does the job. Where the MemberOf group only glued two or three groups together for one app, assign those groups to the app directly and retire the combined one.

The PIM retirement is about plumbing. Iteration 2 lived under /beta/privilegedAccess, with one segment for Entra roles and one for Azure resources. Iteration 3 splits the work: Entra roles and PIM for Groups sit in Microsoft Graph, and Azure resource roles sit in Azure Resource Manager. You no longer write an assignment directly. You create an assignment or eligibility schedule request, and PIM builds the schedules from it. Microsoft's iteration 2 page maps the Azure resource calls to their Resource Manager versions and points to migration guidance for Entra roles, so once you've found the callers the rewrite is mostly mechanical.

Until now every agent identity blueprintdefinitionThe template Entra Agent ID stamps agent identities out of. Its principal in your tenant is the thing that needs CreateAsManager to make new ones. got AgentIdentity.CreateAsManager without anyone approving it. That's the permission that lets a blueprint create agent identities in your tenant. Microsoft's Message Center notice MC1506728 says that from 4 November an admin has to grant it as a Microsoft Graph application permission. Existing agent identities and blueprints stay put, and agents that use a directory role to create identities aren't affected.

Here's the catch. Microsoft Learn's page on how agent identities are created still says the permission is granted automatically and can't be revoked. In October an admin asked on Microsoft Q&A whether Copilot Studio's blueprint would need an explicit grant, and the AI-generated answer leaned on that same page. Go by the notice instead. Admins have been able to grant the permission explicitly since 16 October, so grant it now and test app-only creation before enforcement reaches your tenant. After that, a request that relied on the automatic grant fails with a 403.

Microsoft-managed Conditional Access policies appear in your tenant in report-only modedefinitionConditional Access runs the policy and logs what it would have done, but doesn't block anyone. It's how you find out who'd be hit before switching it on.. If you leave them there, Microsoft turns them on no less than 30 days later and, according to Learn, emails and posts in Message Center two weeks before. Learn also says some policies can be switched on faster. In October Microsoft sent some tenants a Message Center reminder (MC1507808) that the high-risk users policy was about to turn on.

When that policy is on, users Entra ID Protection rates as high risk have to clear the risk themselves before they get back in. Microsoft's notice tells you to make sure users have MFA registered so they can do that. Exclude break-glass accounts, and read the policy's Policy impact tab before it flips.

# Run this before 3 November: groups still on memberOf
Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" -Property Id,DisplayName,MembershipRule |
  Where-Object { $_.MembershipRule -match 'memberof' } | Select-Object DisplayName, Id
# Then find scripts still on PIM iteration 2
grep -rni "beta/privilegedAccess" ./automation
# example output
Finance-All-Licensed    3f1c...
pim-report.ps1:42: beta/privilegedAccess

We run Entra ID estates for companies that rely on them for licences, admin roles and app access, and we start with the inventory: what's built on preview features, what calls beta APIs, and which groups feed which policies. If you want a hand clearing MemberOf before the date, or moving PIM automation to iteration 3, see our Microsoft Entra page, bring in an Entra engineer, or read how our identity and access management practice works. Building agents? Our AI agent identity work covers consent and ownership. Not sure where you stand? Start with the free assessment.