For Remote Desktop Services (RDS) hosted under the Microsoft Services Provider License Agreement (SPLA), the licensing unit is the Subscriber Access License (SAL). The core rule is non-negotiable: The SPLA reports are driven by authorization, not activity.
This crucial distinction separates compliance from a catastrophic penalty, as Microsoft licenses the authorized user, not the session. If a user is authorized to access your hosted RDS service at any moment within a calendar month, you must report one SAL for that user. This obligation stands regardless of whether they connected, how frequently they connected, or the number of concurrent sessions your infrastructure supported. Theoretical access is the licensing trigger.
This authorization mandate applies to all aspects of RDS-SAL reporting but remains the most serious and costly compliance pitfall in the hosting industry. After decades of audits repeatedly uncovering massive under-reporting, providers continue to make the same fundamental mistake: they treat authorization as a secondary technical metric rather than a primary, conscious policy decision. Miscounting this authorization can trigger a six-figure audit penalty.
The unyielding core of SPLA RDS licensing
Under the Microsoft SPLA, your obligation is to report one RDS SAL for every unique user authorized to access your hosted RDS service during the calendar month. The following factors are irrelevant to your reporting requirement:
- Whether the user actually connected to the service;
- How many times they logged in;
- The number of concurrent sessions your infrastructure supported;
- The device used to access the service.
The licensing requirement is laser-focused on authorization, not usage activity. If a user is granted authorization on the 5th of the month and their access is revoked on the 8th, that user is still reportable for the entire month. There are no partial-month credits, no usage-based discounts, and no exceptions for "inactive" authorized users.
Eliminate these four costly misconceptions
The majority of SPLA compliance failures stem from these foundational misunderstandings:
- “We can report based on peak concurrent sessions.”
The Reality: Peak concurrent usage is for capacity planning, not licensing. Your system may support 50 simultaneous connections, but if 150 users are provisioned with access, you are obligated to report 150 SALs. The distinction is who has access, not who is accessing the system at a given moment.
- "Session logs are sufficient for licensing data."
The Reality: Connection logs show usage patterns: a technical data point. Authorization exists entirely independently of usage. A user with access rights who never logs in still requires a SAL.
- "A month-end Active Directory snapshot is sufficient.”
The Reality: A month-end snapshot provides only a single point-in-time view. Microsoft demands accountability for every user authorized at any point during the month, also known as the “highest watermark” metric. If you onboarded 50 users mid-month and offboarded them before the 30th, they still count toward the monthly total.
- "User accounts must be counted.”
The Reality: The actual (real) users accessing the service are what counts.
- If 50 different AD accounts are used by only one person, you report one SAL.
- If one AD account is shared by multiple people (a compliance risk known as “multiplexing”), you must report a SAL for each person accessing that shared account.
What "Authorization" actually means
Authorization is a policy decision, not a registration event. You need written, enforceable definitions that are accepted by the auditors:
- Establish clear policy language
Define Active Directory groups that grant RDS access (e.g., "RDS_Production_Users”). Document this precisely: "A user is authorized if they are a member of any AD group or policy that permits RDS access to production resources. Authorization begins at the timestamp of group addition and ends at removal.”
- Exclude Non-Human and Admin accounts systematically
Don't exclude administrators, service accounts, or machine identities ad hoc during audits. Maintain a formal registry of approved non-human accounts for operational use, updated regularly and available for audit review. Auditors reject informal, retroactive exclusions.
The business case for compliance: Security and financial predictability
When approached correctly, compliance transforms from a reactive risk into a proactive business advantage:
- Predictable financial planning: Authorization-based SAL counts deliver consistent monthly costs aligned with access provisioning, eliminating unpredictable spikes tied to user activity. This allows for stable, explainable billing for your customers.
- Audit resilience: Service providers that embed robust Software Asset Management (SAM) principles find that a solid SAL process transforms audits from an existential threat into a mere administrative formality.
The consequences of non-compliance
Microsoft imposes a penalty on top of any under-licensing discovered in audits. For a mid-sized hosting provider under-reporting by 450 SALs over 24 months, the audit bill can easily reach six figures before penalties.
Worse, significant non-compliance can result in SPLA agreement termination, an outcome that threatens your entire Microsoft-based hosting business.
Authorization is policy, not technology
The fundamental shift required for SPLA RDS compliance is conceptual, not technical.
Stop thinking of RDS SALs as a measure of usage or a technical metric. Start treating them as a reflection of your access governance and policy decisions.
Every user you authorize creates an immediate licensing obligation, whether they log in once, a thousand times, or never at all. Your compliance process must be built on four pillars:
- Define authorization clearly.
- Track authorization rigorously.
- Report authorization accurately.
- Document everything.
The goal of a Microsoft SPLA audit is to verify compliance for each and every calendar month in the past, not just a current point-in-time assessment. Build your processes around this demanding reality from day one.
Service providers who engineer authorization-based SAL reporting don't just survive audits; they optimize costs, improve customer transparency, and solidify their business foundation. The question is not whether you can afford to implement these practices. It is whether you can afford not to.
Octopus Cloud: The essential solution for the RDS SAL
The mandatory, authorization-based RDS SAL workflow is too complex and audit-intensive to manage manually. This reality is why leading SPLA partners rely on purpose-built automation to secure their business.
The three fatal flaws of manual tracking
Manual RDS reporting systems fail precisely where compliance is tested:
- Incomplete data: Scripts miss users across complex, hybrid environments, leading to guaranteed under-reporting.
- Missing "High Watermark": Without automated daily tracking, you cannot reconstruct the required highest watermark of users authorized during the month.
- No audit trail: Manual spreadsheets lack the immutable, timestamped evidence chain Microsoft auditors demand.
Octopus Cloud eliminates these risks. We automate comprehensive data discovery and apply irrefutable, time-stamped change tracking across your entire infrastructure.
The intelligence engine for guaranteed compliance
Our Intelligence for SPLA converts complex infrastructure data into compliant, cost-optimized reports. The rules engine acts as your automated expert:
- Continuous SPUR compliance: Automatically updates reports with the latest Microsoft use rights.
- Precision calculation: Executes the complex, authorization-based methodology to ensure accurate SAL reporting.
- Audit-proof data: The generated data is accepted by almost all global auditors and thus offers unshakeable confidence.
The risk of audit penalties and SPLA termination is too high to bet on fragile manual processes. Stop risking your business on fragile spreadsheets and incomplete data.
Transform your SPLA compliance from a costly, monthly burden into a secure, automated process.
Cihan Gökgöz, CTO of Octopus Cloud
