Common questions about partner security requirements

All partners in the CSP program (direct-bill, indirect provider, and indirect reseller), Advisors, and Control Panel Vendors must meet the requirements.

1. Enforce MFA for all users

   All partners in the CSP program, Advisors, and Control Panel Vendors are required to enforce MFA for all users in their partner tenant.

   Other considerations:

   • Indirect providers need to work with indirect resellers to onboard to Partner Center, if they haven't done so already, and encourage their resellers to meet the requirements.
   • Microsoft Entra multifactor authentication is available to users in the partner tenant at no cost through Microsoft Entra security defaults, with the only verification method of an authenticator application that supports time-based, one-time passwords (TOTP).
   • Other verification methods are available through the Microsoft Entra P1 or P2 SKUs, if other methods such as a phone call or text message are required.
   • Partners can also use a third-party MFA solution for each account when accessing Microsoft commercial cloud services.

2. Adopt the Secure Application Model framework

   Partners who have developed custom integration using any APIs (such as Azure Resource Manager, Microsoft Graph, Partner Center API, and so on) or implemented custom automation using tools such as PowerShell, must adopt the Secure Application Model framework to integrate with Microsoft cloud services. Failure to do so can result in a disruption due to MFA deployment.

   The following resources provide an overview and guidance about how to adopt the model.

   • Secure Application Model overview
   • Partner Center: Secure Application Model guide
   • Partners in CSP program: .NET sample code for enabling Secure Application Model
   • Partners in CSP program: Java sample code for enabling Secure Application Model
   • Partner Center authentication document
   • Partner Center PowerShell Multifactor Authentication (MFA) document

   Consult with the vendor if you're using a control panel regarding the adoption of the Secure Application Model framework.

   Control panel vendors are required to onboard to Partner Center as control panel vendors and to start implementing this requirement immediately. Refer to the Partner Center: Secure Application Model framework.

   Control panel vendors must accept and manage CSP partners' consent instead of credentials and purge all existing CSP partners' credentials.

MFA is a security mechanism to authenticate individuals using more than one required security and validation procedure. It works by requiring two or more of the following authentication methods:

• Something you know (typically a password)
• Something you have (a trusted device that isn't easily duplicated, like a phone)
• Something you are (biometrics)

Microsoft provides MFA at no cost through the implementation of Microsoft Entra security defaults. The only verification option available using this version of MFA is an authenticator application.

• If a phone call or SMS message is required, then a Microsoft Entra P1 or P2 license must be purchased.
• Alternatively, you can utilize a third-party solution to provide MFA for each user in your partner tenant. In that case, it is your responsibility to ensure your MFA solution is being enforced and that you're compliant.

Users in a partner tenant must authenticate using MFA when accessing Microsoft commercial cloud services. Third-party solutions can be used to fulfill these requirements. Microsoft no longer provides validation testing to independent identity providers for compatibility with Microsoft Entra ID. To test your product for interoperability, see Microsoft Entra identity Provider Compatibility Docs.

Yes. You must enforce MFA for each Microsoft Entra tenant associated with the CSP program or the Advisor program. To purchase a Microsoft Entra ID P1 or P2 license, you must purchase a Microsoft Entra ID license for the users in each Microsoft Entra tenant.

Yes. Each user must have MFA enforced. However, if you're using Microsoft Entra security defaults, no other action is required because that feature enforces MFA for all user accounts. Enabling security defaults is a free and easy way to ensure that your user accounts are MFA-compliant and not affected when MFA is enforced.

Direct-bill Cloud Solution Provider partners must enforce MFA for each user in their partner tenant.

Yes. All indirect resellers are required to enforce MFA for each user in their partner tenant. The indirect reseller must enable MFA.

Yes. This security requirement is for all users, including Partner admin users and end users in a partner tenant.

When you're reviewing MFA vendors and solutions, you must ensure that the solution you choose is compatible with Microsoft Entra ID.

Microsoft no longer provides validation testing to independent identity providers for compatibility with Microsoft Entra ID. If you want to test your product for interoperability, refer to Microsoft Entra identity Provider Compatibility Docs.

For more information, see the Microsoft Entra federation compatibility list.

The Microsoft Entra security defaults feature should be enabled. Alternatively, you can use a third-party solution that uses federation.

No. The fulfillment of these security requirements won't affect how you manage your customers. Your ability to perform delegated administrative operations won't be interrupted.

No. You aren't required to enforce MFA for each user in your customer's Microsoft Entra tenants. However, we recommend that you work with each customer to determine how best to protect their users.

No. Every user in your partner tenant, including service accounts, must authenticate using MFA.

Yes. That means you must implement the appropriate MFA solution for users in the integration sandbox tenant. We recommend that you implement Microsoft Entra security defaults to provide MFA.

It's considered a best practice to create one or two emergency access accounts to prevent being inadvertently locked out of your Microsoft Entra tenant. With respect to the partner security requirements, it's required that each user authenticates using MFA. This requirement means you need to modify the definition of an emergency access account. It could be an account that uses a third-party solution for MFA.

No. It isn't required to have Active Directory Federation Service (ADFS) if you're using a third-party solution. It's recommended that you work with the vendor of the solution to determine what the requirements for their solution are.

No.

Yes. You can use conditional access to enforce MFA for each user, including service accounts, in your partner tenant. However, given the highly privileged nature of being a partner, we need to ensure that each user has an MFA challenge for every single authentication. That means that you can't use the feature of conditional access that circumvents the requirement for MFA.

No. The service account used by Microsoft Entra Connect won't be affected by the partner security requirements. If you experience an issue with Microsoft Entra Connect as result of enforcing MFA, then open a technical support request with Microsoft support.

Microsoft has introduced a secure, scalable framework for authenticating Cloud Solution Provider (CSP) partners and Control Panel Vendors (CPV) that uses multifactor authentication. For more information, see the Secure Application Model guide. All partners who have developed custom integration using any APIs (such as Azure Resource Manager, Microsoft Graph, Partner Center API, and so on) or implemented custom automation using tools such PowerShell, will need to adopt the Secure Application Model framework to integrate with Microsoft cloud services.

Microsoft is introducing a secure, scalable framework for authenticating Cloud Solution Provider (CSP) partners and Control Panel Vendors (CPV) that uses multifactor authentication. For more information, see the Secure Application Model guide.

All partners who have developed custom integration using any APIs (such as Azure Resource Manager, Microsoft Graph, Partner Center API, and so on) or implemented custom automation using tools such PowerShell, must adopt the Secure Application Model framework to integrate with Microsoft cloud services. Failure to do so can result in a disruption due to MFA deployment.

The following resources provide an overview and guidance regarding how to adopt the model:

• Secure Application Model overview
• Partner Center: Secure Application Model guide
• Partners in CSP program: .NET sample code for enabling Secure Application Model
• Partners in CSP program: Java sample code for enabling Secure Application Model
• Partner Center authentication document
• Partner Center PowerShell Multifactor Authentication (MFA) document

If you're using a control panel, you need to consult with the vendor regarding the adoption of the Secure Application Model framework.

Control panel vendors are required to onboard to Partner Center as a control panel vendor and start implementing this requirement immediately.

Refer to the Partner Center: Secure Application Model framework. Control panel vendors must accept and manage CSP partners' consent instead of credentials and purge all existing CSP partners' credentials.

By enforcing multifactor authentication for all user accounts, any automation or integration that is intended to run non-interactively is affected. Although the partner security requirements require you to enable the secure application model for the Partner Center API, it can be used to address the need for a second factor of authentication with automation and integration.

You must implement the Secure Application Model if your automation runs non-interactively and relies on user credentials for authentication. See Secure Application Model | Partner Center PowerShell for guidance on how to implement this framework.

It's recommended that you use a service account that has been assigned the least privileged permissions. With respect to the Partner Center API, you should use an account that has either been assigned to the Sales agent or Admin agent role.

It's a best practice to use a least-privileged identity because doing so reduces risk. It's not recommended to use an account that has Global admin privileges because that provides more permissions than are required.

For partners using a Control Panel Vendor (CPV) solution to transact in the Cloud Solution Provider (CSP) program, it's your responsibility to consult with your CPV.

A control panel vendor is an independent software vendor that develops apps for use by CSP Partners to integrate with Partner Center APIs. A control panel vendor isn't a CSP Partner with direct access to the Partner Center or APIs. A detailed description is available within the Partner Center: Secure Applications Model guide.

To enroll as a control panel vendor (CPV), follow the guidelines in Enroll as a Control Panel Vendor to help integrate CSP partner systems with Partner Center APIs.

After you enroll in Partner Center and register your applications, you'll have access to Partner Center APIs. You'll receive your sandbox information in a Partner Center notification if you're a new CPV. After you've completed enrollment as a Microsoft CPV and accepted the CPV agreement, you can:

• Manage multitenant applications (add applications to Azure portal, and register and unregister applications in Partner Center).

  Note

  CPVs must register their applications in Partner Center to get authorized for Partner Center APIs. Adding applications to the Azure portal alone doesn't authorize CPV applications for Partner Center APIs.

• View and manage your CPV profile.

• View and manage your users who need access to CPV capabilities. A CPV can only have the role Global admin.

No. You must follow the guidelines in the Secure Application Model guide.

Yes. A refresh token can be generated using an account that doesn't have MFA enforced. However, doing so should be avoided. Any token generated using an account that doesn't have MFA enabled won't be able to access resources due to the requirement for MFA.

Follow the Secure Application Model guide that provides detail on how to do so while complying with the new security requirements. You can find .NET sample code at Partner Center DotNet Samples - Secure App Model and Java sample code at Partner Center Java Samples.

The CPV must create the Microsoft Entra application in the tenant associated with their enrollment as a CPV.

App-only authentication isn't affected because user credentials aren't used to request an access token. If user credentials are being shared, then control panel vendors (CPVs) must adopt the Secure Application Model framework and purge any existing partner credentials they have.

No. Control Panel Vendor partners can't utilize the app-only authentication style to request access tokens on the behalf of partner. They should implement the secure application model, which utilizes the app + user authentication style.

All partners participating in the Cloud Solution Provider (CSP) program, Control Panel Vendors (CPVs), and Advisors should implement the mandatory security requirements to stay compliant.

To provide more protection, Microsoft began the activation of security safeguards that helps partners secure their tenants and their customers by mandating multifactor authentication (MFA) verification to prevent unauthorized access.

We successfully completed the activation for admin-on-behalf-of (AOBO) capabilities to all partner tenants. To further help protect partners and customers, we'll begin the activation for Partner Center transactions in CSP, helping partners protect their businesses and customers from identity-theft related incidents.

For more information, see Mandating Multifactor Authentication (MFA) for your partner tenant page.

To validate that the account accessing resources was challenged for multifactor authentication, we check the authentication method reference claim to see if MFA is listed. Some third-party solutions don't issue this claim or don't include the MFA value. If the claim is missing, or if the MFA value isn't listed, there isn't a way to determine whether the authenticated account was challenged for multifactor authentication. You'll need to work with the vendor for your third-party solution to determine which actions to take so the solution issues the authentication method reference claim.

If you're unsure whether your third-party solution is issuing the expected claim or not, see Testing the Partner Security Requirements.

The technical enforcement for the partner security requirements is checked if the authenticated account has been challenged for multifactor authentication. If the account hasn't been checked, you'll be redirected to the sign-in page and prompted to authenticate again.

For more experience and guidance, see Mandating Multifactor Authentication (MFA) for your partner tenant.

In a scenario in which your domain isn't federated, after successfully authenticating, you'll be prompted to set up multifactor authentication. After that is completed, you'll be able to manage your customers using AOBO. In a scenario in which your domain is federated, you'll need to ensure the account is being challenged for multifactor authentication.

Microsoft Entra ID "baseline" policies are being removed and replaced with "security defaults," a more comprehensive set of protection policies for you and your customers. Security defaults can help protect your organization from identity-theft related security attacks.

Your multifactor authentication (MFA) implementation will be removed due to the baseline policies retirement if you haven't transitioned from baseline policies to the security defaults policy or other MFA implementation options. Any users in your partner tenants performing MFA protected operations will be requested to complete MFA verification. For more detailed guidance, see Mandating multifactor authentication for your partner tenant.

To stay compliant and minimize disruptions, use the following steps:

• Transition to security defaults
  • Security defaults policy is one of the options that partners can choose to implement MFA. It offers a basic level of security enabled at no extra cost.
  • Learn how to enable MFA for your organization with Microsoft Entra ID, and review the security defaults key considerations.
  • Enable security defaults policy if it meets your business needs.
• Transition to Conditional Access
  • If security defaults policy doesn't serve your needs, enable Conditional Access. For more information, review the Microsoft Entra Conditional Access documentation.

• View Partner security requirements: step-by-step guide.
• Direct your questions and feedback to the Partner Center Security Guidance Group.
• Attend upcoming partner office hours and webinars. Check the detailed schedule and resources on the Partner Community page.

• Secure Application Model overview
• Partner Center: Secure Application Model guide
• Partners in CSP program: .NET sample code for enabling Secure Application Model
• Partners in CSP program: Java sample code for enabling Secure Application Model
• Partner Center authentication document
• Partner Center PowerShell Multifactor Authentication (MFA) document

For support resources to meet the security requirements:

• If you have Advanced Support for Partners (ASfP), contact your Service Account Manager.
• For Premier Support for Partners agreement (PSfP), contact your Service Account Manager and Technical Account Manager.

Technical product support options for Microsoft Entra ID are available through your Microsoft AI Cloud Partner Program benefits. Partners with access to an active ASfP or PSfP subscription can work with their associated account manager (SAM/TAM) to understand the best options available to them.

If you lose access due to an MFA issue, contact the Global admin for your tenant. Your internal IT department can tell you who your Global admin is.

If you forgot your password, see Unable to sign in for help.

Information regarding the common technical issues can be found in Partner security requirements for partners using Partner Center or Partner Center APIs