Managing Microsoft software licences requires a clear grasp of the metrics used to measure usage. The most common models are based on processor cores, individual users, or devices. Choosing the wrong metric wastes money. Missing a minimum threshold triggers audit exposure. This guide provides a complete breakdown of each model with real-world examples, virtualisation implications, common compliance traps, and strategies for optimising your licence metric selection across the Microsoft estate.
Part of the Microsoft Licensing Knowledge Hub. Related guides include True-Up Best Practices, Licensing in Virtualised Environments, and Microsoft Licensing Guide.
Microsoft licences its products using three fundamental metrics: per-user, per-device, and per-core. Every Microsoft product uses one (or sometimes a combination) of these models. The right choice depends on how your organisation's people interact with the software, and picking the wrong model is one of the most common sources of both over-spend and under-licensing.
Per-user licensing assigns a licence to a specific individual. That user can then access the software from multiple devices (desktop, laptop, tablet, phone) under a single licence. This is the dominant model for cloud services and modern Microsoft 365 subscriptions. One licence per person, regardless of how many devices they use.
Per-device licensing ties the licence to a specific piece of hardware. Any number of users can use the software on that licensed device, but the licence does not extend to other machines. This model is common for shared workstations, kiosks, and environments where devices outnumber named users or where multiple shifts share equipment.
Per-core licensing is based on the processor cores in the server running the software. It measures capacity rather than consumption. Once the server is licensed for its core count, unlimited users and devices can access the software with no additional per-connection fees. This model applies to server products like SQL Server and Windows Server.
Evaluate the ratio of users to devices. If many people share a few devices (shift workers, call centres, shared kiosks), device licences are more cost-effective. If individuals use multiple devices each (knowledge workers with desktop, laptop, and phone), user licences are more efficient. For servers accessed by large or unpredictable user populations, per-core licensing eliminates the need to track individual connections entirely.
Per-user licensing is the most common model in the modern Microsoft estate. Microsoft 365 subscriptions (E3, E5, F1, F3, Business Basic, Business Standard, Business Premium), Dynamics 365 user licences, Power BI Pro, and Power Platform per-user plans all operate on this metric. One licence is assigned to one named individual, and that individual can use the software across all their devices.
How it works in practice. A Microsoft 365 E3 licence assigned to an employee allows them to install Office desktop applications on up to 5 PCs or Macs, 5 tablets, and 5 smartphones. They can access Exchange Online, SharePoint, Teams, and OneDrive from any device. The licence follows the person, not the machine. If the employee gets a new laptop, no additional licence is needed. If they leave the company, the licence is freed and can be reassigned to their replacement.
Where per-user excels. Knowledge worker environments where each person has a dedicated workstation plus one or more additional devices (laptop, phone, tablet). A company with 500 employees, each using a desktop and a laptop, needs 500 per-user licences rather than 1,000 per-device licences. The savings are substantial and the administrative overhead is lower because you track people, not hardware.
Per-user compliance risks. The most common per-user compliance issue is shared accounts. Two employees sharing a single Microsoft 365 account is a licence violation, even if they never use the account simultaneously. Each person who uses the software must have their own licence. Contractors, temporary workers, and external collaborators who access Microsoft 365 resources also require appropriate licensing, either full licences or guest access entitlements depending on the scenario. See our M365 E3 vs E5 vs F3 Comparison.
The opposite risk is over-licensing: paying for users who no longer need licences. Employees who have left the company, contractors whose engagements ended, or users who have been reassigned to roles that require a lower-tier licence (E5 assigned to someone who only needs E3 functionality). Regular licence reconciliation, at least quarterly, identifies these "ghost" licences and reclaims them for reassignment. For a 5,000-user organisation, ghost licences typically represent 5 to 10% of the user population, which translates to $100,000 to $300,000 per year in wasted spend depending on the licence tier.
Per-device licensing ties the licence to a specific piece of hardware. Any number of users can use the licensed software on that device, but the licence does not cover any other machine. This model predates the cloud era and remains relevant for specific scenarios where devices are shared across users.
How it works in practice. A Windows Server Device CAL assigned to a specific PC allows any user of that PC to access Windows Server resources (file shares, print services, Active Directory). A Windows desktop licence tied to a specific workstation covers anyone who sits down at that workstation. The licence follows the machine, not the person.
Where per-device excels. Shared workstation environments with more users than devices. Call centres where three shifts of agents use the same desks. Hospital nursing stations accessed by rotating clinical staff. Manufacturing floor terminals used by different operators. Public library or school computer labs. In all these scenarios, the number of users exceeds the number of devices, making per-device licensing significantly cheaper than per-user.
Per-device cost advantage example. A call centre with 100 workstations used across 3 shifts (300 total agents) needs either 300 per-user CALs or 100 per-device CALs for Windows Server access. At comparable per-unit pricing, the device model costs one-third as much. The savings scale linearly: more shifts and more users per device mean greater cost advantage for the device model.
Per-device compliance risks. The primary risk is untracked devices. When new PCs, laptops, or terminals are deployed without being added to the licence inventory, they access server resources without proper CALs. Hardware refresh cycles are a common trigger: old devices are retired and new devices are deployed, but the licence records are not updated. Thin clients and virtual desktop endpoints also require device CALs if they access Windows Server resources, a point frequently missed in VDI deployments.
Most enterprises have both dedicated-user and shared-device scenarios within the same environment. The optimal approach is a hybrid licence model: per-user CALs for knowledge workers with dedicated devices and per-device CALs for shared workstations. Microsoft allows mixing user and device CALs within the same environment. The key is mapping each access scenario to the cheaper model. Get this wrong and you either over-pay (user CALs for shift workers) or under-licence (no CALs for shared terminals).
Per-core licensing is the most complex and most frequently mis-licensed of Microsoft's three models. It applies to server products, primarily SQL Server and Windows Server, and is based on the number of physical processor cores in the server hardware. The principle is simple: licence the capacity of the machine, and unlimited users can access the software. The execution is where organisations get into trouble.
How core counting works. Count the physical cores in each processor installed in the server. A server with two 12-core processors has 24 physical cores and requires 24 core licences. Core licences are sold in 2-core packs, so this server needs 12 two-core packs. Straightforward when the server runs a single SQL Server instance on bare metal.
Microsoft's core minimums. This is where most compliance issues originate. Microsoft imposes two mandatory minimums that override the actual core count.
Minimum 1: 8 cores per physical processor. Even if a processor has only 4 or 6 cores, you must licence at least 8 cores for that processor. A server with two 4-core processors (8 physical cores) requires licensing for 16 cores (8 per processor), not 8.
Minimum 2: 16 cores per physical server. Even if the server has a single 8-core processor (meeting the per-processor minimum), the per-server minimum requires 16 cores. A single-processor server with an 8-core CPU requires 16 core licences, not 8.
These minimums mean that every physical server running SQL Server or Windows Server Datacenter/Standard requires a minimum of 16 core licences, regardless of actual core count. For small servers, this minimum can double the effective licensing cost.
Step 1: Count physical cores per processor.
Step 2: Apply the 8-core-per-processor minimum (round up any processor below 8 cores to 8).
Step 3: Multiply by number of processors to get total core count.
Step 4: Apply the 16-core-per-server minimum (if total from Step 3 is below 16, round up to 16).
Step 5: Purchase core licences in 2-core packs for the number from Step 4.
Example: Server with 2x 10-core CPUs = 20 physical cores. Per-processor minimum met (10 > 8). Per-server minimum met (20 > 16). Licence 20 cores = 10 two-core packs.
Example: Server with 1x 6-core CPU = 6 physical cores. Per-processor minimum: round up to 8. Per-server minimum: round up to 16. Licence 16 cores = 8 two-core packs, despite having only 6 physical cores.
SQL Server editions and core licensing. SQL Server comes in two core-licensed editions: Standard and Enterprise. SQL Server Standard is licensed per core with all the minimums above, and imposes additional capacity limits (24 cores maximum per instance, 128 GB RAM per instance). SQL Server Enterprise is licensed per core with no capacity limits. The per-core price difference is substantial: SQL Server Enterprise core licences cost roughly 4x more than Standard. Choosing between Standard and Enterprise is one of the most consequential licensing decisions in the Microsoft server estate. See our SQL Server Licensing Guide.
Windows Server editions and core licensing. Windows Server Standard and Datacenter are both core-licensed with the same minimums. The critical difference is virtualisation rights. Windows Server Standard allows two virtual machines (OSEs) per set of core licences. Windows Server Datacenter allows unlimited virtual machines per set of core licences. For highly virtualised environments, Datacenter is typically more cost-effective despite the higher per-core price. See our Virtualisation Licensing Guide.
| Characteristic | Per-User | Per-Device | Per-Core |
|---|---|---|---|
| Licence assigned to | Individual person | Specific hardware | Server CPU cores |
| Covers multiple devices? | Yes, all of the user's devices | No, one device only | N/A, server capacity metric |
| Covers multiple users? | No, one user only | Yes, all users of that device | Yes, unlimited users once licensed |
| Common products | M365, Dynamics 365, Power BI Pro, Power Platform | Windows Server CALs, Windows desktop OS, Office LTSC | SQL Server, Windows Server Standard/Datacenter |
| Best when | Users have multiple devices each | Devices shared by many users | High or unknown user counts accessing servers |
| Tracking complexity | Low: count headcount | Low: count hardware assets | Medium: count cores plus apply minimums |
| Key compliance risk | Shared accounts, ghost users | Untracked devices after hardware refresh | Under-licensing due to core minimums |
| Typical cost driver | User count and tier (E3/E5/F3) | Device count and device type | Core count, edition (Standard/Enterprise/Datacenter), and virtualisation density |
Virtualisation transforms core licensing from a straightforward counting exercise into one of the most complex areas of Microsoft compliance. The rules differ significantly between SQL Server and Windows Server, and between Standard and Datacenter editions. Getting this wrong is the single most common source of multi-million-dollar compliance findings in Microsoft audits.
Windows Server Standard: 2 VMs per core licence set. A set of Windows Server Standard core licences (covering all physical cores on the host, minimum 16) entitles you to run 2 Windows Server virtual machines (Operating System Environments, or OSEs) on that host. If you need more VMs, you must purchase additional sets of core licences. A host with 24 cores running 6 Windows Server VMs needs 3 sets of 24-core licences (3 sets x 2 VMs = 6 VMs covered). This stacking calculation is frequently done incorrectly.
Windows Server Datacenter: unlimited VMs per core licence set. One set of Datacenter core licences covering all physical cores on the host allows unlimited Windows Server VMs on that host. For highly virtualised environments (more than 4 to 6 VMs per host), Datacenter is typically cheaper than stacking Standard licences. The break-even point depends on the per-core price difference and the VM density per host.
SQL Server in VMs: licence the virtual cores. For SQL Server running in virtual machines, you can licence either the physical host's total cores or the virtual cores assigned to the specific VM. Licensing virtual cores is typically cheaper because you licence only the cores allocated to the VM, subject to the same minimums (4-core minimum per VM for SQL Server, with the 16-core-per-server minimum applied to the physical host only if licensing the full host). This flexibility allows organisations to right-size SQL Server licensing to actual VM allocations rather than paying for unused host capacity.
Software Assurance and Licence Mobility. SQL Server core licences with active Software Assurance include Licence Mobility rights, allowing the licences to move between servers and between on-premises and Azure (via Azure Hybrid Benefit). Without SA, SQL Server core licences are locked to specific hardware and cannot be moved when VMs migrate between hosts. For dynamic virtualised environments where VMs move between hosts regularly, SA with Licence Mobility is effectively mandatory.
Windows Server and SQL Server core licences with active Software Assurance qualify for Azure Hybrid Benefit (AHB), which reduces Azure VM compute costs by 40 to 50%. AHB allows you to use your existing on-premises core licences to cover the licensing cost of Windows Server or SQL Server running in Azure VMs. For organisations migrating workloads to Azure, AHB transforms on-premises core licences from a sunk cost into a strategic asset that directly reduces cloud spend. Track your SA-covered core licences carefully: each one represents real Azure savings. See Negotiating Azure Commitments in Your EA.
Windows Server and SQL Server Standard can be licensed under two different models: Server + CAL (a server licence plus individual Client Access Licences for each user or device) or core-only (per-core licences with no CAL requirement). The choice between these models depends on user volume and predictability.
Server + CAL model. Under this model, you purchase a server licence for each server instance plus a CAL (either per-user or per-device) for every user or device that accesses the server. This model works well when the user population is known, finite, and manageable. A departmental SQL Server database accessed by 50 users in a specific team is efficiently licensed with a server licence plus 50 user CALs.
Core-only model. Under this model, you purchase core licences based on the server's physical core count. No CALs are required. Once the cores are licensed, unlimited users and devices can access the server. This model works well when user counts are large, unpredictable, or difficult to track. A SQL Server database backing a customer-facing web application with thousands of anonymous users is far more efficiently licensed per-core than with individual CALs for every website visitor.
The break-even calculation. The core-only model has a higher upfront cost (licensing all cores) but no per-user incremental cost. The Server + CAL model has a lower server cost but adds cost per user or device. The break-even depends on the number of users: for servers with fewer than approximately 50 to 100 users (depending on edition and pricing), Server + CAL is cheaper. Above that threshold, core-only becomes more economical because the fixed core licensing cost is spread across a larger user base.
For any server accessible from the internet by external users (web servers, public-facing SQL Server databases, customer portals), core-only licensing is the only practical option. You cannot track or license every external user with individual CALs. Microsoft's licensing terms require either a CAL for every accessing user/device or core licences that cover unlimited access. For internet-facing workloads, core licensing is not optional, it is the only compliant approach.
Even experienced IT teams make predictable mistakes with Microsoft licensing metrics. These pitfalls are the most frequent sources of compliance findings in Microsoft audits and the most common causes of over-spend in licence renewals.
Ignoring core minimums. The single most common compliance gap. A server with a single 6-core processor requires 16 core licences, not 6. Organisations that licence based on actual core counts without applying the 8-per-processor and 16-per-server minimums are under-licensed on every small server. In a data centre with dozens of servers, these gaps compound into a significant compliance exposure.
Wrong metric for the scenario. Using per-user CALs for a call centre with shared workstations (per-device would be cheaper) or per-device CALs for a remote workforce where each person accesses from multiple devices (per-user would be cheaper). The wrong metric selection does not create a compliance issue but it does create unnecessary cost. For a 500-user call centre with 200 shared workstations across 3 shifts, the cost difference between per-user (500 CALs) and per-device (200 CALs) is 300 CALs multiplied by the per-unit price.
Stacking errors in virtualised Windows Server. Windows Server Standard allows 2 VMs per licence set. Organisations that count incorrectly, such as believing 1 licence set covers 4 VMs, or that do not add additional licence sets when VM density increases, are under-licensed. Every host where the VM count exceeds the licensed entitlement is a compliance finding. This is the single largest compliance exposure in virtualised Microsoft environments.
Missing CALs for indirect access. When users access a Windows Server or SQL Server resource indirectly, through a middleware application, a web portal, or an API, each accessing user or device still needs a CAL unless the server is licensed per-core. "Multiplexing" (using middleware to reduce the apparent number of connections) does not reduce the CAL requirement. Every user at the front end of the application chain who ultimately accesses the server needs a licence.
Ghost users on per-user subscriptions. Departed employees, completed contractors, and users who have changed roles but retained high-tier licences represent pure waste. For M365 E5 at approximately $57/user/month, 100 ghost licences cost $68,400 per year. Quarterly licence reconciliation against HR and directory data identifies and reclaims these licences.
Not reassessing at renewal or true-up. Organisations that select a licensing model at initial deployment and never revisit it as the environment changes end up with misaligned metrics. A company that adopted per-device CALs five years ago, before moving to a remote-first model where every employee now accesses from 3 devices, is paying for a model that no longer fits. Every EA renewal and annual true-up is an opportunity to reassess and optimise the metric selection.
Licence metric optimisation is one of the highest-ROI activities in Microsoft licensing management. The wrong metric costs money every month, and the right metric saves money every month. The following strategies apply across the Microsoft estate.
Map every access scenario to the cheapest compliant metric. For each Microsoft product in your environment, identify who or what accesses it, and calculate the cost under each available metric (per-user, per-device, per-core, Server+CAL). Choose the cheapest option for each scenario independently. You are not locked into a single metric for the entire estate. Use per-user CALs for knowledge workers, per-device CALs for shared workstations, and per-core for servers with large or internet-facing user populations.
Right-size core licensing to actual VM allocations. For SQL Server in virtualised environments, licence virtual cores assigned to the VM rather than the full physical host (where permitted and cost-effective). If a SQL Server VM is allocated 8 virtual cores on a 32-core host, licensing the 8 virtual cores (with the 4-core-per-VM minimum) is significantly cheaper than licensing all 32 physical cores. Ensure the VM allocation is documented and enforceable to support audit defence.
Evaluate Standard vs Datacenter for Windows Server hosts. Calculate the break-even point for each virtualisation host. If a host runs more than approximately 8 to 12 Windows Server VMs (the exact threshold depends on core count and pricing), Datacenter is cheaper than stacking Standard licence sets. For highly consolidated environments with 20 or more VMs per host, Datacenter is dramatically cheaper.
Leverage Azure Hybrid Benefit for cloud workloads. Every Windows Server and SQL Server core licence with active Software Assurance represents a potential 40 to 50% reduction in Azure VM costs. Map your SA-covered core licence inventory against your Azure VM footprint. Apply AHB to every eligible VM. For organisations with large on-premises Windows Server and SQL Server estates migrating to Azure, AHB can represent hundreds of thousands of dollars in annual Azure savings.
Consolidate and rationalise at EA renewal. The EA renewal is the optimal time to reassess licence metrics across the entire Microsoft estate. Bring a complete inventory of current licensing (by metric), a current deployment map (who and what accesses each product), and an optimised target state (cheapest compliant metric for each scenario) to the renewal negotiation. Use the optimised model to set true-up quantities and subscription counts for the new EA term. See our EA Optimisation Service.
The annual true-up is not just a compliance checkpoint. It is an opportunity to adjust licence quantities, switch metrics where beneficial, and eliminate waste. Organisations that treat true-ups as a compliance burden rather than an optimisation opportunity leave money on the table every year. Prepare for each true-up with a fresh deployment inventory, a metric analysis, and a target licence position. See True-Up Best Practices.
Microsoft licensing metric optimisation requires deep knowledge of Microsoft's product terms, pricing models, and audit practices. Independent advisory delivers value that internal teams and Microsoft's own account teams cannot provide objectively.
Unbiased metric analysis. Independent advisors do not sell software. Their goal is to find the most efficient and compliant licence configuration for your organisation. They identify scenarios where you are overspending on one metric when another would suffice, all without vendor bias. Microsoft's account team is incentivised to maximise your spend. An independent advisor is incentivised to minimise it.
Licence compliance assurance. Independent experts perform licence health checks that identify compliance gaps before Microsoft does. They catch scenarios like core minimum violations, stacking errors in virtualised environments, missing CALs for indirect access, and ghost users on per-user subscriptions. Correcting these findings proactively is dramatically less expensive than correcting them during a Microsoft audit. See our Microsoft Audit Defence Service.
Cost optimisation at scale. For enterprises with thousands of users, hundreds of servers, and complex virtualised environments, the savings from metric optimisation compound across the entire estate. Switching 500 call-centre agents from per-user to per-device CALs, right-sizing SQL Server core licensing to VM allocations, applying AHB to Azure VMs, and reclaiming ghost M365 licences can collectively save hundreds of thousands of dollars annually.
"Understanding Microsoft's core, user, and device licensing metrics is a foundational skill for managing software assets. The organisations that control costs are the ones that match the licence metric to the access pattern for every product in their estate, reassess at every renewal and true-up, and engage independent advisory to validate their position before Microsoft does."
Microsoft requires a minimum of 8 core licences per physical processor and 16 core licences per physical server. This means that even a single-processor server with only 4 physical cores requires 16 core licences (the per-processor minimum of 8 applies, then the per-server minimum of 16 overrides). These minimums are the most commonly missed compliance requirement in Microsoft server licensing. Every physical server running SQL Server or Windows Server Standard/Datacenter needs at least 16 core licences regardless of actual core count.
It depends on the ratio of users to devices. If users outnumber devices (shift workers sharing workstations, call centres, shared kiosks), per-device CALs are cheaper because you licence each device once and all users are covered. If devices outnumber users per person (knowledge workers with a desktop, laptop, and phone), per-user CALs are cheaper because one licence covers all of a person's devices. Microsoft allows mixing user and device CALs in the same environment, so you can use per-user for some populations and per-device for others to optimise cost.
You have two options. Option 1: licence all physical cores on the host server. This covers all SQL Server VMs on that host (with SA for Licence Mobility if VMs move between hosts). Option 2: licence only the virtual cores assigned to the specific SQL Server VM, subject to a 4-core minimum per VM. Option 2 is typically cheaper for environments where SQL Server VMs use a fraction of the host's total cores. The 16-core-per-server minimum applies only when licensing the full physical host, not individual VMs. Ensure VM core allocations are documented for audit defence. See our SQL Server Licensing Guide.
Windows Server Standard allows 2 VMs per licence set (a set covers all physical cores on the host, minimum 16). Datacenter allows unlimited VMs per licence set. If a virtualisation host runs more than approximately 8 to 12 Windows Server VMs, Datacenter is typically cheaper than purchasing multiple stacked Standard licence sets to cover the VM count. Calculate the break-even for your environment: multiply the per-core Standard price by the number of licence sets needed (VM count divided by 2, rounded up) and compare to the per-core Datacenter price for one licence set. For highly consolidated environments with 20+ VMs per host, Datacenter is dramatically cheaper. See our Virtualisation Licensing Guide.
Multiplexing is using middleware, software, or hardware to pool or reduce the number of connections that directly access a Microsoft server product. Common examples include web servers that accept user requests and query SQL Server on behalf of users, or middleware applications that aggregate multiple user sessions into fewer database connections. Multiplexing does not reduce the CAL requirement. Every user or device at the front end of the application chain that ultimately accesses the Microsoft server product needs a CAL, regardless of how the connection is routed or pooled. This is one of the most frequently misunderstood Microsoft licensing rules and a common audit finding.
Azure Hybrid Benefit (AHB) allows organisations with Windows Server or SQL Server core licences that have active Software Assurance to use those licences to cover the software cost of running Windows Server or SQL Server in Azure VMs. This reduces Azure VM compute costs by approximately 40 to 50%. Each set of Windows Server core licences (16 cores) with SA can cover a Windows VM with up to 16 vCPUs. Each SQL Server core licence with SA can cover one vCPU in Azure. AHB transforms on-premises core licences from a sunk cost into an active cost-reduction tool for cloud workloads. Track your SA-covered core licence inventory and apply AHB to every eligible Azure VM.
At minimum, reassess at every EA renewal (every 3 years) and at every annual true-up. Organisations that undergo significant changes (cloud migration, remote work adoption, virtualisation consolidation, M&A activity, workforce growth or reduction) should reassess immediately after the change. The licensing metric that was optimal three years ago may no longer be the cheapest option today. A company that moved to remote work may now save by switching from per-device to per-user CALs. An organisation that consolidated servers may save by switching from Standard to Datacenter. Treat every change in infrastructure or workforce as a trigger to re-evaluate. See our EA Optimisation Service.
Redress Compliance delivers independent Microsoft licensing assessments: licence metric analysis, compliance health checks, core licensing audits for virtualised environments, true-up preparation, and EA renewal optimisation. Most engagements identify savings worth multiples of the advisory investment.
Microsoft Optimisation ServicesIndependent Microsoft licensing advisory. Metric analysis. Core licensing compliance. EA optimisation. 100% vendor-independent.