MFA Now Mandatory for Microsoft 365: What Admins and Developers Must Do

The MFA Enforcement Timeline

Microsoft began enforcing multi-factor authentication for all Microsoft 365 and Azure portal sign-ins in October 2025. This was not a recommendation or a nudge — Microsoft applied Conditional Access policies at the platform level, meaning tenants that had not proactively configured MFA started receiving enforcement automatically.

The rollout followed a staged approach: commercial tenants went first, followed by government cloud (GCC, GCC-High, DoD) on a separate schedule announced in the Microsoft 365 Message Centre. If your tenant received message MC912047 or later, enforcement is already active for your organisation.

• Phase 1 (October 2025): Azure portal, Microsoft Entra admin centre, and Intune admin centre — all require MFA at sign-in.
• Phase 2 (November 2025): Microsoft 365 admin centre, Exchange admin centre, SharePoint admin centre, and Teams admin centre.
• Phase 3 (Early 2026): All Microsoft 365 services including end-user apps such as Outlook, Teams, and SharePoint Online access via browser.

What Actually Changed

Before October 2025, Microsoft offered two baseline options: Security Defaults (a free, opinionated set of policies that enabled MFA for all users) and Conditional Access (a premium, granular policy engine available with Entra ID P1 or P2 licences). Admins who had disabled Security Defaults and not configured Conditional Access policies were effectively running without MFA enforcement.

What changed in October 2025 is that Microsoft began applying a Microsoft-managed Conditional Access policy to all eligible tenants. This policy is read-only — you can see it in the Entra admin centre under Conditional Access, but you cannot delete it. You can, however, exclude specific users, groups, or service principals from it.

Security Defaults vs Conditional Access

If your tenant still runs on Security Defaults (visible in Entra ID > Properties > Manage security defaults), the new Microsoft-managed policy layers on top. Tenants with Entra ID P1/P2 that have already deployed their own Conditional Access policies are largely unaffected — Microsoft's managed policy defers to existing admin-configured policies.

Service Accounts and Automation

The most common support ticket since enforcement went live: "Our PowerShell automation script broke overnight." Scripts using username-and-password authentication (Basic Auth, ROPC grant) against Microsoft 365 APIs are now blocked when MFA is enforced on the account.

There are three correct approaches for non-interactive automation accounts:

1. App Registration with Client Credentials: Register an app in Entra ID, grant it application permissions (not delegated), and authenticate using a client secret or certificate. This flow has no user context and therefore no MFA prompt. This is the correct pattern for unattended scripts.
2. Managed Identity (Azure resources only): If your automation runs inside Azure (Azure Automation, Azure Functions, Logic Apps), use a system-assigned or user-assigned Managed Identity. No credentials to rotate, no MFA issues.
3. Conditional Access exclusion (last resort): Exclude a specific service account from MFA policies and restrict it to sign-in from a known IP range only. This is the weakest option — use only for legacy systems that cannot be migrated to app-only auth.

# Requires Microsoft.Graph PowerShell SDK
Connect-MgGraph -Scopes "Reports.Read.All", "AuditLog.Read.All"

# Get all users and their MFA registration status
$report = Get-MgReportAuthenticationMethodUserRegistrationDetail

$report | Where-Object {
    $_.IsMfaRegistered -eq $false -and
    $_.IsEnabled -eq $true
} | Select-Object UserPrincipalName, IsMfaCapable, IsMfaRegistered, IsPasswordlessCapable |
    Export-Csv -Path ".\mfa-gaps-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

Write-Host "MFA gap report exported."

Configuring Conditional Access Policies

Conditional Access gives you surgical control that Security Defaults cannot. A well-structured tenant runs several overlapping policies: one requiring MFA for all users accessing admin portals, one requiring compliant devices for accessing sensitive data, and one defining trusted locations where MFA may be satisfied more easily.

Trusted Locations

Named locations (defined IP ranges) can be marked as trusted. Users signing in from a trusted location may satisfy MFA with a single factor if your policy is configured that way — this is useful for on-premises office networks where a compliant, domain-joined device on a known IP is already a strong signal.

{
  "displayName": "Require MFA for Admin Portals",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeRoles": [
        "62e90394-69f5-4237-9190-012177145e10",  // Global Administrator
        "f28a1f50-f6e7-4571-818b-6a12f2af6b6c",  // SharePoint Administrator
        "9b895d92-2cd3-44c7-9d02-a6ac2d5ea5c3"   // Application Administrator
      ],
      "excludeUsers": ["<break-glass-account-object-id>"]
    },
    "applications": {
      "includeApplications": ["MicrosoftAdminPortals"]
    },
    "locations": {
      "includeLocations": ["All"]
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

Impact on App Registrations and SPFx

App registrations authenticating with application permissions (client credentials flow) are not affected by MFA enforcement — they authenticate as the application, not as a user. However, app registrations using delegated permissions with a stored username and password (ROPC — Resource Owner Password Credential flow) are directly affected and will start failing.

If any of your SPFx solutions, Power Automate flows, or Azure Functions use an Entra ID app with a stored password for delegated access, you must migrate to one of these patterns:

• Certificate-based client credentials: Upload a self-signed or CA-issued certificate to the app registration. Use Connect-PnPOnline -Url ... -ClientId ... -Tenant ... -CertificatePath ... instead of username/password.
• Managed Identity: For Azure-hosted workloads, assign a Managed Identity and grant it the required Graph or SharePoint permissions directly.
• Application permissions on the app registration: Replace delegated permissions with application permissions where the operation does not require acting as a specific user.

SPFx Developer Workstation Setup

SharePoint Framework (SPFx) developers using the local workbench or running gulp serve with a connected Microsoft 365 tenant will notice authentication prompts changing. The MSAL browser flow used by SPFx's serve mode handles MFA correctly via the browser pop-up — developers do not need to change their local toolchain for interactive development.

Where issues arise is in CI/CD pipelines and headless test runners that previously used username-and-password environment variables to authenticate to a Microsoft 365 test tenant. These must migrate to app-only authentication.

Setting Up a CI/CD App Registration for SPFx

1. Register a new app in Entra ID: "SPFx CI Pipeline".
2. Grant it Sites.FullControl.All (application permission on SharePoint) — requires Global Admin consent.
3. Upload a certificate (PEM format). Store the private key as a pipeline secret variable.
4. In your pipeline, use Connect-PnPOnline with -CertificatePath and -CertificatePassword to authenticate without any user interaction or MFA prompt.

Break-Glass Accounts

A break-glass account (also called an emergency access account) is a cloud-only, highly privileged account that is excluded from all Conditional Access policies, including MFA requirements. Its sole purpose is to restore admin access if every other admin account is locked out — for example, if your MFA provider has an outage or if a Conditional Access misconfiguration locks out all Global Admins.

Microsoft's own documentation recommends every tenant maintain at least two break-glass accounts. Key requirements:

• Cloud-only accounts — not synced from on-premises Active Directory.
• Global Administrator role assigned permanently (not via PIM).
• Long, randomly generated password stored in a physical safe, not a password manager.
• No MFA method registered — the account must be usable when MFA infrastructure is unavailable.
• Excluded from every Conditional Access policy by Object ID (not UPN, which can change).
• Sign-in activity monitored with alerts — any sign-in to these accounts is a major security event.

30-Day Action Checklist

If your tenant has received MFA enforcement notices, this is the ordered list of actions your Microsoft 365 admin team should complete within the next 30 days.

1. Run the MFA gap report (PowerShell script above) and identify all enabled users without MFA registered. Target 100% registration before Phase 2 enforcement.
2. Audit app registrations for ROPC / username-password flows. Migrate to certificate-based or Managed Identity auth.
3. Identify service accounts used by on-premises scripts, third-party SaaS tools, and Power Automate flows. Move them to app-only authentication or create a Conditional Access exclusion with IP restriction as an interim measure.
4. Create or verify break-glass accounts. Confirm they are excluded from all CA policies by Object ID and that their credentials are stored physically and securely.
5. Set up a sign-in alert in Microsoft Sentinel or Log Analytics for any sign-in from break-glass account UPNs.
6. Review Conditional Access named locations. Ensure office IP ranges are defined and marked trusted where appropriate.
7. Test MFA registration for all privileged role members (Global Admins, SharePoint Admins, Exchange Admins, Teams Admins, Intune Admins). Do this interactively — do not assume they have registered.
8. Update CI/CD pipelines for SPFx and other M365-connected build systems to use certificate-based app-only auth.