Back to Blog
How to Prepare for Enhanced Security

Understanding Microsoft's MFA Requirements

Microsoft MFA: The Critical Role of Multifactor Authentication in Security (2026)

Published: October 25, 2024
Last updated: March 24, 2026

Microsoft's decision to enforce Multifactor Authentication (MFA) for all users. Since October 15, 2024, anyone signing into the Azure portal, Microsoft Entra admin center, and Intune admin center will need to have MFA enabled. 

Microsoft has been enforcing Multifactor Authentication (MFA) across Partner Center since mid-2025. The portal is already locked down. The API deadline — April 1, 2026 — is next. If you just need the deadline, who's affected, and what to do right now, see our MFA API enforcement announcement.

This guide covers the full picture: what's enforced, what's coming, and exactly what your technical team needs to do. No padding. Just the facts and the steps.

What Microsoft Is Enforcing

Microsoft now requires MFA across two surfaces in Partner Center:

Partner Center portal (enforced since September 2025). Every page in the Partner Center dashboard requires MFA-verified sign-in. This has been active since the rollout began on September 8, 2025, and applies to all users — no exceptions.

Partner Center APIs (enforced April 1, 2026). All App+User API calls must include a valid MFA token in the access token. After April 1, calls without it receive a 401 response code with a 900421 error code. This is already being enforced in sandbox environments.

App-only authentication — where no user context is involved — is not affected. If your automated processes use App-only tokens, they'll continue to work. But any flow that involves a user signing in (App+User) is in scope.

For the official specification, see Microsoft's MFA mandate for partner tenants.

 

The Enforcement Timeline

Here's how Microsoft phased this in:

August 30, 2025 — Original target date for portal MFA enforcement across all Partner Center pages.

September 8, 2025 — Actual rollout start for portal MFA enforcement.

September 30, 2025 — All Partner Center APIs became MFA-enabled and available for partner testing.

October 2025 — APIs began checking for MFA tokens in requests and confirming their presence in responses, allowing partners to validate compliance.

March 2026 — Sandbox tenant enforcement activated. Non-compliant requests return 401/900421 errors in sandbox environments. We covered the current enforcement status and action steps in our API enforcement deadline breakdown.

April 1, 2026 — Full production enforcement. All App+User API calls without a valid MFA token are blocked.

For the latest enforcement status and immediate action steps, see our MFA API enforcement deadline breakdown.

Source: Partner Center Announcements — March 2026

 

Who Is Affected

Every partner type in the Cloud Solution Provider (CSP) program that uses App+User API authentication:

Direct bill partners — Any direct API integrations for provisioning, billing, or subscription management.

Indirect providers (distributors) — API calls made on behalf of resellers, including order placement and reconciliation.

Indirect resellers — If using tools or platforms that make App+User API calls to Partner Center.

Control Panel Vendors (CPVs) — Must use the Secure Application Model with App+User authentication. CPVs cannot use App-only authentication on behalf of partners.

If you use a third-party platform (like CloudCockpit) to manage your CSP operations, check with your vendor to confirm their API integration is MFA-compliant. Platforms that have already adopted the Secure Application Model framework should require no action from you on the API side.

 

How MFA Verification Works for APIs

When Partner Center receives an API request using App+User authentication, it checks the access token for the AMR (Authentication Method Reference) claim. The AMR claim must include the mfa value, confirming that the user completed MFA during authentication.

This means three things need to be true:

  1. The user account used to generate the token has MFA enabled.
  2. The user actually completed MFA verification during the sign-in that produced the token.
  3. The identity provider correctly passes the MFA claim through to Microsoft Entra ID.

If any of these conditions aren't met, the API returns a 401 response with error code 900421.

For the technical specification, see Partner Center Authentication.

 

The Secure Application Model

Microsoft requires CSP partners and CPVs to use the Secure Application Model framework for App+User authentication. This framework replaces the legacy approach of passing user credentials directly in API calls.

Here's how it works:

One-time consent process. A partner admin (with MFA enabled) signs into a consent application, completes MFA verification, and authorizes the application. This generates a refresh token.

