IBM's sub-capacity licensing programme is one of the most commercially significant — and operationally complex — compliance requirements in the enterprise software market. Sub-capacity pricing allows organisations running IBM software on virtualised infrastructure to pay for the virtual processor capacity actually allocated to IBM workloads rather than the full physical capacity of the underlying server. The financial difference is substantial: for large IBM software estates, sub-capacity pricing reduces licence costs by 60–80% compared to full-capacity pricing.
The condition for sub-capacity pricing eligibility is deployment and continuous operation of IBM License Metric Tool (ILMT) — IBM's own sub-capacity measurement technology. Organisations that claim sub-capacity pricing but have not correctly deployed and operated ILMT are claiming a pricing benefit they are not contractually entitled to, and IBM's audit programme specifically targets this gap. For the full audit defence framework, see our Software Audit Defence Guide. For IBM-specific audit triggers, see what triggers a software audit.
The ILMT Compliance Risk: An organisation claiming sub-capacity pricing for IBM software without correctly deployed ILMT is exposed to retroactive full-capacity pricing from the date sub-capacity pricing was first claimed — not just prospectively. For a large IBM software estate, this exposure can exceed $10M. IBM's audit programme uses ILMT deployment status as the primary criterion for audit prioritisation. There is no workaround: ILMT (or IBM's CloudPak for Multicloud Management as an approved alternative) is the only path to sub-capacity compliance.
Understanding Sub-Capacity Pricing
IBM's Processor Value Unit (PVU) licensing model charges per virtual core for IBM software running on virtualised infrastructure. Full-capacity pricing requires PVU coverage for every physical core on every server in the cluster where IBM software runs — regardless of how many virtual machines are running IBM workloads. Sub-capacity pricing requires PVU coverage only for the virtual cores assigned to virtual machines running IBM software.
For a 20-core physical server running VMware with three IBM WebSphere virtual machines each allocated 2 virtual cores, full-capacity pricing requires 20 cores × PVU rate × number of servers in the cluster. Sub-capacity pricing requires 6 virtual cores × PVU rate — a reduction of 60–90% depending on cluster density. The commercial stakes are high enough that IBM includes sub-capacity eligibility requirements directly in its International Passport Advantage Agreement.
ILMT: What It Is and What It Does
IBM License Metric Tool is IBM's proprietary sub-capacity measurement tool, available at no additional cost to IBM Passport Advantage customers. It performs three core functions: software discovery across managed endpoints to identify IBM product installations; licence metric calculation for sub-capacity pricing (determining actual virtual core allocation for IBM workloads); and audit snapshot generation — the formal compliance records that IBM requires organisations to retain and produce in an IBM audit.
ILMT is not a general-purpose SAM tool — it is specifically designed for IBM licence compliance measurement. Third-party SAM platforms (ServiceNow, Flexera, Snow) cannot substitute for ILMT. IBM's sub-capacity pricing condition requires specifically ILMT or IBM CloudPak for Multicloud Management — no other tool satisfies the contractual requirement, regardless of how comprehensive the third-party tool's IBM software discovery capabilities are.
ILMT Deployment Requirements
The specific deployment and operation requirements for ILMT sub-capacity pricing eligibility are defined in IBM's Software Licence Information (SLI) documents and the IBMPA Agreement. The requirements below represent the minimum compliance standard IBM auditors apply when assessing ILMT deployment.
Core Deployment Requirements
- ILMT must be deployed before sub-capacity pricing is first claimed — retroactive deployment does not establish eligibility for the period before deployment
- All virtualised systems running IBM sub-capacity-eligible software must be within ILMT's scan scope — gaps in scan coverage void sub-capacity eligibility for uncovered systems
- ILMT server must be deployed on infrastructure that can reach all managed endpoints — air-gapped networks, isolated VLAN segments, and DMZ systems frequently create coverage gaps
- ILMT must use an IBM-approved version — organisations running end-of-support ILMT versions are at risk of non-compliance; IBM releases updated versions and requires migration within defined windows
- ILMT BigFix infrastructure (where applicable) must be correctly sized and operational — ILMT relies on BigFix endpoint management for agent deployment and data collection
Scan Frequency and Data Quality Requirements
- Software catalogue scans must run at least every 30 days across all managed endpoints
- Hardware inventory scans must run at minimum monthly to capture processor allocation changes
- ILMT's software catalogue must be kept current — IBM releases catalogue updates; organisations must apply updates to maintain accurate product recognition
- Product ID mapping must be validated — ILMT product IDs must correctly match the IBM Passport Advantage part numbers for your licenced products
- Virtual machine processor allocation data must be current — when VM sizing changes, ILMT must capture the change before the next compliance measurement period
Audit Snapshot Requirements
- ILMT audit snapshots must be generated at least quarterly and retained for a minimum of two years
- Snapshots must be generated from the ILMT instance that covers the complete IBM software estate — partial snapshots covering only a subset of managed systems are not sufficient
- Snapshot data must be exportable in IBM's required format — organisations should test snapshot export periodically to confirm the process works before an audit requires it
- Snapshot history must be continuous — gaps in the quarterly snapshot sequence create periods of unverifiable compliance that IBM auditors treat as full-capacity periods
Common ILMT Compliance Failures
The following failures are the most frequently identified gaps in IBM audit reviews. Each represents a specific exposure to retroactive full-capacity pricing claims.
Coverage Gap: Isolated Networks and Cloud Instances
ILMT requires network connectivity between the ILMT server and all managed endpoints. Systems on isolated networks — disaster recovery environments, high-security segments, government-classified networks — frequently fall outside ILMT scan coverage. IBM software on these systems is not covered by sub-capacity pricing regardless of what ILMT reports for the rest of the estate. Cloud instances (AWS, Azure, GCP) running IBM software also require explicit ILMT configuration — cloud instances are not automatically discovered.
Deployment Gap: ILMT Deployed After Sub-Capacity Pricing Claimed
The most commercially damaging ILMT gap is the organisation that deployed IBM software on virtual infrastructure and claimed sub-capacity pricing — through procurement at sub-capacity rates or through sub-capacity reporting on true-up forms — before deploying ILMT. IBM's position is that sub-capacity pricing eligibility begins from the date ILMT was correctly deployed. The period before ILMT deployment is billed at full capacity. For organisations that have been using sub-capacity pricing for several years without ILMT, this retroactive exposure can be the single largest software compliance liability in the estate.
Container Scanning Gap: IBM Cloud Paks and OpenShift
IBM software deployed in container environments — particularly IBM Cloud Paks running on Red Hat OpenShift — requires container-level ILMT scanning that is separate from and additional to standard ILMT endpoint scanning. Many organisations have deployed OpenShift and IBM Cloud Paks without implementing the container scanning configuration, creating a sub-capacity compliance gap for all containerised IBM workloads. IBM is increasingly focused on container scanning compliance as Cloud Pak deployments proliferate.
ILMT Remediation: The Prioritisation Approach
For organisations that have identified ILMT deployment gaps, remediation should be approached in a specific sequence that prioritises the highest commercial exposure while building toward complete ILMT coverage.
- Conduct a confidential ILMT coverage assessment under legal privilege. Before engaging IBM, you need to understand your own ILMT coverage gaps and the sub-capacity pricing exposure they represent. This assessment should be commissioned under legal privilege so that the findings are privileged work product. The assessment should map every system running IBM sub-capacity-eligible software against ILMT scan coverage, identify gaps, and quantify the potential full-capacity pricing exposure for each gap.
- Prioritise deployment to highest-exposure systems. ILMT deployment to the systems with the largest IBM software deployments (highest PVU count, most IBM products) should begin immediately. Each system brought into ILMT scan coverage reduces the prospective full-capacity exposure. The historical exposure for pre-ILMT periods cannot be erased, but reducing prospective exposure is commercially significant.
- Validate software catalogue currency and product ID mapping. An ILMT instance that has not had its software catalogue updated may be technically deployed but reporting incorrect licence obligations. Validate that the current IBM software catalogue is loaded, that all IBM products in your estate are correctly recognised, and that product IDs map to the correct Passport Advantage part numbers.
- Implement container scanning for OpenShift/Cloud Pak environments. If you have IBM Cloud Pak or OpenShift deployments, implement the ILMT License Service (the container-specific ILMT component) and integrate it with your primary ILMT deployment. This is a specific technical implementation that requires the ILMT documentation for container environments.
- Generate and archive quarterly snapshots going forward. Once ILMT is correctly deployed, establish a formal process for generating quarterly audit snapshots and archiving them with retention for at least two years. This process should be owned by a named individual and documented in your SAM governance framework.
- Engage IBM through your account team with a remediation narrative. Once you have achieved substantive ILMT coverage, engaging IBM proactively — with a documented remediation programme and evidence of progress — is more commercially effective than waiting for IBM's audit team to discover gaps. Proactive engagement often results in IBM treating historical gaps more commercially generously than a confrontational audit process.
IBM BigFix vs. ILMT Without BigFix
ILMT historically required IBM BigFix (Endpoint Manager) as its infrastructure foundation — BigFix agents deployed to managed endpoints collected the hardware and software discovery data that ILMT analysed. IBM subsequently introduced a standalone ILMT deployment option (ILMT without BigFix, using its own lightweight agent) that reduces the infrastructure requirement, particularly for organisations that are not BigFix customers.
Both deployment models satisfy the sub-capacity compliance requirement. The choice between BigFix-based and standalone ILMT should be based on your existing infrastructure: organisations already using BigFix for patch management or endpoint management should use the integrated ILMT/BigFix deployment. Organisations without BigFix should use the standalone ILMT agent deployment, which is simpler to implement and maintain for SAM-only use cases.
Redress Compliance is the leading independent advisory firm for IBM licence compliance and ILMT programme management. Their IBM practice includes ILMT coverage assessment, deployment programme management, sub-capacity exposure quantification, and IBM audit defence for organisations facing IBM compliance reviews. Their former IBM licence programme managers understand both the technical ILMT requirements and the commercial negotiation framework IBM uses in sub-capacity audits. Our Vendor Audit Defence service covers IBM audit management, including ILMT remediation and settlement negotiation. The Software Audit Preparation white paper covers the complete audit readiness framework, including IBM ILMT compliance as a core component.
For the broader compliance controls that protect against IBM and other vendor audits, see the enterprise software compliance checklist. For the full audit defence framework applicable to IBM and other vendors, see our Software Audit Defence Guide. For SAM tooling context — including why third-party SAM tools cannot substitute for ILMT — see the SAM Tools Guide.