New Microsoft Solutions Partner Security Requirements: Changes and Impacts

Microsoft has significantly raised the bar for partner security compliance as part of the Microsoft Cloud Partner Program (the program for “Microsoft Certified Solutions Partner” designations). Recent updates (rolling out through 2024–2025) introduce new mandatory security controls and a scoring system to strengthen the entire partner ecosystem’s security posture. These changes build on earlier requirements – such as enforced multi-factor authentication – but go further by adding new controls, tightening existing standards, and linking compliance directly to program eligibility. This article examines the key new security requirements, compares them to previous standards, and discusses the implications and priorities for IT professionals in Microsoft partner organizations.

Overview of the New Security Requirements (2024–2025)

Microsoft’s updated partner security requirements center around a Partner Center Security Score and a set of mandatory controls that all Cloud Solution Provider (CSP) partners must implement. Beginning in late 2024 and into 2025, partners are expected to meet these security criteria to attain or maintain their authorization in the program. The core requirements now include:

• Enable Multi-Factor Authentication (MFA) for all administrative users in the partner’s tenant.

• Designate a security contact in Partner Center for security issues.

• Respond to security alerts within 24 hours (on average) of their appearance in Partner Center (with a goal of 1 hour response) – this applies to direct bill partners and distributors (indirect providers), whereas indirect resellers are exempt from the alerts requirement.

These measures are assessed via a Security Requirements Dashboard in Partner Center, which consolidates the status of all requirements into a single security score. The score ranges from 0 to 100 and reflects how many of the required controls a partner has implemented. Each requirement carries a point value (weighted by importance), and completing it contributes to the partner’s score. Partners can monitor their score and see recommendations through this dashboard, aligning their efforts with Microsoft’s best practices and even Zero Trust security principles.

 Screenshot of the Partner Center Security Requirements dashboard, showing a partner’s security score and the status of each requirement. The dashboard lists mandatory controls (MFA for admin roles, alert response, security contact, Azure spending budgets) with their completion status and point values. A “Future requirements” section previews upcoming mandates (e.g. MFA for customer tenant admins) and their point allocations. In this example, some requirements are incomplete, yielding a partial security score (33.33).

Notably, Microsoft has expanded the scope of security oversight beyond the partner’s own tenant. In addition to the three core requirements above, the security score framework currently includes: configuring Azure spending budgets for customer subscriptions (a control to detect anomalous cloud usage) and enforcing MFA for users in administrative roles in customer tenants. These latter two are given point values in the score (10 and 20 points respectively) and signal Microsoft’s expectation that partners proactively help secure customer environments as well. (The Azure budget requirement only applies to partners transacting under the newer “new commerce experience,” not legacy models.) All told, the new security score approach takes a more holistic view of security – covering identity protection, incident response readiness, and even financial governance – as part of partner compliance.

Microsoft has set a timeline for enforcement: beginning October 1, 2025, partners must meet all mandatory security requirements (e.g. enabling MFA, having a security contact, etc.) to either attain or renew their CSP authorization. Compliance will be validated annually during the partner’s CSP program anniversary month. In practice, this means partners need to treat these controls as ongoing obligations, not one-time checkboxes. Microsoft also provides a Security Requirements API (announced in 2024) to allow partners to programmatically retrieve their security compliance status – an indication of how central these checks have become in managing partner status.

Previous Security & Compliance Requirements (Prior to 2024)

Before these recent changes, Microsoft’s partner security requirements were narrower in scope, though the groundwork was already laid over the past few years. Multi-Factor Authentication for partner tenant accounts has been a cornerstone requirement since 2019. In fact, following some high-profile incidents of compromised partner accounts, Microsoft mandated MFA for all user accounts in a partner’s tenant (especially for Cloud Solution Provider partners). This was enforced via the Microsoft Partner Agreement, with the clear warning that any partner not implementing MFA would be unable to transact in the CSP program or manage customer tenants. In other words, even prior to 2024, MFA was non-negotiable – partners had to enforce it for every login to Microsoft commercial cloud services or any Partner Center APIs.

