Mandating multifactor authentication (MFA) for your partner tenant

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
• Partner Center API
• Partner Delegated Administration

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).

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

Supported MFA options

• Partners who use Microsoft supported Microsoft Entra multifactor authentication. For more information, see Multiple ways to enable Microsoft Entra multifactor authentication (MFA supported)
• Partners who implemented integrated MFA federated authentication. These partner users are allowed to access Partner Center and manage the customers using GDAP. See the integrated MFA providers with MFA offerings available with AD FS: Configure Methods for AD FS.

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:

• Use Microsoft built-in authentication methods to satisfy MFA requirements.
• If you're using a federated identity provider, ensure that the federation is configured to accept the federated MFA.
• If you want to use ADFS to configure the external second factor, see the third party providers with MFA offerings available with AD FS: Configure Authentication Methods for AD FS
• Implement MFA: Immediately enable MFA via security defaults or Conditional Access by following the security defaults guidance.

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.

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": "[email protected]",
  "upn": "[email protected]",
  "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.

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:

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

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.

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

• Partner security requirements status