Secure token storage. The refresh token is stored securely — Microsoft recommends Azure Key Vault. This token is encrypted and never exposed in application code.

Token-based API calls. When your application needs to call Partner Center APIs, it uses the stored refresh token to request a new access token. Because the original consent included MFA, the resulting tokens carry the MFA claim.

Token refresh cycle. Refresh tokens have a finite lifetime. Your application must handle token renewal before expiry to maintain uninterrupted API access.

Microsoft provides sample implementations in both .NET and Java on GitHub.

 

Identity Provider Requirements

Your MFA solution must be compatible with Microsoft Entra ID. Specifically, it must support the AMR claim — the credential method reference that tells Partner Center which authentication factors were used.

Microsoft Entra MFA — Works natively. No additional configuration needed. You can enable it via security defaults (free) or Conditional Access (requires Entra ID P1 or P2).

Federated third-party MFA — Supported, but your federation must be configured to pass strong authentication claims to Entra ID. If your federated identity provider doesn't send the correct AMR claim, users will be blocked from Partner Center — even if they completed MFA on the third-party side.

Non-compatible MFA — If your MFA provider doesn't integrate with Entra ID at all, it won't work for Partner Center. Microsoft's documentation is clear: partners must use a provider that supports the Entra ID AMR claim.

If you're unsure about your identity provider's compatibility, see Microsoft's guide on configuring authentication methods for AD FS.

 

How to Test Your Compliance

You don't have to wait for April 1 to find out if your API calls will work. Microsoft has made testing available since September 2025.

Add the ValidateMfa header. Include ValidateMfa: true in your API request headers. Partner Center will check for the MFA claim and return an isMfaCompliant field in the response.

GET https://api.partnercenter.microsoft.com/v1/customers/{customer-tenant-id}/users HTTP/1.1
Authorization: Bearer {access-token}
ValidateMfa: true
Accept: application/json

If isMfaCompliant returns true, your token flow is correct. If it returns false, your access token doesn't carry a valid MFA claim — and your calls will be blocked on April 1.

Test in sandbox first. Microsoft is already enforcing MFA in sandbox tenants — requests without a valid MFA claim return a 401 response with error code 900421. We covered the current enforcement status and what to do before April 1 in a separate post.

For more detail, see Validating API calls are integrated with MFA.

 

CSP Authorization: The Broader Security Requirements

MFA enforcement for APIs is part of a larger security framework that Microsoft activated on October 1, 2025. To maintain CSP authorization, all partners must meet three mandatory requirements:

1. Enable MFA for all administrative users in your CSP tenant. Not optional. Not just for some admins. Every administrative user account must have MFA enforced.

2. Designate a security contact in Partner Center. This person or group is accountable for security-related incidents. Populate the name, email, and phone number in Partner Center's Security workspace.

3. Respond to security alerts within 24 hours. When Microsoft flags a security issue on your tenant, your designated contact must act within 24 hours. (This requirement does not apply to indirect resellers.)

These requirements are validated annually during your CSP onboarding anniversary month, starting January 2026. If you don't meet them, your CSP authorization is at risk.

For the full breakdown, see Security requirements for Partner Center.

 

Compliance Checklist

Use this to confirm you're ready before April 1, 2026:

  • MFA is enabled for all user accounts in your partner tenant (via security defaults or Conditional Access).
  • Your identity provider is compatible with Microsoft Entra ID and supports the AMR claim.
  • You've implemented the Secure Application Model framework for all App+User API calls.
  • Refresh tokens are stored securely (Azure Key Vault or equivalent).
  • You've tested API calls with the ValidateMfa: true header and confirmed isMfaCompliant returns true.
  • Sandbox API calls are succeeding without 401/900421 errors.
  • A security contact is designated in Partner Center.
  • Your team can respond to security alerts within 24 hours.
  • Legacy authentication methods (IMAP, POP3, SMTP) are identified and migrated, since they don't support MFA.
  • If using a third-party CSP platform, you've confirmed with your vendor that their integration is MFA-compliant.

 

 

Key Microsoft Documentation Links