Alongside MFA, Microsoft introduced the Secure Application Model (SAM) for API integrations. This framework, rolled out a few years ago, required partners to adopt more secure authentication flows for any apps or scripted integrations with Partner Center or Azure AD (Microsoft Entra ID). The Secure Application Model moved partners away from storing admin credentials in scripts and toward using token-based auth and least-privileged access for automation, aligning with modern OAuth 2.0 practices. From 2019 onward, any partner building tooling or using the CSP/APIs had to implement this model or risk their integration being blocked. These two controls – MFA for all accounts and SAM for apps – were the primary mandatory security measures prior to the 2024 updates.

In terms of compliance enforcement, earlier requirements were a bit more binary. If a partner failed to implement MFA or SAM, Microsoft could suspend their ability to transact or even terminate the partnership agreement. However, beyond those, most other security guidelines were advisory. Microsoft has long published security best practices for partners and encouraged things like regular security training and good hygiene, but there wasn’t a formal scoring or reporting mechanism for those. For example, Microsoft’s guidance has recommended that partners follow Zero Trust principles and secure their admin privileges, but these were framed as best practices rather than monitored requirements in the past.

One notable area of change is in how partners manage customer tenant access. Historically, partners used Delegated Admin Privileges (DAP) to administer customer tenants with broad elevated rights. By 2022–2023, Microsoft recognized the risk in this model – if a partner tenant was breached, an attacker could leverage DAP to compromise many customer environments. In response, Microsoft began deprecating DAP in favor of Granular Delegated Admin Privileges (GDAP), which allow more fine-grained, time-bound access. Prior to 2024, transitioning to GDAP was strongly recommended (Microsoft even started auto-migrating inactive DAP relationships to GDAP in mid-2023) to reduce risk. This shift wasn’t always described as a “requirement,” but it was a significant security change in the partner program leading up to the new regime. In summary, before the latest updates, the security compliance focus for partners was mostly on identity security (MFA) and secure access patterns (SAM, and moving to GDAP) – crucial but relatively limited in scope compared to what’s now being rolled out.

What’s New: Key Additions and Changes in 2024 Requirements

The 2024+ Microsoft partner security standards introduce several new controls and stricter rules that go beyond the earlier baseline. Below are the most notable additions or changes, compared to previous requirements:

• Dedicated Security Contact – New: Every partner must designate a security contact (an individual or team) with up-to-date email and phone details in Partner Center. Previously, this was not required. Now it is mandatory to have a clear point of contact for Microsoft to report security incidents or suspicious activity to your organization. This ensures no critical alert falls through the cracks, whereas under old programs Microsoft had no formal contact on file specifically for security issues.

• Incident Response Timeframe – New Obligation: Under the new requirements, partners are expected to triage and respond to security alerts within 24 hours on average (and Microsoft’s guideline is to aim for a 1-hour response). This is a brand-new standard – past partner agreements did not specify any response time requirement for security issues. Now, if Microsoft raises an alert (for example, detection of suspicious admin activity or a potential breach in the partner’s tenant), the partner must address it promptly and update the alert’s status in the Partner Center portal. The security score measures the partner’s average response time over the last 30 days, rewarding a fast response with a full score and penalizing slower responses. This addition essentially pushes partners to have an incident response plan and 24/7 readiness, whereas earlier compliance focused only on preventive measures like MFA.

• Azure Subscription Spending Budgets – New Control: Microsoft now encourages partners to set spending budgets for all customer Azure subscriptions (for those using the modern commerce platform), and has made this a scored requirement worth up to 10 points. The idea is that by configuring budgets and alerts (e.g. get notified at 80% of expected monthly spend), partners can catch potential fraud or resource misuse early. This is a proactive cloud governance control aimed at preventing costly incidents (like attackers spinning up VMs for crypto-mining on a compromised account). Earlier partner security guidelines did not include any financial or usage monitoring requirements – this is a notable expansion of what “security” entails, tying in operational guardrails. Partners on the legacy commerce platform don’t get scored on this, but Microsoft clearly views it as a best practice for those who can use it. It’s a subtle addition that reflects lessons learned from real-world incidents of cloud resource abuse.

