IBM Licensing Guide 2026
How IBM's Passport Advantage metrics, sub-capacity rules, and software bundles turn ordinary infrastructure decisions into compliance exposure — and the buyer-side discipline that keeps an IBM estate predictable and defensible.
Executive Summary
IBM software is rarely the largest line in an enterprise estate, but it is often the least understood — and that asymmetry is precisely where exposure accumulates. The Passport Advantage model layers product-specific metrics (Processor Value Unit, Resource Value Unit, Virtual Processor Core, Authorized User, and a dozen others) over a sub-capacity regime that only protects the customer if a specific tool, the IBM License Metric Tool (ILMT), is deployed, configured, and reporting correctly. When ILMT lapses — and in most estates it has lapsed somewhere — IBM's contractual remedy is to bill at full capacity, which can multiply a genuine requirement several times over.
This guide distils what former IBM commercial and compliance practitioners know about how the model is constructed and where buyers routinely overpay: PVU sub-capacity mechanics, RVU and bundle traps, container and cloud metrics, Software Subscription & Support (S&S) renewal economics, and a practical IBM audit-defence framework. The central message is consistent with every vendor we advise on: IBM's compliance position is an assertion built on tooling and policy, not an immovable fact — and disciplined preparation routinely removes 25–50% of a proposed shortfall or renewal.
1. How IBM's Licensing Architecture Is Built
Every effective IBM negotiation starts from the same realisation that governs Oracle or SAP work: the licensing model is a commercial instrument, not a technical specification. IBM's particular design has three load-bearing features. First, almost every product is licensed under a named metric — PVU, RVU, VPC, Authorized User Single Install, Concurrent User, Install, Managed Virtual Server — and each metric counts something different, so the same workload can carry wildly different entitlement depending on which product edition you bought. Second, the right to license a fraction of your hardware (sub-capacity) is conditional on operating IBM's measurement tooling to IBM's satisfaction; fail the condition and the contract reverts to full-capacity counting. Third, IBM sells through Passport Advantage, a points-based program whose Relationship Suggested Volume Price (RSVP) tiers, anniversary dates, and S&S renewal mechanics quietly shape how much leverage you hold and when.
The practical consequence is that the gap between what a customer believes they owe and what IBM asserts is rarely a dispute about facts. It is a dispute about which metric applies, whether sub-capacity eligibility was preserved, and how a bundle's Supporting Programs are counted. Each of those is interpretive, and interpretation is negotiable. Buyers who treat an IBM compliance number as a technical certainty concede the most value; buyers who treat it as a claim to be tested against the actual contract keep it.
IBM's sub-capacity terms live in the Passport Advantage Sub-Capacity Licensing Attachment and the ILMT documentation — not always in the program-specific License Information document a customer reads first. Many "full-capacity" findings rest on a tooling or reporting lapse, not on actual over-deployment. The deployment may be perfectly sized; only the evidence is missing.
2. Processor Value Units and the Sub-Capacity Trap
PVU is IBM's oldest and still most consequential metric. Each processor core is assigned a PVU value from IBM's processor table (commonly 70 or 100 PVU per core depending on chip family), and entitlement is the sum of PVUs across the cores the program runs on. The decisive question is whether you count every core in the physical environment (full capacity) or only the cores available to the specific virtual machines running the IBM software (sub-capacity). Sub-capacity is almost always dramatically cheaper — and it is exactly the eligibility that lapses most often.
To claim sub-capacity, IBM requires that you install ILMT (or, in limited legacy cases, a manual alternative), keep it current, generate the prescribed quarterly reports, and retain them for at least two years. Miss any element — ILMT not deployed on a host, a version too old to recognise a processor, a virtualization technology ILMT cannot read, reports not generated for a quarter — and IBM's position is that the affected programs revert to full-capacity licensing for the period in question. The table below shows how punishing that reversion is.
| Scenario | Cores in scope | PVU/core | PVU entitlement required |
|---|---|---|---|
| Sub-capacity: 4 vCPU VM on a managed cluster | 4 | 70 | 280 |
| Full capacity: 2-socket host (16 cores), ILMT lapsed | 16 | 70 | 1,120 |
| Full capacity: whole 6-host cluster, vMotion enabled | 96 | 70 | 6,720 |
The mitigation is part hygiene and part contract. Operationally, treat ILMT as production infrastructure: monitor that it is installed on every host running PVU-licensed software, that its version recognises your processors, and that bundling data (which scans for IBM software signatures) is reviewed before it is ever shared. Contractually, when IBM asserts full capacity for a lapsed period, establish what the workload actually consumed — full-capacity billing is a contractual remedy for missing evidence, not a measure of real usage, and the gap between the two is the negotiation.
The most common ILMT failure is not absence but blindness: ILMT is running, but a newer hypervisor, a container platform, or a processor model it does not recognise causes it to silently def