Jaa

Security requirements to use Partner Center or Partner Center APIs

  • Artikkeli

Appropriate roles: All Partner Center users

As an advisor, control panel vendor, or Cloud Solution Provider (CSP) partner, you have decisions to make regarding authentication options and other security considerations.

Privacy safeguards and security for you and your customers are among our top priorities. We know that the best defense is prevention and that we're only as strong as our weakest link. We need everyone in our ecosystem to ensure appropriate security protections are in place.

Mandatory security requirements

The CSP program helps customers buy Microsoft products and services through partners. In accordance with their agreement with Microsoft, partners are required to manage the environment for and provide support to the customers they sell to.

Customers who buy through this channel, place their trust in you as a partner because you have high-privilege admin access to the customer tenant.

Partners who don't implement the mandatory security requirements aren't able to transact in the CSP program. They also can't manage customer tenants who use delegated admin rights. In addition, partners who don't implement the security requirements might put their participation in programs at risk.

The terms associated with the partner security requirements are added to the Microsoft Partner Agreement. The Microsoft Partner Agreement (MPA) is updated periodically, and Microsoft recommends that all partners check back regularly. As it relates to Advisors, the same contractual requirements are in place.

All partners are required to adhere to security best practices so they can secure partner and customer environments. These best practices help you mitigate security issues, remediate security escalations, and ensure your customers' trust isn't compromised.

To protect you and your customers, you're required to take the following actions immediately:

Enable MFA for all user accounts in your partner tenant

You must enforce multifactor authentication (MFA) on all user accounts in your partner tenants. MFA challenges users when they:

  • Sign in to Microsoft commercial cloud services.
  • Transact in the Cloud Solution Provider program through Partner Center.
  • Transact by way of APIs.

MFA enforcement follows these guidelines:

  • Partners who use Microsoft-supported Microsoft Entra multifactor authentication. For more information, see Multiple ways to enable Microsoft Entra multifactor authentication.
  • Partner who implemented any non-Microsoft MFA and are part of the exception list. They can still access Partner Center and APIs with exceptions but can't manage customers by using DAP/GDAP. No exceptions.
  • Partner's organization that was previously granted an exception for MFA. If a partner organization was granted an exception for MFA, the exceptions are only honored if the users who manage customer tenants as part of the Cloud Solution Provider program enabled them before March 1, 2022. Not complying with MFA requirements can result in the loss of customer tenant access.

For more information, see Mandate multifactor authentication for your partner tenant.

Adopt the Secure Application Model framework

All partners who integrate with Partner Center APIs must adopt the Secure Application Model framework for any app and user auth model applications.

Important

We strongly recommend that partners implement the Secure Application Model to integrate with a Microsoft API, such as Azure Resource Manager or Microsoft Graph. Also, partners should implement the Secure Application Model when they leverage automation, such as PowerShell by using customer credentials, to avoid any disruption when they enforce MFA.

These security requirements help protect your infrastructure and safeguard your customers' data from potential security risks, such as identify theft or other fraud incidents.

Other security requirements

Customers trust you, as their partner, to provide value-added services. It's imperative that you take all security measures to protect the customer's trust and your reputation as a partner.

Microsoft continues to add enforcement measures so that partners are required to adhere to and prioritize the security of their customers. These security requirements help protect your infrastructure and safeguard your customers' data from potential security risks, such as identify theft or other fraud incidents.

Partners must ensure that they adopt the principles of Zero Trust, as described in the following sections.

Delegated Admin Privileges

Delegated admin privileges (DAP) provide the capability to manage a customer's service or subscription on their behalf. The customer must grant the partner administrative permissions for that service. Since the privileges provided to the partner to manage the customer are highly elevated, Microsoft recommends that partners remove inactive DAPs. Partners who manage the customer tenant by using Delegated Admin Privileges should remove inactive DAP from the Partner Center to prevent any impact on the customer tenant and their assets.

For more information, see the Monitor administrative relationships and self-service DAP removal guide, the Delegated administration privileges FAQ, and the NOBELIUM targeting delegated administrative privileges guide.

Also, DAP is being deprecated soon. We strongly encourage all partners who actively use DAP to manage their customer tenants move toward a least privilege Granular Delegated Admin Privileges model to securely manage their customers' tenants.

Transition to least privilege roles to manage your customer tenants

Because DAP is being deprecated soon, Microsoft highly recommends that you move from the current DAP model, which gives Admin agents standing or perpetual Global admin access. Replace it with a fine-grained delegated access model. The fine-grained delegated access model reduces security risks to customers and the effects of those risks. It also gives you control and flexibility to restrict access per customer at the workload level of your employees who manage your customers' services and environments.

For more information, see the Granular delegated admin privileges (GDAP) overview, information on least-privileged roles, and the GDAP FAQ

Watch for Azure fraud notifications

As a partner in the CSP program, you're responsible for your customer's Azure consumption, so it's important that you're aware of any potential cryptocurrency mining activities in your customers' Azure subscriptions. This awareness helps you take immediate action to determine whether the behavior is legitimate or fraudulent. If necessary, you can then suspend the affected Azure resources or Azure subscription to mitigate the issue.

For more information, see Azure fraud detection and notification.

Sign up for Microsoft Entra ID P2

All Admin Agents in the CSP tenant should strengthen their cybersecurity by implementing Microsoft Entra ID P2, and take advantage of the various capabilities to strengthen your CSP tenant. Microsoft Entra ID P2 provides extended access to sign-in logs and premium features such as Microsoft Entra Privileged Identity Management (PIM) and risk-based Conditional Access capabilities to strengthen security controls.

