subscription-manager output, read against the contract.
Red Hat audit teams routinely request the output of the subscription-manager command across the estate as evidence of attached entitlements and consumed subscriptions. The tool's output represents the attach state at the moment of the query, not the contractual entitlement; the two are frequently different, and the difference is where the audit defense lives. This note treats subscription-manager output as audit evidence and the posture that maps the tool's view back to the contract that governs.
What subscription-manager actually shows.
The subscription-manager command on a RHEL host reports the system's registration status with Red Hat, the entitlements currently attached to the system, the entitlements consumed from each subscription pool, and a set of system facts including CPU socket count, virtualisation type, and the operating system version. The tool exposes its data through several subcommands. subscription-manager list shows attached subscriptions and available pools; subscription-manager facts shows system topology; subscription-manager status shows the current compliance state from Red Hat's perspective.1
The practice's reading is that subscription-manager output represents the attach state at a moment in time, not the contractual entitlement that governs. A system showing "current" compliance under subscription-manager is one that Red Hat's tooling considers in compliance with the attach pattern; that does not necessarily match the audit clause's view of the same fleet, particularly when subscriptions have been added, moved, or unattached over the contract's term. The parent service note on Red Hat audit defense treats the general evidence posture; the present note treats the subscription-manager application.
Which subcommand outputs matter.
The audit team's typical request for subscription-manager output covers list, facts, and status. Each subcommand surfaces different evidence. list reveals which subscription pools the system is attached to and which pools were available at registration time. facts reveals the CPU topology that drives socket pair and core counting. status reveals the system's compliance from Red Hat's view, including any expired or insufficient attachments. The defended response produces what the contract entitles the audit team to see; the request for additional subcommand output must be addressed on the merits.
The Insights data sharing question intersects with subscription-manager output. A system running with Insights enabled is sharing telemetry with Red Hat that overlaps with the subscription-manager view. The companion note on Red Hat Insights data and audit treats the Insights side; the subscription-manager output the customer produces from its own systems is generally the more carefully scoped evidence source.
| Subcommand | What it surfaces | Disclosure posture |
|---|---|---|
| list --consumed | Attached subscription pools | Typically required |
| facts | CPU topology, virt status | Required for counting |
| status | Compliance from RH view | Typically required |
| identity, refresh | Registration tokens | Withhold tokens |
Attach state versus contractual entitlement.
The single most common error in subscription-manager based audit findings is treating attach state as equivalent to contractual entitlement. The two diverge in several ways. A subscription that was attached to a system at one point but later moved to a different system continues to be reflected in historical logs but not in current attach state. A subscription that was sold to the customer but never attached anywhere produces zero attach state and zero audit finding, but is contractually entitled. A subscription whose pool expired technically while a renewal was pending produces a non compliant attach state but is contractually in force.
The defended response builds the contract side first. The list of subscriptions Red Hat actually sold to the customer (with quantities, terms, and dates) is the contractual entitlement; the attach state on the systems is a separate fact. The audit team's finding rests on the gap between attach state and the workload count; the customer's defense rests on the gap between attach state and the contract. Both gaps are typically real, and they often cancel each other in the defended response.2
Satellite and Subscription Watch intermediation.
Customers running Red Hat Satellite have a layer of intermediation between subscription-manager on the host and Red Hat's central view. Satellite manages the subscription attach for systems registered to it; the Satellite database is itself an evidence source. The audit team that asks for subscription-manager output across an estate without acknowledging Satellite's role is asking for evidence that reflects Satellite's attach decisions rather than direct customer choices. The defended response produces Satellite's view alongside the host level subscription-manager output and explains the relationship.
Subscription Watch on console.redhat.com adds another layer, particularly for OpenShift workloads and for hybrid cloud deployments. The companion notes on Red Hat Insights inventory what to trust and Subscription Watch versus own data treat the source comparison; for subscription-manager output specifically, the host level view is the most carefully scoped evidence the customer typically produces. The parent practice note on RHEL licensing treats the product side that the subscription-manager output feeds into.
Format of the defended production.
The defended subscription-manager production is a structured CSV or JSON aggregation across the in scope hosts, with one row per host and columns for the subcommand outputs the contract requires. The aggregation is accompanied by a memorandum that explains the host selection (which hosts are in scope and why), the subcommand selection (which fields are included and why), and the entitlement mapping (how the attach state maps back to the contract).
Registration tokens, subscription pool identifiers that reveal pricing structure, and customer account identifiers are withheld from the production. Those fields are credentials or commercial information and are not relevant to the entitlement question. The audit team's request for those fields must be addressed on the merits; the defended response typically does not produce them. The companion note on audit document preservation protocol treats the disclosure mechanics that govern all productions.
RHEL on cloud marketplaces and subscription-manager.
RHEL workloads acquired through cloud marketplace mechanics (AWS, Azure, Google Cloud) frequently register against the cloud provider's intermediated subscription pool rather than against a customer owned pool. The subscription-manager output on those workloads looks different from on a workload registered against a customer Red Hat account; the entitlement obligation also flows through the cloud provider. The cross link into Lane 10 on RHEL on AWS marketplace economics treats the pricing side; the audit application is that marketplace registered workloads sit outside the customer's direct subscription pool.
How the practice approaches subscription-manager evidence.
The practice begins subscription-manager evidence engagement by establishing the contract side, the in scope host list, and the relevant Satellite or Subscription Watch intermediation. The defended production is then assembled as a structured aggregation with the accompanying memorandum that maps attach state back to contractual entitlement. The audit team's finding on attach gaps is met with the contract; the contract's excess where it exists offsets the attach gaps where they exist.
Across audits where subscription-manager output was the primary evidence in the practice's trailing twelve months, defenses that produced the structured aggregation with the contractual mapping settled at materially lower percentages of the initial Red Hat finding than defenses that produced raw subscription-manager dumps. If the audit notice asks for subscription-manager output, the first useful hour is a call with the desk. The companion notes on vCenter host inventory, KVM and Proxmox evidence, and audit clause anatomy treat parallel pieces of the evidence picture.
Notes & references
- 1. Tool versus contract. subscription-manager reflects attach state; the contract reflects entitlement. The two diverge, and the divergence is where the audit defense lives.
- 2. Bilateral gaps. Audit findings rest on attach gaps versus workload counts; defenses rest on attach gaps versus contractual entitlements. Both gaps are typically real.
- 3. Satellite intermediation. Satellite managed estates produce subscription-manager output that reflects Satellite's attach decisions; produce the Satellite view alongside.
- 4. Withhold tokens. Registration tokens and account identifiers are credentials, not evidence; withhold from production unless the audit clause specifically requires.
- 5. Cloud marketplace. Marketplace registered workloads sit outside the customer's direct subscription pool; their subscription-manager output reflects intermediated entitlement.
Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.