Microsoft SPLA — the rules that govern hosting Microsoft software.

What is Microsoft SPLA and who needs it?

SPLA is Microsoft's licensing programme for service providers who make Microsoft software available to third parties as a hosted or managed service. You need SPLA whenever an external party — a customer, a tenant, a subscriber — uses software running on infrastructure you operate. Unlike an Enterprise Agreement, SPLA has no perpetual licences and no Software Assurance: you report actual usage every month and pay for what you provisioned, through a Microsoft-authorised SPLA reseller. The defining rule is the third-party test. Volume licences (EA, MPSA, CSP) cover your own organisation; the instant a non-affiliated third party becomes the user, you are hosting, and SPLA — or a License Mobility path — applies.

This is the hosting deep-dive in our Microsoft server licensing guide cluster. If you are licensing servers for your own employees, start with the Windows Server licensing mechanics instead; SPLA only enters the picture when you are the provider.

How do I know if a workload needs SPLA?

Apply one question to each workload: is a third party the user of the software? If your employees administer a system that your customers log into, the customers are the users and SPLA applies. If you simply run software your own staff use to deliver a service, that may be covered by your own volume licences. The grey zone — and the most common audit exposure — is the managed-services provider who runs customer-dedicated environments on volume licences bought under the customer's name, or worse, on the MSP's own EA. The table sets out the boundary.

The third-party hosting test — which licensing vehicle applies to a given workload.

Scenario	Who is the user	Vehicle
You host an app your customers log into	Third party	SPLA
Customer brings own licences to your cloud	Third party (their licence)	License Mobility (SA) / Azure
You run software your employees use	Your org	Volume licensing (EA/CSP)
Dedicated outsourced environment for one customer	That customer	SPLA or customer's licences via Listed Provider rules

SAL or per-core — which SPLA metric applies?

SPLA products are licensed one of two ways. A Subscriber Access Licence (SAL) is counted per unique user (or device) with access during the month — the model for products like Windows Remote Desktop Services, Office, and most application servers. Per-core licensing applies to the infrastructure tier — Windows Server and SQL Server — and follows the same core-counting logic as volume licensing, including the per-processor minimum, reported monthly against the cores you ran. Some products offer both and the cheaper model depends on user density per core.

SPLA metrics by common product family (representative; confirm against the current SPUR).

Product	Typical SPLA metric	Counted on
Windows Server	Per-core	Physical cores you ran (min per proc)
SQL Server	Per-core (or SAL for some editions)	Cores allocated to SQL
Remote Desktop Services	SAL	Unique users with RDS access
Office / Microsoft 365 apps	SAL	Unique users provisioned
System Center	Per-core	Cores of managed servers

The reporting discipline matters more under SPLA than anywhere else in the Microsoft estate, because you self-report every month and the numbers compound. Two patterns drive over-reporting: counting provisioned-but-dormant SALs (users who no longer have access but were never removed), and reporting peak rather than actual concurrent core allocation. Both are recoverable with a monthly reconciliation process — the same rigour we apply on the buyer side to System Center core counts.

When can a customer bring their own licences instead?

License Mobility through Software Assurance lets a customer move eligible server application licences — SQL Server, SharePoint, Exchange and others — into a provider's shared-hardware environment, so the provider does not need SPLA for that workload. Windows Server itself is generally excluded from License Mobility on shared hardware; that is what the per-core SPLA or the dedicated-host hosting rules exist to cover. For providers, the practical effect is a split estate: customer-owned SA licences for the application tier where eligible, SPLA for Windows Server and for any customer without SA. Mapping which workloads can ride on customer SA versus which must be SPLA is the single biggest cost lever a hoster has.

What does a SPLA audit look for?

SPLA audits — run by Microsoft or its appointed auditors — concentrate on three things: under-reported usage versus deployed capacity, use of non-SPLA (volume) licences to serve third parties, and desktop-operating-system hosting, which SPLA does not grant on multi-tenant shared hardware outside the specific QMTH/multitenant hosting rights. The exposure is rarely a single month; it is the back-bill across the reporting history plus the corrected forward run-rate. In our audit-defence engagements, the recoverable position is almost always in the reporting methodology — dormant SALs, peak-versus-actual core counts, and workloads that were eligible for customer License Mobility but reported under SPLA.

For providers above meaningful monthly SPLA spend, an independent review across the third-party test, SAL hygiene and License Mobility eligibility typically pays for itself many times over. This pairs with our license optimization service and, where a notification is live, with vendor audit defence. For the broader Microsoft commercial picture, our Microsoft EA optimization work and the case behind it — an $8.7M Microsoft outcome — show the same methodology applied across the estate.