Major Microsoft Entra ID (formerly Azure AD) changes — October 2025

Executive summary

October 2025 brought several tenant-impacting changes for Microsoft Entra ID (formerly Azure Active Directory). The highest-impact items for administrators are:

• Mandatory MFA enforcement (Phase 2) beginning October 1, 2025 — applied to accounts that sign in to Azure CLI, Azure PowerShell, the Azure mobile app, IaC tools, and REST APIs for create/update/delete operations (read-only operations excluded). This specifically affects user-based service accounts; Microsoft recommends migrating such accounts to workload/mananged identities.
• Retirement of Microsoft Entra Permissions Management (MEPM) effective October 1, 2025 — sales and support discontinued; customers must follow offboarding guidance and plan replacements.
• High-severity Entra ID token vulnerability (CVE-2025-55241) publicly discussed in September/October 2025 — patched by Microsoft earlier; raised urgency around deprecated token flows (actor tokens, Azure AD Graph). Review apps for deprecated flows and apply mitigations.
• Private network connector update (release notes show Oct 10, 2025) — check connector versions and apply updates where auto-update doesn't run.
• Documentation refresh / “What’s new” updates (updated Oct 6, 2025) — catch recent rollouts (e.g., managed identities as federated credentials, entitlement management updates).

Bottom line for admins: verify MFA exposure for CLI/PowerShell/IaC, migrate user-based service accounts to workload identities, export MEPM data and plan replacements, patch and remove deprecated token flows from apps, and update connectors and Entra Connect where required.

Mandatory MFA enforcement — Phase 2 (what changed)

Microsoft started gradually enforcing multi-factor authentication (MFA) for resource-management actions (create/update/delete) initiated via Azure CLI, Azure PowerShell, the Azure mobile app, Infrastructure-as-Code (IaC) tools, and REST API calls starting October 1, 2025. Read-only operations are excluded from this enforcement.

The enforcement is aimed at reducing risky user-based service accounts and ensuring critical changes to Azure resources require a second authentication factor. Administrators should expect authentication failures from scripts and automation that use user accounts without MFA-capable auth flows. This change is documented on Microsoft Learn and announced in the Azure blog.

Who is impacted?

• Users and scripts that sign in using user credentials for Azure CLI / PowerShell and perform create/update/delete operations.
• Automation pipelines invoking IaC (Terraform, Pulumi, ARM/Bicep) that authenticate with interactive user tokens without MFA.
• Legacy REST API clients that use user tokens for privileged operations.
• User-based service accounts used as “service accounts” — Microsoft recommends migrating these to workload identities (managed identities or service principals with certificates/keys) that are not subject to user MFA policies.

Recommended immediate actions

1. Inventory authentication flows: find accounts used by CLI/PowerShell/IaC and identify automation that will be affected.
2. Migrate to workload identities: replace user-based service accounts with managed identities (system-assigned or user-assigned) or service principals using certificate-based authentication or client secrets stored securely in Key Vault with appropriate rotation policies.
3. Enable conditional access where appropriate: use Conditional Access policies to require MFA for admin/privileged roles but exempt managed workloads where secure identity patterns are used.
4. Update tool versions: ensure Azure CLI, Azure PowerShell, and SDKs are upgraded to versions that support the new authentication flows and device-based MFA where required.
5. Test in a staging tenant: before broad enforcement, validate scripts and pipelines in test environments with enforcement enabled.

Example: common migrations

From: automation script using a shared user account + password that is stored in a pipeline variable. To: pipeline authenticates using a service principal + certificate retrieved from Azure Key Vault, or by enabling a managed identity on the compute host and granting the identity needed RBAC roles.

    # Example: Azure CLI login using managed identity on VM (no user MFA required)
    az login --identity
    az role assignment create --assignee <managed-identity-client-id> --role "Contributor" --scope /subscriptions/...
    

If you must temporarily allow a path for migration, document the change and plan to remove temporary exceptions within a defined window.

Microsoft Entra Permissions Management (MEPM) retirement — what to do

Microsoft made the retirement of Entra Permissions Management (MEPM) effective October 1, 2025 — new sales ended earlier in 2025 and support has been phased out. Existing customers were given timelines and offboarding guidance. Administrators using MEPM must export necessary reports, data, and configuration and plan a replacement (third-party CIEM or native Entra entitlement features).

Impact areas

• Cloud Infrastructure Entitlement Management (CIEM) features previously provided by MEPM (permission insights, least-privilege recommendations, cross-cloud findings).
• Automated remediation workflows integrated with MEPM.
• Historical reports and risk dashboards stored in MEPM (export data urgently if needed for compliance).

Step-by-step offboarding checklist

1. Export all MEPM reports and configuration: permission graphs, entitlement mappings, historical audit logs, saved queries, and remediation playbooks.
2. Catalog integrations: list systems/integrations that rely on MEPM APIs, webhooks, or connectors (IAM connectors, ticketing systems).
3. Choose a replacement: evaluate CIEM vendors (SailPoint CIEM, Palo Alto Prisma Cloud CIEM, etc.) or Entra-native features for entitlement & governance depending on coverage needs. See vendor assessments and proof-of-concepts (PoCs).
4. Plan data migration or mapping: map MEPM findings to equivalent constructs (roles, policies) in your chosen replacement platform.
5. Retire MEPM integrations: gracefully disable automations and update runbooks to use the replacement tool's APIs or native Entra features.

Decision criteria for replacement

When evaluating replacements, consider:

• Coverage across cloud providers (Azure, AWS, GCP).
• Ability to perform least-privilege recommendations and automated remediation.
• Integration with existing SIEM/SOAR and ticketing solutions.
• Vendor support and roadmap alignment for identity risk detection and continuous optimization.

High-severity Entra ID token vulnerability (CVE-2025-55241) — overview & implications

Security researchers disclosed a high-severity vulnerability in Entra ID relating to legacy token flows (actor tokens and the legacy Azure AD Graph API), tracked as CVE-2025-55241. Microsoft issued patches prior to public writeups; public reporting in Sep–Oct 2025 documented how undocumented "actor tokens" and deprecated APIs could be abused for cross-tenant impersonation. The issue was patched, but the episode accelerated deprecation of legacy token flows and highlighted the need to remove deprecated authentication mechanisms from apps.

Why this matters

The vulnerability demonstrated that legacy token issuance and validation patterns (especially undocumented tokens or legacy APIs) can bypass modern control planes like Conditional Access and logging. Even if patched, the root cause was the continued presence of deprecated flows in production, increasing attack surface.

Immediate actions for app owners and security teams

1. Inventory all apps and APIs: find apps still using Azure AD Graph API, ACS/actor token patterns, or other legacy authentication methods.
2. Migrate to Microsoft Graph and OAuth 2.0 / OpenID Connect: rewrite token acquisition and validation to rely on modern, documented flows with well-understood lifetimes and scopes.
3. Check logs and alerts: monitor for anomalous token use or unexpected tenant-crossing operations; review Sentinel / SIEM for indicators of compromise during the disclosure window.
4. Apply Microsoft’s mitigations and recommendations: follow security advisories and patch guidance; confirm tenant telemetry shows no suspicious activity.

Developer checklist — migrate to modern flows

• Replace Azure AD Graph API calls with Microsoft Graph equivalents.
• Use standard OAuth 2.0 client credentials (for daemon/service apps) or device code/interactive flows with MFA for user-level access where applicable.
• Implement token introspection and short-lived tokens where possible; use refresh tokens carefully and protect them.
• Enable logging for token issuance and conditional access enforcement to detect bypass attempts.

    # Example: OAuth2 client credentials with MSAL (Python)
    from msal import ConfidentialClientApplication
    app = ConfidentialClientApplication(client_id, client_credential=client_secret, authority=authority)
    token = app.acquire_token_for_client(scopes=["https://graph.microsoft.com/.default"])
    

Microsoft Entra private network connector updates — what to check

Microsoft published a new release of the Microsoft Entra private network connector (release notes showing Oct 10, 2025). Some connectors auto-update if the connector updater service is installed; others require manual reinstallation. Admins should verify connector version history and whether auto-update applied to deployed connectors.

