SPLA Licensing Complete Guide: How It Works

SPLA Licensing: Complete Guide to How It Works

Executive Summary:

Microsoft’s Services Provider License Agreement (SPLA) is a specialized licensing program that allows service providers to rent Microsoft software on a pay-as-you-go basis for hosting services.

It’s a three-year agreement with monthly usage reporting – meaning providers only pay for what they use (based on peak monthly usage.

This guide explains how SPLA licensing works, its benefits and pitfalls, recent changes, and what enterprise IT and finance leaders need to know to manage SPLA effectively.

What is SPLA and Who Needs It?

SPLA Defined:

The Service Provider License Agreement is Microsoft’s program for service providers and ISVs to legally offer Microsoft software as part of their services to third-party customers.

Unlike standard enterprise licenses, SPLA allows providers to license Microsoft products every month during a 3-year agreement term to host software services and applications for clients. In other words, it’s a rental model – no upfront purchase, just pay-as-you-go usage fees.

Who Uses SPLA:

Typical SPLA participants include hosting companies, cloud service providers, SaaS vendors, outsourcers, and managed service providers.

If an organization offers any kind of hosted IT service (e.g., hosting websites, enterprise applications, or desktop-as-a-service) using Microsoft software, SPLA is usually required.

Microsoft explicitly prohibits the use of standard volume licenses (such as those under an Enterprise Agreement) for third-party hosting, except in very limited “self-hosted” scenarios.

Therefore, providers must sign up for SPLA to stay compliant when delivering Microsoft-based services to customers.

Why Enterprises Should Care:

Even if you’re a CIO/CTO/CFO at an end-user company, understanding SPLA is important. Many enterprises rely on external service providers for hosting and software services.

Those providers’ costs – and compliance risks – are driven by SPLA licensing.

Understanding how SPLA works helps you negotiate more favorable contracts with vendors and ensure that your use of Microsoft software via outsourcing is properly licensed.

How SPLA Licensing Works

Pay-As-You-Go Model:

Under SPLA, there is no fixed entitlement of licenses that a provider buys upfront.

Instead, a service provider can deploy as many instances or enable as many user accounts as needed during a month, and then report the highest usage (“high watermark”) at the end of the month.

Microsoft bills the provider via an authorized SPLA reseller for that month’s usage.

This usage-based approach means costs scale with actual deployment – if you double the number of virtual machines or users one month, that month’s bill will reflect the increase, but you can also scale down the next month.

Monthly Reporting:

The SPLA partner must report all licenses consumed by all customers every month. This includes counts such as the number of users (for user-based licenses) or the number of processor cores used (for core-based licenses) at peak usage.

Reports are submitted to the SPLA reseller or Microsoft, and the provider is invoiced on a monthly basis. There are no long-term commitments beyond the 3-year agreement itself – you pay only for what was used each month.

There are also no Microsoft-imposed pricing rules for end customers; Microsoft charges the provider according to its price list, but the provider can charge their clients as they see fit (margin, bundling, etc.).

SPLA Resellers and Pricing:

Microsoft doesn’t sell SPLA licenses directly to providers; instead, providers work with authorized SPLA resellers (also called LSPs).

The reseller provides the monthly price list of all available Microsoft products under SPLA. The SPLA price list is confidential and not publicly available.

Although it’s mostly standardized, providers can occasionally negotiate a slight discount on their SPLA pricing through the reseller. In general, however, discounts are modest – SPLA is typically a “pay the sticker price” program for most. Providers then add their markup when billing customers.

For example, if the SPLA cost for a SQL Server is $100 per month, a managed service provider might charge the customer a higher amount that includes that licensing cost plus services and profit.

Licensing Models (Per Core vs. Per User):

Microsoft’s SPLA encompasses a broad range of products with varying licensing metrics. There are eight distinct licensing models in SPLA, but they boil down mainly to two categories:

• Per Processor/Core Licenses: The provider is charged based on the number of processor cores (or CPUs) running the software, regardless of user count. Key server products, such as Windows Server, SQL Server, System Center, and others, fall into this category. The primary benefit is unlimited user access – you pay for the server’s capacity, and any number of users can utilize it without requiring separate client licenses. This model is ideal for multi-tenant services or public-facing applications (e.g., hosting a web application on Windows Server accessible by many users).
• Per User (Subscriber Access License, SAL): Here, the cost is based on the number of unique users authorized to use the service. Each user needs a SAL for a given product. Many Microsoft applications offered via SPLA use per-user licensing – e.g. Remote Desktop Services CALs, Microsoft Office/Visio/Project (when offered as a hosted desktop app), Exchange or SharePoint hosted instances, etc.. The advantage is that you can run any number of server instances for that service, but you must count every user. Important: SPLA charges for authorized users, not just active users. If a user account exists and has access to the software, it must typically be reported, even if the user didn’t log in this month. This is a common pitfall – for example, if an Active Directory group, such as “All Employees,” is given access to a hosted application, the provider owes a SAL for every single employee in that group. Managing and limiting user access is critical to keep SPLA costs under control.

Example:

A SaaS provider might host a web application that uses an SQL Server database and also provides a web front-end for customers’ employees.

They would license SQL Server under SPLA per-core (ensuring the database server has sufficient core licenses for its vCPUs) and license the web application access via, say, Windows Server (per-core) and perhaps RDS or another component per-user.

Each month, they report the maximum number of cores used for SQL Server and Windows Server, as well as the number of user SALs for RDS or other components, corresponding to the peak number of user accounts enabled.

Benefits of SPLA for Providers and Customers

For Service Providers (Flexibility and Scale):

• No Upfront Costs: SPLA is a pure rental model – no large capital expense for licenses. This lowers the barrier to entry for new services and allows providers to offer the latest versions of software without buying new licenses each time (SPLA rights are always for the most current versions)
• Pay-as-You-Go Scalability: Licensing costs scale with business. If a provider’s customer base grows, the SPLA costs grow correspondingly; if it shrinks or usage dips, the costs decrease. This closely aligns operational cost with revenue, protecting cash flow and reducing the risk of over-provisioning.
• Monthly Adjustments: Providers can adjust their offerings every month. There’s no strict cap on usage – you can spin up new VMs or add users mid-month to meet a customer need, then report them. SPLA’s flexibility enables a quick response to market or client changes without requiring renegotiation of licenses.
• Breadth of Products: Virtually the entire Microsoft software portfolio is available – including Windows Server, SQL, SharePoint, Dynamics, and Office components – under a single agreement. This means a provider can craft tailored solutions with a wide range of Microsoft tech, all covered by SPLA.

For Enterprise Customers (Value and Simplicity):

• Access to Software as a Service: Enterprises can utilize Microsoft software through a provider without needing to purchase licenses or infrastructure. The provider’s SPLA covers the licensing, so the customer simply pays a subscription fee or service charge. This simplifies life for ITAM and finance teams – no need to track those licenses internally or carry them as assets.
• Cost-Efficiency: Customers only pay for what they use, indirectly. For example, if you have 100 users on a hosted CRM one month and 80 the next, your service bill can scale accordingly since the provider’s SPLA costs drop. You avoid the significant upfront CAPEX of buying licenses for peak capacity.
• Latest Technology: Providers using SPLA can offer the latest Microsoft software versions. Enterprises benefit from up-to-date functionality and security without having to manage upgrades. It’s essentially outsourcing the licensing headache.
• Customized Solutions: With SPLA’s flexibility, providers can craft bespoke solutions (a mix of products and services) tailored to the customer’s needs. The customer isn’t constrained by standard cloud service bundles – almost any Microsoft product can be provided as a managed service if the provider is willing.

Example: A global enterprise might use a third-party provider for a legacy application that needs an underlying Windows Server and SQL Server.

Instead of buying those licenses or moving to a public cloud, the enterprise can have the provider host it under SPLA. The provider charges a monthly fee that covers infrastructure, support, and the Microsoft licensing.

The enterprise enjoys a single bill and contract, and can scale the user count up or down as needed.

Cost Structure and Key Considerations

Pricing Mechanics:

Every SPLA-licensed product has a monthly price (per user, per core, etc.), but those prices are available only through your SPLA reseller.

Microsoft’s SPLA price list is not publicly published, and although volume discounts are not typical for SPLA, large providers may negotiate slightly better rates through their reseller. Generally, expect SPLA unit prices to be consistent globally, with local currency adjustments.

Providers typically apply a markup to these costs in their customer offerings. Enterprise buyers should be aware that a portion of any cloud or hosting service fee from a provider is attributable to the underlying SPLA licensing.

Cost Drivers:

The main drivers of SPLA cost are the quantity of licenses consumed each month and the specific products in use. High-end server products (like SQL Server Enterprise or Dynamics ERP components) carry hefty monthly fees, while simpler services (like basic Windows Server or standard CALs) are cheaper.

User-based vs. core-based licensing can also drive cost strategy: for example, Windows Server under SPLA is licensed per-core, which may be more costly for a multi-core environment with few users, whereas an RDS SAL is licensed per-user, which can be costly in a scenario with hundreds of occasional users. It’s crucial to pick the right model for each service to optimize costs.

High-Watermark Billing:

SPLA charges are based on the peak usage in each calendar month. This means if you temporarily scale up resources (even for a day), your report will reflect that peak. Actionable tip: right-size and clean up unused resources before month-end.

For example, if some VMs are spun up for a short project and are no longer needed, decommission them promptly; otherwise, they may count toward your peak for that month.

Common Pitfalls and Hidden Costs:

Compliance, Audits and Risks

SPLA Obligations:

Signing an SPLA comes with strict obligations. Providers must include Microsoft’s End User License Terms in their customer contracts (so customers acknowledge Microsoft’s software terms).

They must also keep detailed records of what each client is using. If a customer’s usage exceeds approximately $1,000/month in licenses, the customer’s details must be reported to Microsoft as part of the monthly usage report.

Additionally, if providers use subcontractors or data center partners, they must be disclosed upon request. In practice, compliance means having robust internal systems to track deployments, user counts, and ensuring accurate reporting each month.

Audit Frequency:

Microsoft regularly audits SPLA partners for compliance.

Audits are typically handled by third-party firms (the “Big Four” accounting firms often lead these). An audit can review the past several years of usage data to identify any under-reported licenses. Many service providers can expect an audit at least once every 2-3 years (sometimes more frequently for larger hosts).

Audit Process and Penalties:

A formal audit starts with a notice letter, after which the provider usually has 30 days to respond and prepare. Auditors will gather data (such as server inventory and user lists) to calculate what the provider should have reported versus what was reported.

If under-licensing is found to be beyond a small threshold (5% variance), Microsoft will demand back-payment for all unreported licenses at current pricing, plus a 25% penalty.

In many cases, the provider must also pay the auditor’s fees.

These back-bills can reach millions of dollars for large providers, so the risk is significant. The provider may negotiate the final settlement or payment terms, but it’s a painful hit regardless.

For enterprises using a service provider, an SPLA audit could indirectly impact you as well. E.g., the provider might pass on costs or impose stricter usage limits if it is found to be non-compliant.

Staying Compliant:

Preventative measures are key. Providers require robust asset management and monitoring tools to track every instance and user in near real-time.

It’s wise to do regular self-audits and true-ups internally.

Any mistake in a monthly report often has a short window for correction – after that, it’s locked in and would be counted as under-reporting in an audit.

Key best practices include maintaining a license usage register, documenting all changes (new deployments, decommissions, client onboarding/offboarding), and retaining proof when clients bring their licenses (e.g., License Verification Forms for BYOL scenarios).

In short, SPLA compliance requires discipline. Many providers engage licensing experts or utilize specialized software asset management (SAM) tools to continuously reconcile their environment with the information being reported.

Pitfall:

One subtle requirement is that SPLA license use is allowed only for providing services, not for reselling standalone licenses.

Providers cannot act as a reseller of Microsoft licenses under SPLA – they must be adding value via a software service (hosting, managed solution, etc.).

All customer use of the software must be under the provider’s management and part of a service offering (which is usually naturally the case, but it prevents schemes like simply renting out licenses without any service).

SPLA vs. Other Licensing Options

Many enterprise leaders ask how SPLA differs from Microsoft’s other licensing programs, like the Enterprise Agreement (EA) or Cloud Solution Provider (CSP) program.

The table below highlights key differences:

In summary:

SPLA is unique to service/hosting scenarios – it’s the only way a third party can legally provide Microsoft software to you as a service (aside from Microsoft’s cloud).

Enterprises typically deal with EAs or CSP for their direct licensing needs, but whenever you outsource or use a provider, SPLA might be working in the background.

Notably, with trends toward cloud subscriptions, Microsoft is also evolving its programs to blur the lines (e.g., the recently introduced CSP-Hoster program allows certain providers to host VMs for customers who bring their licenses or subscriptions).

But SPLA remains critical for traditional hosting of Microsoft software.

Recent Changes and Future Outlook

Microsoft has been updating its licensing programs to adapt to the evolving economics of the cloud and regulatory pressures.

Two key changes affecting SPLA in recent years are:

• October 2022 Changes – More BYOL Flexibility: In late 2022, Microsoft introduced the “Flexible Virtualization” benefit, along with other changes aimed at addressing concerns about cloud competition. Essentially, they made it easier for customers to bring their licenses to third-party clouds and ended the restrictive Qualified Multi-Tenant Hoster (QMTH) program. Now, service providers (except a few major clouds) can host Windows 10/11 and Office 365 Apps for customers that have their appropriate licenses, without special prior authorization. The flip side is that Microsoft now requires customers to have their license in some cases – for example, a provider cannot use their SPLA to cover Windows 11 for a customer on shared cloud infrastructure; the customer must have a Windows client subscription or the service must be via Windows 365. These changes provided customers with more deployment flexibility but also eliminated some scenarios where the provider’s SPLA would have been sufficient. Providers had to adjust offerings to ensure clients bring the necessary licenses when required by the new rules.
• Upcoming 2025 Restrictions – No SPLA on Hyperscalers: A major shake-up is set to take effect on September 30, 2025. Microsoft is disallowing SPLA partners from using their own SPLA licenses on the big “Listed Providers” infrastructure – namely Azure, AWS, Google Cloud, and Alibaba. After that date, if a service provider runs customer workloads on those hyperscale clouds, they can’t simply apply SPLA licenses to cover Windows/SQL/etc. Instead, they’ll have to acquire licenses through the cloud’s marketplace (license-included VMs or SaaS) or have the customer bring licenses. Essentially, Microsoft is closing a loophole where MSPs could buy cheaper SPLA licenses and run them on Azure/AWS VMs – going forward, those clouds want you to use their own (more expensive) licensing options. This change will likely increase costs and complexity for service providers who have built solutions on third-party clouds, and it reduces flexibility in choosing the most cost-effective platform. Providers may respond by moving customer workloads to private or smaller cloud datacenters where SPLA can still be used freely, or by transitioning to new programs. For enterprise clients, this could mean price increases or changes in your MSP’s hosting strategy if they currently leverage AWS/Azure with SPLA. It’s a developing area, and CIOs should proactively discuss with their vendors how they plan to handle these 2025 licensing rule changes.

Future of SPLA:

Microsoft’s long-term strategy appears to be nudging providers toward cloud-first programs (such as CSP for SaaS and Azure usage) and ensuring that Microsoft captures revenue regardless of whether the software is hosted on Azure or elsewhere.

Still, SPLA remains the only viable model for many scenarios (especially hosting on-premises or private cloud infrastructure). We can expect SPLA to continue, but with tighter rules in place to prevent misuse and possibly increased scrutiny.

Providers and customers alike should stay informed on Microsoft’s announcements (licensing blogs, partner newsletters) to avoid surprises.

In an era of rapid cloud adoption, SPLA is evolving – understanding those changes is crucial for negotiating contracts and avoiding compliance traps.

Recommendations (Expert Tips)

For CIOs, CTOs, CFOs, and IT asset managers dealing with SPLA (either directly as providers or indirectly through vendors), here are practical tips:

• 1. Insist on Transparency from Providers: If you’re sourcing services, ask your service provider for a breakdown of Microsoft licensing costs (or at least which components drive the cost). Understanding how SPLA factors into your bill can reveal opportunities for optimization.
• 2. Optimize User Counts Monthly: Ensure processes are in place to remove or disable unused user accounts before each month’s end. This prevents paying for SALs that aren’t truly needed – a simple but effective cost saver.
• 3. Monitor Usage and Right-Size Regularly: Treat your SPLA usage like a cloud bill – use monitoring tools to identify idle VMs or over-provisioned resources. Proactively shut down or consolidate to maintain a lean license footprint.
• 4. Leverage BYOL When Sensible: For customers with existing Microsoft 365 or volume licenses, evaluate if those can be applied (via License Mobility or Azure Hybrid Benefit, etc.) to the provider’s environment. While SPLA is often the only choice, in some cases BYOL can reduce costs – just ensure it’s compliant and documented.
• 5. Engage with Your SPLA Reseller: If you’re a provider, maintain a good relationship with your SPLA reseller. They can alert you to program changes, provide compliance guidance, and occasionally assist with negotiations (e.g., securing academic pricing or other incentives).
• 6. Stay Educated on Licensing Changes: Microsoft licensing rules change frequently. Assign someone (an internal licensing specialist or an external consultant) to track announcements related to SPLA and cloud licensing. Being aware ahead of time (like the 2025 change) allows you to plan migrations or budget for cost changes.
• 7. Conduct Periodic Self-Audits: Don’t wait for Microsoft’s official audit. Conduct your internal audit at least annually (or quarterly) to verify that your reported usage aligns with actual deployments. This helps catch any slips early – far easier to correct proactively than to pay penalties later.
• 8. Have an Audit Response Plan: In case Microsoft does come knocking for an audit, be prepared. Identify who will gather data and who will interface with auditors, and consider seeking expert help. A well-managed audit can save money by reducing errors in findings and negotiating more favorable outcomes.
• 9. Evaluate Alternatives for Cloud Hosting: If you’re a provider using AWS/Azure with SPLA, start exploring alternatives. Can you move some clients to Azure’s CSP program or a private cloud? Planning now will cushion the impact of the 2025 rule change on your business and your customers.
• 10. Align Contracts with Licensing Reality: If you’re an enterprise, ensure your contracts with service providers have clauses for licensing changes – for instance, how cost changes due to Microsoft’s licensing updates will be handled. This avoids nasty surprises and encourages both parties to collaborate on optimizing license use.

Checklist: 5 Actions to Take

For a quick-start plan, here’s a checklist of five key actions to manage SPLA licensing effectively in your organization:

1. Identify SPLA Usage: Create a list of all services and vendors that provide you with Microsoft software as a service. Confirm that those vendors are using SPLA (most will be). If your company provides services itself, identify which offerings rely on SPLA.
2. Review and Optimize Access Controls: Implement a monthly review of user access for any hosted applications (especially if you run your own SPLA or if you have influence over user provisioning with your provider). Remove unused accounts and reduce broad group permissions to minimize unnecessary SAL counts.
3. Implement Monitoring Tools: Ensure you have tooling (or require your provider to have tooling) that tracks license-relevant metrics, such as peak VM counts, user counts, and feature usage. Set up alerts or regular reports to catch anomalies (like a sudden spike in usage that will drive costs up).
4. Consult with Licensing Experts: If you lack in-house expertise, engage a Microsoft licensing specialist or your SPLA reseller to do a license posture review. They can identify misconfigurations (such as mislicensed scenarios or missed opportunities for more cost-effective licensing) and help you adjust before it becomes a compliance issue.
5. Plan for 2025 Changes: If your environment involves hosting on Azure/AWS/GCP via a third party, initiate conversations now about the September 2025 SPLA changes. Evaluate options such as converting to a license-included model, migrating to a different infrastructure, or using Azure’s upcoming programs. Create a transition plan well in advance of the deadline to avoid service disruptions or sudden cost increases.

By following this checklist, organizations can proactively manage their SPLA-related costs and risks, rather than reacting to problems after they occur.

FAQs

Q: Our company is not a service provider. Why should we care about SPLA?
A: Even if you don’t offer services, you likely consume services from vendors who use SPLA to license Microsoft software on your behalf (datacenter outsourcing, SaaS solutions, etc.). Understanding SPLA helps you ensure your vendors’ costs are reasonable and that they remain compliant (so you don’t face an interruption if a vendor gets audited). It also informs your negotiations – for instance, knowing that a provider’s cost for a Windows Server license is usage-based can help you structure a deal that benefits you from efficiencies.

Q: How is SPLA different from Microsoft’s cloud subscriptions (like Office 365 or Azure)?
A: SPLA is fundamentally for infrastructure or software hosted by a third-party provider. Office 365, Azure, and other cloud subscriptions are Microsoft’s services or licenses sold to end-customers (often via CSP or EA). You can’t buy Azure through SPLA – Azure is a separate pay-as-you-go service. Similarly, Office 365 (Microsoft 365) licenses are typically obtained through CSP or volume licensing, rather than SPLA. However, a service provider might use SPLA to provide a similar offering (e.g., hosting Exchange on their servers as opposed to Office 365 Exchange Online). Think of SPLA as the way a provider rents Microsoft software to offer you a custom or hosted solution outside of Microsoft’s own cloud.

Q: Can we use our existing Microsoft licenses with a service provider instead of using their SPLA?
A: In some cases, yes – this is commonly called Bring Your Own License (BYOL). Microsoft allows customers with certain Volume Licensing agreements and Software Assurance to “bring” those licenses to a qualified provider’s environment (License Mobility and newer outsourcing terms govern this). For example, you might bring your SQL Server license to run on a third-party cloud rather than paying the provider’s SPLA fee. But BYOL has strict rules and is limited to certain products. Also, as of 2025, for big cloud providers (Azure/AWS/GCP), Microsoft is emphasizing BYOL or license-included only – providers can’t cover those with their own SPLA. Always discuss BYOL options with your provider and ensure Microsoft’s requirements (e.g. filling out License Verification forms, having active Software Assurance, or using Authorized Outsourcers) are met.

Q: What happens if a service provider fails an audit? Could our company be affected?
A: If a provider is found non-compliant in an SPLA audit, they will likely owe Microsoft a substantial sum in back-licenses and penalties. While Microsoft’s action is against the provider (not the end customer), there are indirect impacts. The provider might need to raise prices or cut costs (possibly reducing service levels) to recoup the loss. In worst-case scenarios, a small provider could go out of business due to an audit hit – leaving their customers scrambling. Additionally, as a customer, you may be asked to retroactively purchase licenses or sign documents if there is a shortfall (although generally, the SPLA holder is accountable, not the customer). The best safeguard is to ensure you partner with reputable, well-governed providers. It’s reasonable to ask your critical service providers about their license management practices and whether they have been audited or have compliance programs in place.

Q: Is SPLA being phased out in favor of other programs?
A: Microsoft is certainly shifting focus toward its cloud and the CSP program, but SPLA still fills a vital niche. The recent rule changes (like the 2025 hyperscaler restriction) indicate Microsoft wants to close loopholes and push more usage onto its own platforms or newer licensing models. Over time, we may see SPLA evolve or merge with other partner programs. For now, however, SPLA remains the go-to program for hosting providers. Enterprises should watch this space – if Microsoft introduces a new “hosting subscription” model or incentives for Azure-based services, some traditional SPLA scenarios might move there. In summary, SPLA isn’t dead, but it is changing. Service providers and customers should stay agile and be prepared to adapt licensing approaches as Microsoft’s strategy unfolds.

Do you want to know more about our Microsoft Optimization Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit