Share via

Mandating multifactor authentication (MFA) for your partner tenant

  • Article

Appropriate roles: Admin agent | Sales agent | Helpdesk agent | Billing admin | Security admin

Better security, and ongoing security and privacy safeguards are among our top priorities, and we continue to help partners protect their customers and tenants.

To help partners protect their businesses and customers from identity theft and unauthorized access, we activated more security safeguards for partner tenants. These safeguards mandate and verify MFA. Mandating MFA helps partners to secure their access to customer resources against credentials compromise.

This article gives detailed examples and guidance for mandating multifactor authentication (MFA) in Partner Center.

Partners participating in the Cloud Solution Provider (CSP) program, Control Panel Vendors (CPVs), and Advisors must implement the Partner Security Requirements to stay compliant.

Partners are required to enforce MFA for all user accounts in their partner tenant, including guest users. Users must complete MFA verification for the following areas:

Partner Center

Some pages in the Partner Center are MFA-protected, including:

  • All pages under the Customers tab (that is, all pages with a URL that starts with https://partner.microsoft.com/commerce/*)
  • All pages under the Support > Customer requests tab (for example, all pages accessed with a URL that starts with https://partner.microsoft.com/dashboard/v2/support/customers/*)
  • All pages in the Billing tab

Other pages on Partner Center, such as the Overview page and Service Health Status check page, don't require MFA.

The following table shows which user types are authorized to access these MFA-protected pages (and are affected by this feature).

MFA-protected page Admin agents Sales agents Helpdesk agents Security administrator Billing administrator
All pages under the Customers tab x x x
All pages under the Support > Customer requests tab x x
Billing page x x x
Security workspace x x

To access these pages, you must first complete MFA verification.

Supported MFA options

Important

Partners are required to use an authentication provider that is compatible with Microsoft Entra ID's integrated MFA claim. The integrated claim indicates the actual credential type provided during authentication. Partners are required to use integrated MFA in order to manage customer tenants with GDAP.

Partner Center and APIs

For the following Partner Center APIs, App+User access and Microsoft Entra ID Support MFA are required:

  • Discover (price/catalog/promotion)
  • Transact and manage
  • Billing and reconciliation
  • Manage customers using delegated access/AOBO
  • User and license assignment (with DAP only)
  • User and license assignment (with GDAP)
  • Granular Admin Relationships Request and access assignment

The following options are available for partners:

Verification examples

To illustrate how verification works in the Partner Center, consider the following examples.

Example 1: Partner has implemented Microsoft Entra multifactor authentication

  1. Alejandra works for a CSP named Contoso. Contoso has implemented MFA for all their users under Contoso partner tenant using Microsoft Entra multifactor authentication.

  2. Alejandra starts a new browser session and goes to the Partner Center overview page (which isn't MFA-protected). Partner Center redirects Alejandra to Microsoft Entra ID to sign-in.

  3. Due to the existing Microsoft Entra multifactor authentication setup by Contoso, Alejandra is required to complete MFA verification. Upon successful sign-in and MFA verification, Alejandra is redirected back to the Partner Center overview page.

  4. Alejandra tries to access one of the MFA-protected pages in Partner Center. Because Alejandra completed MFA verification during sign-in earlier, Alejandra can access the MFA-protected page without being required to go through MFA verification again.

Example 2: Partner has implemented non-Microsoft MFA using identity federation

  1. Prashob works for a CSP named Wingtip. Wingtip has implemented MFA for all their users under Wingtip partner tenant using non-Microsoft MFA, which is integrated with Microsoft Entra ID via identity federation.

  2. Prashob starts a new browser session and goes to the Partner Center overview page (which isn't MFA-protected). Partner Center redirects Prashob to Microsoft Entra ID to sign in.

  3. Because Wingtip has setup identity federation, Microsoft Entra ID redirects Prashob to the federated identity provider to complete sign-in and MFA verification. Upon successful sign-in and MFA verification, Prashob is redirected back to Microsoft Entra ID and then to Partner Center overview page.

  4. Prashob tries to access one of the MFA-protected pages in Partner Center. Because Prashob has already completed MFA verification during sign-in earlier, he can access the MFA protected page without being required to go through MFA verification again.

  5. Prashob then goes to the service management page to add users in Contoso's Microsoft Entra ID. Because Prashob has used the Entra compatible authentication provider with strong authentication, they can access the customer tenant without any issues.

The recommendation for Prashob in this example is to use the Microsoft Entra multifactor authentication solution or an Entra compatible authentication provider, so they can manage the customer's tenant successfully.

Example 3: Partner hasn't implemented MFA

  1. A CSP partner called Fabrikam hasn't yet implemented MFA. Microsoft recommends that they implement a Microsoft Entra ID-supported MFA solution.

  2. John works for Fabrikam. Fabrikam hasn't implemented MFA for any users under the Fabrikam partner tenant.

  3. John starts a new browser session and goes to the Partner Center overview page (which isn't MFA-protected). Partner Center redirects John to Microsoft Entra ID to sign in.

  4. After successfully signing in, John is redirected back to the Partner Center overview page, because he hasn't completed the MFA verification.

  5. John tries to access one of the MFA-protected pages in Partner Center. Because John hasn't completed MFA verification, Partner Center redirects John to Microsoft Entra ID to complete MFA verification. Because this is the first time John is required to complete MFA, John is also requested to register for MFA. Upon successful MFA registration and MFA verification, John can access the MFA-protected page.

  6. On another day, before Fabrikam implements MFA for any user, John starts a new browser session and goes to the Partner Center overview page (which isn't MFA-protected). Partner Center redirects John to Microsoft Entra ID to sign in without MFA prompt.

  7. John tries to access one of the MFA-protected pages in Partner Center. Because John hasn't completed MFA verification, Partner Center redirects John to Microsoft Entra ID to complete MFA verification. Because John has registered MFA, this time he's only asked to complete the MFA verification.

Example 4: Partner has implemented non-Microsoft MFA that isn't compatible with Microsoft Entra

  1. Trent works for a CSP named Wingtip. Wingtip has implemented MFA for all their users under Wingtip partner tenant using non-Microsoft MFA in their cloud environment with conditional access.

  2. Trent starts a new browser session and goes to the Partner Center overview page (which isn't MFA-protected). Partner Center redirects Trent to Microsoft Entra ID to sign in.

  3. Because Wingtip used a non-Microsoft MFA integration that isn't compatible with the Microsoft Entra ID and doesn't have a strong authentication, Trent will be blocked from accessing all of the MFA protected pages and APIs within Partner Center.

Because Trent is accessing the MFA protected pages, he's required to present the MFA with Strong Auth to gain access to the MFA protected pages.

Partners are required to use an authentication provider compatible with Microsoft Entra ID that supports the credential method claim ("amr claim" in Access token claims reference - Microsoft identity platform, reflecting the actual credential type provided during authentication.

We strongly encourage CSP Partners to implement MFA that is compatible with Microsoft Entra ID immediately to raise the security baseline of your tenant.

Partner Center API

The Partner Center API supports both App-only authentication and application and user (App+User) authentication.

When App+User authentication is used, Partner Center requires MFA verification. More specifically, when a partner application sends an API request to Partner Center, it must include an access token in the authorization header of the request.

Note

The Secure Application Model framework is a scalable framework for authenticating CSP partners and CPVs through the Microsoft Azure MFA architecture when calling Partner Center APIs. You must implement this framework when using MFA in service automation.

When Partner Center receives an API request with an access token obtained using App+User authentication, the Partner Center API checks for the presence of the MFA value in the Authentication Method Reference (AMR) claim. You can use a JWT decoder to validate whether an access token contains the expected authentication method reference (AMR) value or not:

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

  • If the value is present, Partner Center concludes that MFA verification was completed and processes the API request.

  • If the value isn't present, Partner Center API rejects the request with the following response:

    HTTP/1.1 401 Unauthorized - MFA required
Transfer-Encoding: chunked
Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
WWW-Authenticate: Bearer error="invalid_token"
Date: Thu, 14 Feb 2019 21:54:58 GMT

When calling Partner Center APIs, app-only access tokens are only supported for operations that don't require GDAP role assignments in a customer tenant.

To learn more best practices, see API authentication and authorization - Overview.

Partner Delegated Administration

Partner tenants should use Granular delegated admin privileges (GDAP) to manage customer resources through Microsoft Online Services portals (portal.azure.com or admin.microsoft.com), command-line interface (CLI), and APIs (using App+User authentication). For more information, see supported MFA options.

Using service portals

CSP Partners can administer their customers from the Partner Center portal through the Service Management interface. Partners can navigate to the customer and select Service Management to be able to administer a specific service for the customer. Partners must follow the GDAP role guidance to get the right least-privilege GDAP role to manage their customers.

When accessing Microsoft Online Services portals using Partner Delegated Admin Privileges (Admin-On-Behalf-Of) to manage customer resources, many of these portals require the partner account to authenticate interactively, with the customer Microsoft Entra tenant set as the authentication context. The partner account is required to sign in to the customer tenant.

Microsoft Entra ID authentication requires a user to complete MFA verification if there's a policy requiring MFA. There are two possible user experiences, depending on whether the partner account is a managed or federated identity:

  • If the partner account is a managed identity, Microsoft Entra ID directly prompts the user to complete MFA verification. If the partner account hasn't registered for MFA with Microsoft Entra ID before, the user is asked to complete MFA registration first.

  • If the partner account is a federated identity, the experience is dependent on how the partner administrator has configured federation in Microsoft Entra ID. When setting up federation in Microsoft Entra ID, the partner administrator can indicate to Microsoft Entra ID whether the federated identity provider supports MFA or not.

    • If so, Microsoft Entra ID redirects the user to the federated identity provider to complete MFA verification.
    • If not, Microsoft Entra ID directly prompts the user to complete MFA verification. If the partner account hasn't registered for MFA with Microsoft Entra ID before, the user is asked to complete MFA registration first.

The overall experience is like the scenario in which an end-customer tenant has implemented MFA for its administrators. For example, the customer tenant has enabled Microsoft Entra security defaults, which requires all accounts with administrative rights to sign in to the customer tenant with MFA verification, including Admin agents and Helpdesk agents.

For testing purposes, partners can enable the Microsoft Entra security defaults in the customer tenant and then try using Partner Granular Delegated Administration Privileges (GDAP) to access the customer tenant.

Note

Not all Microsoft Online Service portals require partner accounts to sign in to the customer tenant when accessing customer resources using GDAP. Instead, some only require the partner accounts to sign in to the partner tenant. An example is the Exchange Admin Center. Over time, we expect these portals to require partner accounts to sign in to the customer tenant when using GDAP.

MFA registration experience

During MFA verification, if the partner account hasn't registered for MFA before, Microsoft Entra ID prompts the user to complete MFA registration first.

Review more info about the Microsoft Authenticator method:

Screenshot of the first step in MFA registration.

After the user selects Next, they're asked to choose from a list of verification methods.

Screenshot of the second step in MFA registration.

After successful registration, the user must complete MFA verification using their chosen verification method.

Common issues

To understand whether your request is valid, review the list of common issues reported by other partners.

Issue 1: Partner needs more time to implement MFA for their partner agents

A partner hasn't started or is still in the process of implementing MFA for their partner agents who require access to Microsoft Online Services Portals using Partner Delegated Administration Privileges to manage customer resources. The partner needs more time to complete MFA implementation. Is this a valid reason for technical exception?

Answer: No. A partner needs to plan to implement MFA for their users to avoid disruption.

Note

Even though a partner hasn't implemented MFA for their partner agents, the partner agents can still access Microsoft Online Services portals using Partner Delegated Administration Privileges if they can complete MFA registration and MFA verification when prompted during sign-in to customer tenant. Completing MFA registration does not automatically enable the user for MFA.

Issue 2: Partner hasn't implemented MFA because they don't need access to manage customers

A partner has some users in their partner tenants who don't require access to Microsoft Online Services Portals to manage customer resources using Partner Delegated Administration Privileges. The partner is in the process of implementing MFA for these users and needs more time to complete. Is this a valid reason for technical exception?

Answer: No. Because these user accounts aren't using Partner Delegated Administration Privileges to manage customer resources, they won't be required to sign in to the customer tenant. They won't be affected by Microsoft Entra ID requiring MFA verification during sign-in to customer tenant. All users are required to have MFA accessing Partner Center or the customer workloads to manage the customer resources.

Issue 3: Partner hasn't implemented MFA for user service accounts

A partner has some user accounts in their partner tenants, which are being used by devices as service accounts. These low-privileged accounts don't require access Partner Center nor Microsoft Online Services Portals to manage customer resources using Partner Delegated Administration Privileges. Is this a valid reason for a technical exception?

Answer: No. Because these user accounts aren't using Partner Delegated Administration Privileges to manage customer resources, they aren't required to sign in to customer tenant. They won't be affected by Microsoft Entra ID requiring MFA verification during sign-in to customer tenant. If the API or the portal required app+user authentication, then every user is required to use MFA for authentication.

Issue 4: Partner can't implement MFA using Microsoft Authenticator app

A partner has "clean desk" policy, which doesn't permit employees bringing their personal mobile devices to their work area. Without access to their personal mobile devices, the employees can't install the Microsoft Authenticator app, which is the only MFA verification supported by Microsoft Entra security defaults. Is this a valid reason for technical exception?

Answer: No. The partner should consider the following alternative so their employees can still complete MFA verification when accessing Partner Center:

  • Partner can also sign up for Microsoft Entra ID P1 or P2, or use non-Microsoft MFA solutions that are compatible with Microsoft Entra ID that can provide more verification methods. To learn more, see Authentication methods supported.

Issue 5: Partner can't implement MFA due to the use of legacy authentication protocols

A partner has some partner agents who are still using legacy authentication protocols, which aren't MFA compatible. For example, the users are still using Outlook 2010, which is based on legacy authentication protocols. Enabling MFA for these partner agents will disrupt the use of legacy authentication protocols. Is this a valid reason for technical exception?

Answer: No. Partners are encouraged to move away from the use of legacy authentication protocols because of potential security implications because these protocols can't be protected with MFA verification and are much more susceptible to credential compromise. We recommend that you deprecate any legacy authentication and use security defaults or Conditional Access. To prepare to move away from legacy authentication, review the Sign-ins using legacy authentication workbook and the guidance on how to block legacy authentication.

To understand the latest plan for supporting legacy authentication for Outlook, read the post about the Basic Auth and Exchange Online and follow the Exchange team blog to get the upcoming news.

Issue 6: Partner has implemented a non-Microsoft MFA that isn't recognized by Microsoft Entra ID

A partner has implemented MFA for their users using a non-Microsoft MFA solution. However, the partner is unable to correctly configure the non-Microsoft MFA solution to relay to Microsoft Entra ID that MFA verification has been completed during user authentication. Is this a valid reason for technical exception?

Answer: No, Partners are required to use an authentication provider compatible with Microsoft Entra ID that supports the credential method claim ("AMR"), Access token claims reference - Microsoft identity platform, reflecting the actual credential type provided during authentication.

We strongly encourage you to implement MFA that is compatible with Microsoft Entra ID immediately to raise the security baseline of your tenant.

Related content