A CSP partner may not sell to itself or an affiliate: Microsoft names two own-use routes instead

A partner in Microsoft's Cloud Solution Provider program may not use CSP to sell Microsoft or third-party offers to itself, or to an affiliate organisation, as the end customer. Microsoft states this as a contract term. For the partner's own use, the same Microsoft page names two routes: an Azure Partner Shared Services tenant for Azure, or a separate Microsoft Entra tenant that buys from another CSP partner.

Last verified: 2026-09-15.

The source is Learn how CSP partners can work together, in the section headed "Supported partner transactions in the CSP program". Sample scenario 5 there covers a partner in the CSP program that wants to sell to itself as an end customer, and the answer reads, in full: "By contract, partners in the CSP program aren't allowed to sell Microsoft or third-party offers to themselves (as end-customers) or to their affiliate organizations (as end-customers)."

Sample scenario 4 on the same page covers the next question, a CSP partner that wants to buy Microsoft or third-party offers for its own use. Option A reads: "If a partner wants to purchase Azure subscriptions for their own use, they can create a shared services tenant." Option B reads: "A CSP partner can set up another Microsoft Entra tenant that is a separate customer environment, and then establish a CSP relationship with an indirect reseller or direct bill partner." The CSP authorization overview adds the condition that makes Option B work: "To sell CSP services to CSP partner, the purchasing partner must use a tenant that isn't associated with their CSP."

Why it is easy to get wrong

The prohibition lives in contract wording, and none of the pages cited in this note describes a Partner Center control that stops a partner adding its own tenant, or an affiliate's tenant, as a customer. The mechanics are open. Microsoft's reseller relationship guide says that adding a new CSP customer forms "a reselling relationship" automatically, and that an existing tenant, including "a customer who purchased from Microsoft directly", can be invited into one. A partner who reasons from what the portal allows can conclude that its own tenant is just another customer.

The affiliate half is the one that gets missed. A partner that keeps its own tenant out of its CSP customer list can still fall inside the same sentence by billing a sister company or a holding entity, because "their affiliate organizations" sit in the clause beside the partner itself. The page does not define "affiliate". That definition sits in the contract, which this note did not read.

The overview note quoted above also opens with a sentence that is easy to skip: "Partners can't sell online services to other CSP partners using their CSP partner tenant." Read with the sentence after it, the tenant that receives the licences under Option B has to be a separate customer tenant, never the buyer's CSP partner tenant, whichever partner does the selling.

What it costs to get this wrong

The first cost is a breach of a stated contract term. What Microsoft does when it finds one is not described on any page cited here, and this note does not guess at it (see Limitations). The documented cost is the unwinding. Microsoft's channel move guidance says partners "can cancel newly created subscriptions within the first seven days of creation, like any other newly acquired subscription", and that "Many subscriptions require the customer to keep their subscription for the full term and enforce cancelation policies." A self-supplied subscription found after its first week is bound by the same cancellation policy as any other, so the partner carries the commitment to its end date while buying the replacement through a permitted route.

Recommendation

Choose the route before the first licence is needed, and keep the list of affiliate tenants next to the CSP customer list so the two can be compared. The table sets the two routes Microsoft names for own use beside two that sit outside the CSP program altogether.

Trade-offs

Azure Partner Shared Services covers Azure and nothing else. The Shared Services page also says its subscriptions are "aligned with Azure legacy", that they "cannot be migrated to new commerce Azure plan", and that "APSS no longer supports Marketplace offers". For the full Marketplace catalogue the same page points partners to web direct Azure subscriptions instead. In its favour, consumption appears on the partner's own CSP invoice and reconciliation file, so it stays inside billing tooling a CSP practice already reads.

The separate-tenant route reproduces an ordinary customer relationship because it is one: another partner sells into a tenant that is not the buyer's CSP partner tenant. The price is a second Microsoft Entra tenant to administer, and the regional condition set out in the warning below.

A web direct subscription is bought from Microsoft through the Microsoft 365 admin portal. The channel move guidance says credits on subscriptions bought that way "are handled by Microsoft 365 billing support", so billing questions go to Microsoft rather than to a CSP partner.