Actions

1. Check deployed connector versions: compare your instances to the version history and release notes.
2. Confirm updater service: ensure the connector updater service is running where you expect auto-upgrades, or schedule manual upgrades where needed.
3. Test after update: validate connectivity, application proxy behavior, and logging after applying updates on non-production connectors first.
4. Document rollbacks: keep a tested rollback plan (backup connector configuration / OVF snapshots) before manual reinstallation.

Entra “What’s new” and documentation refresh (Oct 6, 2025)

Microsoft updated the Entra “What’s new” pages and documentation on Oct 6, 2025 — the refresh aggregates many feature rollouts and guidance (over the prior 6 months). Notable mentions include managed identities used as federated credentials, improvements to entitlement management, and other admin-focused updates. Admins should review the page to identify any tenant features they may want to adopt or deprecations to avoid.

How to use the “What’s new” page

1. Filter by product (Entra ID, Private Access, Verified ID).
2. Check “breaking changes” or deprecations that require tenant action.
3. Subscribe to RSS or email notifications if your team needs automated tracking of docs changes.

Admin quick checklist — what you should do now

Actionable items to prioritize (short actionable checklist for busy admins):

• Confirm MFA exposure: identify accounts used by CLI/PowerShell/IaC and migrate those to managed/workload identities or enforce MFA where appropriate.
• Audit apps for deprecated flows: inventory apps using Azure AD Graph or actor/ACS tokens and plan migration to Microsoft Graph + modern OAuth2.
• Plan for MEPM offboarding: export required reports/configs and evaluate replacement CIEM solutions or native entitlement features.
• Update connectors: verify private network connector versions and apply updates where auto-upgrade didn't happen.
• Review “What’s new” updates: scan Oct 2025 updates to catch any additional deprecations/feature rollouts.
• Run targeted tests: test end-to-end automation pipelines and production-critical change paths in a staging tenant to validate the MFA enforcement impact.

Remediation plan & one-page runbook (ops-friendly)

The following is a concise runbook you can hand to your ops team to address the top two urgent items: MFA enforcement and MEPM retirement.

Runbook: MFA enforcement (high-level)

1. Inventory (0–3 days):
   • Query sign-in logs for CLI / PowerShell / IaC clients (look for client app names, user accounts that have performed create/update/delete operations).
   • Export the list to CSV: username, app/tool, resource scope, last successful operation.
2. Classify (1–2 days): mark each entry as: Automation, Human admin, Service account.
3. Migrate (3–14 days):
   • For Automation/Service accounts — create service principals or enable managed identities; grant minimal RBAC roles.
   • Update pipelines to use service principal auth or Managed Identity (example Azure DevOps service connection using certificate stored in Key Vault).
4. Policy (1–3 days): apply Conditional Access policy to require MFA for human admin accounts; exclude managed workload identities where appropriate.
5. Test & validate (ongoing): run smoke tests in pre-prod for all changed automation and monitor logs for auth errors.

Runbook: MEPM retirement (high-level)

1. Export (ASAP): Export datasets from MEPM — reports, mappings, policy configurations, connectors, and audit logs.
2. Map (1–2 weeks): Map MEPM capabilities to replacement product features and identify gaps (reporting, remediation or cross-cloud visibility).
3. Deploy replacement (2–8 weeks): PoC and pilot, then production rollout with cutover plan and communication to stakeholders.
4. Decommission (after cutover): disable MEPM connectors and integrations only after replacement is actively monitoring and remediation workflows are validated.

Useful commands & scripts

Examples to find CLI/PowerShell sign-ins via Azure AD sign-in logs (requires appropriate permissions):

    # Using Graph API to query signInLogs (PowerShell + Microsoft Graph)
    Install-Module Microsoft.Graph -Scope CurrentUser
    Connect-MgGraph -Scopes "AuditLog.Read.All"
    Get-MgAuditLogSignIn -Filter "clientAppUsed eq 'Azure CLI' or clientAppUsed eq 'Azure PowerShell'"