• Customer Tenant Administrator MFA – Expanded Scope: In the new model, Microsoft is looking not just at the partner’s own admins, but also at the security of customer tenants under the partner’s care. Specifically, one of the (emerging) requirements is ensuring all users with admin roles in customer tenants have MFA enabled. This effectively extends the MFA mandate into customer environments. In practice, partners will need to work with their customers’ IT admins to make sure they too have MFA on their accounts, since a breach of a customer’s global admin can be just as devastating. Previously, the partner program did not hold partners accountable for customers’ internal security settings – partners were advisors, but it wasn’t a compliance matter. Now, however, Microsoft is incentivizing partners to drive MFA adoption for customer admins (this requirement is worth up to 20 points in the security score). This change underscores Microsoft’s ecosystem approach: a partner’s security responsibility doesn’t stop at their tenant boundary, but extends to promoting security best practices for customers as well. It also aligns with the move to GDAP; with more limited roles, it becomes practical to insist on MFA for those specific high-privilege accounts in each customer tenant.

• Multi-Factor Authentication – Still Mandatory (with stricter enforcement): MFA was already mandatory before, but the new requirements double-down on it with some nuanced changes. Now the focus is on MFA for all administrative users in the partner tenant (which is effectively the same as “all users” if one follows least privilege internally). Importantly, Microsoft now makes it clear that only Microsoft Entra ID (Azure AD) based MFA counts toward the compliance score – third-party MFA solutions (like Okta, Duo, etc.) “aren’t factored into requirement score calculations.”. In the past, partners could use third-party identity providers or MFA solutions and still meet the intent of the requirement, sometimes via special exception. In fact, Microsoft had an exception process for non-Microsoft MFA up until early 2022 for certain cases. Going forward, however, Microsoft wants partners to either use the built-in Azure AD MFA (which is free via security defaults) or at least understand that if they use an external IdP, they’ll need to obtain a formal exception and will score zero on the automated check. This is effectively a tightening of the standard – no more easy workarounds. Every admin account must register for MFA and actually use it, or the partner will fail the requirement. Microsoft’s rationale is that MFA is one of the most effective defenses against account compromise, so they’ve made its enforcement ironclad.

• Granular Delegated Admin (GDAP) – Phasing Out Old Practices: While not listed as a scored item in the Partner Center security score, the shift from DAP to GDAP is a critical security change that coincided with these updates. By August 2023, Microsoft began ending traditional DAP relationships in favor of GDAP, ensuring partners operate with least privilege access in customer tenants. Prior to this change, a partner could have perpetual global admin rights in a customer tenant (via DAP), but now partners must request specific roles (via GDAP) that expire after a set duration. This tightening of access control was driven by the same security concerns now reflected in the new requirements. In essence, Microsoft is closing loopholes that previously existed: broad standing admin access has been curtailed, and all privileged actions are under greater scrutiny. Partners who haven’t already fully adopted GDAP should treat it as a strategic priority – not only to align with Microsoft’s security expectations, but also to protect their customers and themselves from the fallout of a potential breach.

In summary, the new requirements add several layers of security beyond what partners faced in the past: formal incident response processes, mandatory assignment of responsibility (security contacts), customer-level safeguards, and stricter enforcement of identity security. Microsoft is effectively moving from a stance of “implement these two or three controls or else” to a more comprehensive security framework for partners that touches operations, identity, and even customer advocacy. The addition of a measured security score also means compliance is no longer a simple yes/no – it’s a spectrum, and Microsoft can gauge how well a partner is securing their environment. This scoring approach encourages continuous improvement; for example, a partner might have MFA enabled (20 points) but still respond too slowly to alerts (0 of 10 points), highlighting an area to improve. This is a big change from the older binary checklist approach.

Implications for IT Professionals and Microsoft Partner Organizations

For partners and their IT teams, these new security requirements have both practical and strategic implications. Practically, meeting the requirements will likely necessitate new workflows, tools, and mindsets within partner organizations. Here are some key implications:

• Compliance is Tied to Partner Status: The most immediate implication is that non-compliance can jeopardize a partner’s business with Microsoft. Much like failing to meet revenue targets or competency requirements could affect a partner’s standing, now failing to meet security requirements can result in losing CSP authorization or other partner benefits. For example, an indirect reseller must satisfy the security score requirements (in addition to a revenue threshold) to renew their authorization annually. This raises the stakes for IT teams – security is no longer just protecting the business and customers, it’s also about retaining your ability to do business as a Microsoft partner. The partner’s leadership will be keenly interested in the organization’s security score because it has direct commercial consequences.

• Need for Operational Security Maturity: The introduction of alert response SLAs and a security contact means partners must have operational security processes similar to an enterprise IT department or managed service provider. IT professionals in partner organizations should ensure there is a clear incident response plan and an on-call process to handle security alerts from Microsoft promptly. Microsoft even recommends maintaining an incident response playbook and defining roles/responsibilities for security incidents. Smaller partners who previously treated security more informally may need to assign specific staff (or outsource to a security provider) to monitor and react to incidents. In essence, every partner now needs some SOC (Security Operations Center) capability, even if light, to meet the 24-hour response requirement. This might involve setting up automated alert forwarding (e.g. from the Partner Center security contact email to a ticketing system or SMS) and ensuring coverage after hours. The cultural shift here is significant: security isn’t “someone else’s problem” – Microsoft is explicitly making it part of the partner’s day-to-day responsibilities.

• Proactive Customer Management: The new requirements also push partners to be more proactive with their customers’ security. For instance, to get the points for customer admin MFA, a partner’s IT consultants or account managers will need to work with each customer tenant to enable MFA for those users. This can actually strengthen the partner’s role as a trusted advisor – it opens conversations about broader security improvements (e.g. implementing Microsoft Entra ID Security Defaults or Conditional Access in customer tenants) and shows the partner is serious about protecting the customer. However, it also means partners must allocate time and resources for these proactive efforts, which weren’t explicitly required before. Partners might start including MFA deployment as part of every new customer onboarding, and regularly reviewing customers’ MFA status via the provided Partner Center tools. Similarly, setting Azure spending budgets for customers will require coordination with customers about their expected Azure usage and configuring those budgets in the portal. All of this translates to more work for partner-side IT teams, but it’s work that adds value and reduces risk for both the partner and the customer.

• Technical Alignment with Microsoft’s Ecosystem: IT professionals at partner companies will also need to ensure their technical choices align with Microsoft’s requirements. For example, if a partner was using a third-party identity provider or MFA system, they may need to integrate it in a way that satisfies Microsoft’s checks or consider a shift to Azure AD’s native MFA for administrative accounts. The fact that Microsoft’s security score doesn’t recognize third-party MFA puts pressure on partners to use the Microsoft stack (at least for the accounts that matter, like global admins). Additionally, any partner-developed software or tools must use the Secure Application Model (i.e. no storing plaintext passwords or using basic auth) – which most have already adopted, but stragglers will find those old methods simply won’t work as Microsoft enforces modern auth tokens and deprecated protocols. In short, partners’ IT architectures must be up-to-date with Microsoft’s latest security technologies (Entra ID, Conditional Access, verified publishers for apps, etc.) to remain compliant.

• Enhanced Trust and Marketing Value: On the positive side, partners who fully embrace these security requirements can leverage their compliance as a competitive advantage. In an era of frequent supply-chain attacks, Microsoft and customers will naturally have more trust in partners with demonstrably strong security postures. Microsoft is in fact incentivizing this: partners that “demonstrate robust security practices” are more likely to access new benefits and opportunities in the Microsoft AI Cloud Partner Program. This could include eligibility for certain incentives, or simply being viewed favorably for referrals and co-selling if Microsoft knows a partner takes security seriously. Additionally, Microsoft has a designation called “Solutions Partner for Security” – partners who specialize in security and meet certain performance and skill criteria can earn this badge. While distinct from the baseline security requirements, it underscores the point that security is now a differentiator. IT leaders in partner organizations should not just see compliance as a duty, but also as a chance to stand out. For instance, a partner could mention in marketing that they have a 100% Partner Center security score or highlight their adherence to Microsoft’s highest security standards – giving customers peace of mind. Moreover, by adopting these practices internally, partners gain firsthand expertise that they can turn into service offerings for clients (e.g. helping a client implement similar MFA or Zero Trust initiatives).