Adhere to CSP security best practices

It's important to follow all CSP best practices for security. Learn more at Cloud Solution Provider security best practices.

Implementing multifactor authentication

To comply with the partner security requirements, you must implement and enforce MFA for each user account in your partner tenant. You can do this one of the way following ways:

Security defaults

One of the options that partners can use to implement MFA requirements is to enable security defaults in Microsoft Entra ID. Security defaults offer a basic level of security at no extra cost. Review how to enable MFA for your organization with Microsoft Entra ID. Here are some key considerations before you enable security defaults.

  • Partners who already adopted baseline policies must take action to transition to security defaults.
  • Security defaults are the general availability replacement of the preview baseline policies. After a partner enables the security defaults, they can't enable baseline policies.
  • Security defaults policies are enabled at once.
  • Partners who use conditional access, can't use security defaults.
  • Legacy authentication protocols are blocked.
  • The Microsoft Entra Connect synchronization account is excluded from security defaults and isn't prompted to register for or perform multifactor authentication. Organizations shouldn't use this account for other purposes.

For more information, see Overview of Microsoft Entra multifactor authentication for your organization and What are security defaults?.

Note

Microsoft Entra security defaults is the evolution of the baseline protection policies simplified. If you've already enabled the baseline protection policies, then it is highly recommended that you enable security defaults.

Implementation frequently asked questions (FAQ)

Because these requirements apply to all user accounts in your partner tenant, you need to consider several things to ensure a smooth deployment. For example, identify user accounts in Microsoft Entra ID that can't perform MFA, and applications and devices in your organization that don't support modern authentication.

Before performing any action, we recommend that you complete the following validations.

Do you have an application or device that doesn't support the use of modern authentication?

When you enforce MFA, legacy authentications that use IMAP, POP3, SMTP, protocols are blocked. It's because those protocols don't support MFA. To correct this limitation, use the app passwords feature to ensure that the application, or device still authenticates. Review Considerations for using app passwords to determine if you can use them in your environment.

Do you have Office 365 users with licenses associated with your partner tenant?

Before you implement any solution, we recommend that you determine which versions of Microsoft Office the users in your partner tenant are using. There's a chance your users can experience connectivity issues with applications like Outlook. Before you enforce MFA, it's important to ensure that you use Outlook 2013 SP1, or later, and that your organization has modern authentication enabled. For more information, see Enable modern authentication in Exchange Online.

To enable modern authentication for devices that run Windows and have Microsoft Office 2013 installed, you must create two registry keys. See Enable Modern Authentication for Office 2013 on Windows devices.

Is there a policy preventing any of your users from using their mobile devices while working?

It's important to identify any corporate policy that prevents employees from using mobile devices while working because it influences what MFA solution you implement. There are solutions, such as the one provided through the implementation of Microsoft Entra security defaults, that only allow the use of an authenticator app for verification. If your organization has a policy preventing the use of mobile devices, then consider one of the following options:

  • Deploy a time-based one-time base password (TOTP) application that can run on secure system.

What automation or integration do you have to authenticate user credentials?

MFA enforcement for users, including service accounts, in your partner directory, can affect any automation or integration that employs user credentials for authentication. So, it's important to identify which accounts are being used in these situations. See the following list of sample applications or services to consider:

  • Use a control panel to prepare resources on behalf of your customers.
  • Integrate with any platform that invoices (as it relates to the CSP program) and supports your customers.
  • Use PowerShell scripts that use the Az cmdlets, AzureRM, Microsoft Graph PowerShell, and other modules.

This list isn't comprehensive, so it's important to perform a complete assessment of any application or service in your environment that uses user credentials for authentication. To contend with the requirement for MFA, use the guidance in the Secure Application Model framework where possible.

Access your environment

To better understand what or who authenticates without MFA challenge, we recommend that you review sign-in activity. Through Microsoft Entra ID P1 or P2, you can use the sign-in report. For more information, see Sign-in activity reports in the Microsoft Entra admin center. If you don't have Microsoft Entra ID P1 or P2, or if you need a way to get sign-in activity through PowerShell, use the Get-PartnerUserSignActivity cmdlet from the Partner Center PowerShell module.

How the requirements are enforced

If a partner organization was granted an exception for MFA, the exceptions are only honored if the users who manage customer tenants as part of the Cloud Solution Provider program enabled them before March 1, 2022. Not complying with MFA requirements can result in the loss of customer tenant access.

Microsoft Entra ID and Partner Center enforce partner security requirements by checking for the presence of the MFA claim to identify that MFA verification takes place. As of November 18, 2019, Microsoft activated more security safeguards, previously known as "technical enforcement" to partner tenants.

At the time of activation, users in the partner tenant are requested to complete MFA verification when they perform any admin on behalf of (AOBO) operations. Users also need to complete MFA verification when they access the Partner Center or call Partner Center APIs. For more information, see Mandate multifactor authentication for your partner tenant.

Partners who don't meet the requirements should implement these measures as soon as possible to avoid any business disruptions. If you use Microsoft Entra multifactor authentication or Microsoft Entra security defaults, you don't need to take any other actions.

If you use a non-Microsoft MFA solution, there's a chance that the MFA claim might not be issued. When the claim is missing, Microsoft Entra ID can't determine if MFA challenges the authentication request. For information on how to verify that your solution issues the expected claim, see Test partner security requirements.

Important

If your non-Microsoft solution doesn't issue the expected claim, work with the vendor who developed the solution to determine what actions to take.

Resources and samples

See the following resources for support and sample code:

Related content