A benefit grant is the narrowest route. The benefit table on the Partner Launch Benefits page lists a fixed quantity per product, including 5 of Microsoft 365 Business Premium (no Teams), 5 of Microsoft Defender Suite and 1 of Power Automate Premium, at "$350 USD or equivalent in local currency" a year, and a partner "can buy only one Partner Launch Benefits per Partner Global account". For the keyless redemption flow, the cloud services benefits page says benefits are bound to the partner's purchase Microsoft Customer Agreement billing account, "meaning they can only be redeemed on the partner's own tenant(s) associated with that account", and are "non-transferable outside the partner's organization". Microsoft describes that flow as rolled out in phases by geography, and for the older key-based flow the same table says benefits "were not linked to any specific billing account or tenant". Use rights for each product are set by the Terms of Participation guide the Partner Launch Benefits page links to, which this note did not read, so the licence mix is Microsoft's list and its use is governed by Microsoft's terms.

Where it does not apply

The clause covers one arrangement: a partner, or its affiliate, as the end customer of a CSP sale. It has no bearing on a CSP partner selling to an unrelated customer. It does not touch sample scenarios 2 and 3 on the same page, where one customer buys from, or is managed by, several partners, because customer and partner stay distinct entities there.

It also stops applying where no CSP sale exists. The channel move guidance treats "EA, Web Direct, or another CSP" as distinct starting channels, and the clause is about "partners in the CSP program" selling offers. This note reads web direct, Enterprise Agreement and benefit redemptions as outside it. None of the cited pages says so in terms. The Shared Services page supports the reading for Azure, describing partners using Azure subscriptions "in the Microsoft Enterprise Agreement and Web Direct programs".

flowchart TD
  accTitle: The two own-use routes Microsoft names for a CSP partner
  accDescr: A CSP partner that needs licences for its own tenant cannot buy them as a CSP sale from itself, which is barred by contract. If the need is Azure only, the named route is an Azure Partner Shared Services tenant. Otherwise the named route is a new, separate tenant supplied by another CSP partner.
  A[Licences for own tenant] -.->|own CSP sale| C[Barred by contract]
  A --> B{Azure only?}
  B -->|yes| E[Shared Services tenant]
  B -->|no| F[New tenant, other CSP]

How to check which tenants a CSP relationship bills

From the partner side, the list that matters is the CSP customer list, because that is where a reselling relationship appears. The reseller relationship guide says that once a customer accepts, "the customer appears in your Customer List with a reselling relationship." The Partner Center REST API returns the same list. The Get a list of customers reference documents a GET whose response carries, for each customer, a companyProfile holding the tenantId, domain and companyName, plus a relationshipToPartner value. Compare every tenantId against the partner's own tenant IDs and against the tenant IDs of every organisation the contract could count as an affiliate.

From the customer side, one tenant at a time, the Microsoft 365 admin center has a partner relationships page under Settings which, per Microsoft's admin guidance, lists "the partner's name and relationship to your organization". Signed in to an affiliate's tenant, any reseller entry there is worth tracing back to the partner that holds it.

# Read-only. Lists the customers of the CSP partner tenant that owns the token.
# Partner Center accepts app-only or app+user credentials for this call.
# Compare each items[].companyProfile.tenantId against the partner's own
# tenant IDs and the tenant IDs of every affiliate organisation.

GET https://api.partnercenter.microsoft.com/v1/customers?size=40 HTTP/1.1
Authorization: Bearer {token}
Accept: application/json

Limitations

The customer list shows reseller relationships held by the partner tenant that makes the call. It cannot show a subscription a different CSP partner sells to an affiliate, a web direct subscription or a benefit redemption, because none of those creates a reseller relationship with this partner. The size parameter sets how many customers one call returns, so a large customer book needs more than one page. This note describes the documented request and response and did not run the call against a live partner tenant. The admin center view carries its own caveat from Microsoft: "Keep in mind that this information might be out of date."

Nothing on the cited pages describes how Microsoft detects or treats a self-sale, and "affiliate" is defined in the contract rather than on the page, so this note cannot say which related entities count. Whether a partner sees the keyless benefit redemption flow depends on its country or region and on when the parent offer was bought, per the cloud services benefits page, so read the partner's own Benefits workspace before relying on any quantity above.

Mapping each subscription in a tenant back to the channel that actually supplied it is part of the cloud licensing and procurement work this practice does.