• Continuous Improvement Mindset: Finally, the move to a scoring model implies that security compliance is continuous, not one-and-done. IT pros will need to regularly check the Partner Center Security Requirements dashboard, monitor their score, and watch for any “future requirements” Microsoft plans to enforce. Microsoft has already signaled that new requirements will be added over time (for example, the customer admin MFA started as a “future” requirement preview and then became active). This means partners must stay agile and keep up with Microsoft Learn announcements and partner center communications. From a practical standpoint, it would be wise for partners to integrate these checks into their governance routines – for instance, including security score review in monthly IT ops meetings, or using the API to trigger alerts if the score drops. The annual revalidation cycle also means there may be audits or attestations needed each year. In essence, security compliance is now an ongoing program within the partner’s organization. Those partners who invest in maintaining and improving their security posture will not only avoid unpleasant surprises at renewal time, but also reduce their risk of security incidents overall.

Strategic Considerations to Stay Compliant and Competitive

To navigate this new landscape, Microsoft partners should blend technical measures with strategic planning. Here are some key considerations and best practices moving forward:

• Embrace a Zero Trust Architecture: Microsoft’s guidance repeatedly emphasizes Zero Trust principles (verify explicitly, least privilege access, assume breach). Partners should use the impetus of these requirements to move toward Zero Trust in their own IT. Concretely, this means enforcing MFA everywhere (not just where Microsoft demands it), using conditional access policies to limit risky logins, segmenting internal networks, and reviewing admin access regularly. When Microsoft audits partners’ security or if a breach occurs, those who have adopted Zero Trust will be far better positioned to respond. Zero Trust isn’t a checkbox – it’s a strategy – but the new requirements (MFA, GDAP, etc.) are stepping stones in that direction. Treat them as the minimum, not the maximum.

• Automate and Monitor Compliance: Given that Microsoft now provides a Security Requirements dashboard and API, partners should leverage these to avoid any lapses. IT teams can integrate the security score checks into their existing monitoring systems. For example, you could set up an automation to pull the security score via API daily or weekly and alert if it falls below 100 or if any requirement status changes. Similarly, ensure the security contact information is always up to date and going to the right people or ticketing system. This might involve using a group email that forwards to the on-call engineer. Automation can also help with the alert response process: consider using Azure Monitor or custom scripts to watch for new Partner Center alerts (there’s an API and also email notifications) so that responding within 24 hours is practically achievable even during off-hours. By operationalizing these compliance checks, partners can stay ahead of Microsoft’s enforcement and avoid last-minute scrambles when the annual review comes.

• Invest in Staff Training and Incident Response Drills: Technical controls alone won’t suffice if the team behind them isn’t prepared. Partners should train their technical staff on the specifics of these requirements and the tools available. For instance, ensure administrators know how to use the Customer MFA Status page in Partner Center to check each client’s MFA deployment, or how to set Azure budgets for customers. Conduct periodic drills – e.g., simulate a security alert and practice the end-to-end response: receiving the notification, investigating the issue, updating the alert status with a reason code, and remediating the problem. Microsoft actually encourages partners to specify reason codes in alert handling to provide feedback on alert quality. Doing these exercises will not only prepare the team for real incidents but also ensure you meet the 24-hour response window comfortably. Additionally, staying current with Microsoft’s security technologies (like new Azure AD features, Microsoft 365 Defender, etc.) will help the team implement the best solutions to meet or exceed requirements.

• Collaborate with Customers on Security: Since some compliance elements touch customer settings (MFA for admins, Azure budgets), partners should proactively include these in customer engagements. It’s wise to communicate to customers that as a Microsoft Solutions Partner, you are required to uphold strict security measures – and that this is ultimately for their benefit. Many customers will appreciate that their partner is encouraging stronger security (for example, small businesses who might not have enabled MFA until their IT provider insisted). Offer assistance to implement these changes. Perhaps create a simple report for each customer on their MFA adoption rates (the Partner Center tools provide stats) and present this in quarterly business reviews, along with recommendations. By turning a compliance chore into a value-added service, partners strengthen client relationships. It also ensures that the partner’s compliance doesn’t become a tug-of-war with a resistant customer; instead, it becomes a joint effort toward better security. In cases where a customer might resist (e.g. an admin not wanting MFA), the partner should document their advisory role – since ultimately Microsoft is looking at the partner to lead by example.

• Plan for Future Security Requirements: Microsoft has indicated that more requirements may be coming down the pike. Partners should keep an eye on Microsoft Partner Center announcements and Microsoft Learn documentation updates. It’s reasonable to anticipate that Microsoft could eventually mandate things like endpoint protection standards, compliance with certain frameworks (e.g., an ISO or NIST-based self-attestation), or additional cloud security measures as part of the partner program. For instance, one could imagine a future requirement around enabling Microsoft Defender for Cloud Apps or having a certain Microsoft Secure Score (in M365) threshold. While speculative, the point is that partners should maintain a forward-looking security roadmap. Don’t treat the current requirements as a static checklist; instead, build capabilities that can adapt to new mandates. One practical step is to regularly review Microsoft’s security guidance for partners (the “security best practices” and any new Secure Score recommendations). Many of the recent requirements were foreshadowed by best-practice advice in prior years (for example, incident response and security contacts were suggested long before they became required). By heeding Microsoft’s security advice early, partners can often anticipate where compliance will eventually head and be early adopters rather than last-minute fixers.

• Leverage Microsoft Security Offerings: To meet these requirements efficiently, partners should use the tooling Microsoft provides. Turn on Microsoft Entra ID Security Defaults or Conditional Access policies to enforce MFA for all needed accounts – this is a quick win if not already done. Use Azure AD reporting to track MFA registration status for admins. Use Microsoft Lighthouse (if you’re a service provider managing multiple customer tenants) for a unified view of alerts and MFA status across customers. Microsoft is essentially nudging partners to also adopt its security products (Defender, Sentinel, etc.) to have a more integrated defense. While not explicitly required, doing so can make it easier to meet the requirements. For example, a partner using Microsoft Sentinel could aggregate and automate alert handling from the Partner Center API and other sources. Also consider getting your organization’s Microsoft Secure Score (for your internal tenant in M365/Azure) in a healthy range – it’s not the same as the Partner Center security score, but it correlates with good practices. A high Secure Score internally will usually imply you’ve satisfied things like MFA, admin role separation, logging, etc., which align well with the partner requirements. Essentially, treat your own organization like a model enterprise customer of Microsoft: implement the security features you often deploy for customers on yourselves.

In conclusion, Microsoft’s new Solutions Partner security requirements represent a significant evolution in the partner program – from a light touch approach to a rigorous, standards-based approach. The changes bring tangible improvements in protecting the partner ecosystem: by mandating MFA, rapid incident response, and secure configurations, Microsoft is reducing the risk that one compromised partner could lead to a supply-chain attack affecting many customers. For partners, adapting to these changes might require effort and investment, but it ultimately raises their security maturity. The payoff is a more resilient business and greater trust from both Microsoft and clients.

From a business perspective, partners that excel in security compliance will likely find themselves more competitive and in line for new opportunities, whereas those who drag their feet may face penalties or loss of business. As one analysis noted, “a vulnerability in a partner’s infrastructure could potentially expose numerous customers to risks. Therefore, Microsoft is proactively establishing security standards to mitigate these threats and ensure a secure environment for all stakeholders.” In this new era, security is a shared responsibility and a core component of being a Microsoft Solutions Partner. IT professionals in partner organizations should take these requirements to heart – not just to pass Microsoft’s checks, but to genuinely improve their security posture. By blending technical excellence with strong policies and continuous vigilance, partners can not only remain compliant but turn security into a competitive strength, delivering safer solutions for themselves and their customers in the cloud.

Sources:

1. Microsoft Partner Center – “Security requirements for Partner Center” (Microsoft Learn, updated 2025)

2. Microsoft Partner Center – “Security requirements to use Partner Center or Partner Center APIs” (Microsoft Learn, updated 2024)

3. CIAOPS Blog – “Security Requirements for Microsoft Partners and Their Customers” (May 2025)

4. Microsoft Partner Center Announcement – “Revenue requirement for CSP indirect resellers” (May 2025)

5. Microsoft Documentation – Delegated Admin to Granular Delegated Admin (GDAP) transition notes and Microsoft Tech Community

6. Microsoft Learn – Partner Center security implementation details (MFA, alerts, and security contact requirements)