Red Hat subscription compliance in 2026. How RHEL and OpenShift are counted.

Red Hat compliance is a count of running systems against active subscriptions at the right tier. Simple Content Access no longer stops unentitled systems, so you have to find the gaps before Red Hat does.

What does Red Hat subscription compliance mean?

Red Hat subscription compliance means every running system maps to an active subscription at the right support tier. Red Hat sells access to updates and support, so the question is never how many licenses you bought. It is whether every live instance is entitled.

The Red Hat subscription agreement ties each subscription to a unit of capacity, and the product appendix defines that unit. Read both before a renewal. The counting unit decides your exposure far more than the headline discount does.

• Entitled. A running instance with an active subscription at the right tier.
• Gap. Any instance consuming updates or support without one.
• Evidence. The registered systems in your Red Hat account, cross checked against the subscriptions service and your own inventory.

A Red Hat review compares that live picture with your entitlements, then prices the difference. Your aim is to produce that comparison first.

How does the Red Hat subscription model work?

Red Hat sells term subscriptions, not perpetual licenses. A subscription is a right to updates, security patches and support for one unit of capacity for the term. When it lapses, the right to content stops, although the software keeps running.

The unit of capacity is the number that matters. For RHEL Server it is a socket pair, defined in the Red Hat subscription guide as up to two populated sockets on one system. OpenShift uses a core pair instead, covered further down.

Which support tier does each workload need?

Support tier is the second axis, and it is a compliance question as much as a service level. A Self support subscription applied to a production workload that needs Standard or Premium is a mismatch a review will flag and reprice.

Match the tier to the workload before renewal, because tier mix drives both over spend and under spend. Production usually needs Standard or Premium. Lab and build systems can sit on Self support or a developer subscription used within its terms. The targets below are the initial response times Red Hat publishes for production support.

How did Simple Content Access change Red Hat compliance?

Simple Content Access moved compliance from the platform to the contract. Any registered system can now pull updates whether or not a matching subscription exists, so the technical stop that used to enforce entitlement is gone.

• Before 2021. A system had to attach a specific subscription to receive content, which gave a hard technical block.
• July 15, 2022. Simple Content Access became the default for new Red Hat accounts.
• April 2024. Enabling it became a one way conversion that cannot be switched off.
• November 2024. Red Hat had moved nearly all remaining accounts to this mode, according to its Simple Content Access guidance.

The auto attach command is now obsolete, and a registered host reports that it has access to content regardless of subscription status.

An update that installs without error says nothing about entitlement. Track consumption on purpose, through the subscriptions service and your own records, because the operating system will not do it for you.

How is RHEL counted on physical, virtual and cloud systems?

RHEL is counted by socket pair on physical hardware, by pairs of virtual nodes for guests, and by host socket pair under Virtual Datacenters. The deployment model decides which rule applies, and picking the wrong rule is how buyers end up paying too much or carrying an unpriced gap.

Why physical counting favors the buyer

A RHEL socket pair covers up to two populated sockets regardless of core density. A modern two socket server with a very high core count still needs a single subscription. Buyers who assume a per core model routinely over buy on physical hardware.

Stacking handles larger boxes. An eight socket server needs four subscriptions, counted as four socket pairs, and a four socket server needs two. Only populated sockets count, so a four socket board with two CPUs fitted needs one subscription.

Why virtual environments carry the most risk

A guest subscription covers two virtual nodes regardless of virtual sockets, and it follows the guest. A Virtual Datacenters subscription instead covers unlimited RHEL guests on one host, priced per host socket pair, and it covers that host only.

When a scheduler such as VMware DRS migrates a guest from a covered host to an uncovered one, that guest becomes a gap. Cluster membership and live migration rules decide how many hosts you must license.

When does Virtual Datacenters pay off?

Virtual Datacenters wins when RHEL guest density per host is high. It runs on supported hypervisors including VMware, Microsoft Hyper-V and Red Hat Virtualization. On the Red Hat store prices we checked in September 2026, one Virtual Datacenters subscription cost about 3.4 times a RHEL Server subscription at the same tier.

A guest subscription covers two guests, so the break even sits near 7 RHEL guests per two socket host. Past that, host coverage is cheaper. Below it, count guests one by one. Rerun the ratio with your own quote, because discounts often differ between the two products.

The third row shows why affinity rules matter. If RHEL guests can only run on two hosts, you only need to cover two hosts, provided the rule is enforced and documented. Without it, every host a guest can reach is in scope.

How are RHEL instances counted in public cloud?

Red Hat's guide counts public cloud instances like virtual nodes, so divide the instance count by 2 to get RHEL Server subscriptions. Bringing your own subscriptions to a certified cloud provider runs through Red Hat Cloud Access.

Pay as you go images bought through a cloud marketplace carry the subscription in the hourly price. They should not draw on the subscriptions you bought, so tag them and exclude them from your count.

How is OpenShift subscription usage counted?

Self managed OpenShift counts a core pair, defined as two physical cores or four vCPUs, per the self managed OpenShift subscription guide. You count the cores across every compute node that runs your applications, and divide by two, or divide vCPUs by four.

Which OpenShift nodes need subscriptions?

• Compute nodes. Always counted, on every cluster.
• Control plane nodes. Included and not counted, as long as no user workloads run on them.
• Infrastructure nodes. Included on the same condition, so keep router, registry and monitoring there and keep application pods off.
• Compact three node clusters. Applications run on the control plane nodes, so all cores on the three nodes count.
• Disaster recovery clusters. Hot DR clusters need paid subscriptions. Warm and cold sites take subscriptions transferred from the primary site when they are activated.

On bare metal, physical cores count regardless of hyperthreading, so two physical cores that present as four vCPUs are still one core pair. On hyperscalers and hypervisors, four vCPUs equal one core pair.

Red Hat also sells a bare metal node subscription that covers one physical server regardless of sockets or cores, and it is the only option for OpenShift Virtualization Engine.

How do you size OpenShift without buying for idle capacity?

Size worker nodes to the cores your workloads are actually scheduled to use, then license those nodes. Red Hat counts compute node capacity, so every vCPU you hand a worker node is billable whether pods use it or not. Buying for the whole cluster's allocated capacity is the most common cause of OpenShift over buying we see.

The last row is the one to police. Application pods on the infrastructure nodes put their 24 vCPUs in scope, which here adds 6 subscriptions. Node selectors and taints keep application pods off infra nodes, and the cluster configuration is your evidence.

Where do Red Hat compliance gaps usually hide?

Gaps hide in predictable places, and finding them before a review is the difference between a planned renewal and a backdated true up. Most come from drift.

• Migration debt. CentOS systems converted to RHEL with no new subscription. CentOS Linux 7 reached end of life on June 30, 2024, so check every system converted around that date.
• Standby nodes. Disaster recovery systems that were set up as warm or cold but now replicate production data.
• Tier mismatch. Self support subscriptions running production workloads.
• Developer use. The no cost Developer Subscription for Individuals covers up to 16 systems for personal use only, so any corporate use of it is a gap.
• Cloned images. Entitled images copied onto uncovered capacity, including cloud instances launched from a golden image.

Each pattern has the same root cause. A system keeps consuming updates after the assumption behind its entitlement stopped being true. The subscriptions service will show the running system, but it will not tell you the assumption broke.

Which non compliance patterns show up most often?

Five patterns account for most of what we flag, and virtualization sprawl leads by a wide margin. The table ranks them by how often they surface in review preparation, not by dollar size.

Where does disaster recovery stop needing a subscription?

Red Hat's guides draw the line at replication. A hot DR system runs alongside production and replicates data, so it needs paid subscriptions. Warm and cold DR systems do not replicate, and subscriptions can be transferred to them from the primary site when a disaster occurs.

Get your DR design confirmed in writing, because a warm site that starts replicating becomes hot.

What have we seen in recent Red Hat compliance reviews?

Across roughly 30 Red Hat environments we reviewed in 2024 and 2025, the result was consistent. A median of 22 percent of running instances carried no matching subscription, and virtualization sprawl explained most of it.

• Sprawl first. RHEL guests spread across hosts that were never covered, well ahead of every other cause.
• Conversions and standby next. Converted CentOS systems and standby nodes were the next most frequent sources, far behind sprawl.
• Little deliberate under buying. Most of the companies paid Red Hat in good faith and still carried gaps, because Simple Content Access stopped drawing the line for them.

We are 100 percent independent of Red Hat and IBM. We resell nothing and take no referral fees, so our count of your position has no reason to lean either way.

How do you run a Red Hat self audit?

Run a self audit every quarter as a routine. The goal is a reconciliation you control, built from your own data before anyone asks for it.

1. Pull subscriptions. Export active subscriptions, quantities and tiers from the subscriptions service or the Customer Portal.
2. Inventory instances. List every running instance across physical, virtual, cloud and container platforms.
3. Map hypervisors. Run virt who so guest to host relationships are visible and current.
4. Match and tier. Tie each instance to a subscription at the correct support tier.
5. Flag exceptions. Mark standby nodes, clones, developer use and converted CentOS hosts.
6. Right size OpenShift. Count compute node cores sized to scheduled demand, and confirm nothing runs on control plane or infra nodes.

Red Hat positions the subscriptions service as an account wide reporting tool for self governance. Treat it as your primary source, then reconcile it against your configuration management database.

Which Red Hat tools show your real position?

The subscriptions service in the Hybrid Cloud Console shows usage against the capacity of your subscriptions, per product, as a daily snapshot with history. Its accuracy depends entirely on what feeds it.

• Red Hat Insights client. The feed Red Hat recommends for always connected RHEL systems.
• Red Hat Satellite. The feed for disconnected or tightly controlled sites, and the place to check which hosts report.
• virt who. Reports guest to host mapping, which Virtual Datacenters counting depends on.
• System purpose attributes. Set role, service level and usage per system so tier and production status are recorded.
• OpenShift Cluster Manager. Receives cluster telemetry for OpenShift 4 and shows the cores Red Hat sees.

Check the "last seen" date in the current instances list. Decommissioned systems that still appear inflate your count, and live systems that never report hide gaps.

Red Hat removed the technical stop, not the obligation. Simple Content Access turned compliance into bookkeeping, and the renewal is where that bookkeeping gets tested.

Feed the result straight into renewal planning. A reconciliation built from your own inventory is stronger evidence than a portal export handed over unexamined, and it keeps the scoping conversation on your terms.

How do you close a Red Hat compliance gap without over buying?

Close each gap with the cheapest compliant unit of count, and do not accept the first proposal as the answer. Most gaps cost far less than the opening figure once the counting unit is corrected.

Why we do not simply buy Red Hat's gap number

The usual advice is to take the vendor's gap number, buy the matching subscriptions and close the file. We disagree. That pays for the counting unit Red Hat proposed rather than the one your deployment requires, and it carries the overcount into your renewal baseline for years.

Rebuild the count from your own inventory first. Decide the cheapest compliant unit for each workload, then respond. Once socket pairs, guest density and compute node sizing are counted properly, the gap number and the correct purchase are rarely the same figure.

What will the Red Hat account team say, and how should you answer?

• "Please share your subscriptions service data so we can size the renewal." Share your reconciliation instead of a raw export. Red Hat's documentation says it does not intend to create billing events from that tooling, so ask that sizing follow the same principle.
• "Every host in the cluster needs Virtual Datacenters coverage." Only hosts where RHEL guests can run are in scope. Show the affinity rules and the virt who mapping.
• "OpenShift is counted on all cluster cores." Point to the subscription guide: control plane and infrastructure nodes without user workloads are excluded.
• "Your DR site needs full subscriptions." Only hot DR does. Walk through the replication design against Red Hat's warm and cold definitions.
• "Move everything to Premium to be safe." Tier by workload. Premium on a build server pays for a 24x7 response that no one on the build team will use.

Which Red Hat contract terms matter in a compliance review?

The Red Hat Enterprise Agreement sets the rules for any review, and the US version on Red Hat's site is dated November 9, 2021. Four clauses matter most, and each can be clarified in your order form or a negotiated amendment.

• Reporting excess use (section 3.2). If you deploy more units than you paid for, you must promptly report the additional units and the dates they were deployed. Ask that additional units are priced at your current discount for the rest of the term.
• Review rights (section 10). Red Hat may inspect your facilities and records during the agreement and for one year after it ends, with at least 10 days written notice for on site visits. Ask for the same notice for any records request, and a limit of one review in 12 months.
• Resolution window and costs. You must resolve a notified underpayment within 15 days, and you reimburse Red Hat's review costs if the underpayment exceeds 5 percent. Ask for a longer window that fits your purchasing cycle.
• Automatic renewal (section 2.2). Subscriptions renew for the same term unless either side gives written notice at least 30 days before expiry. Put that date in the contract calendar.

Also ask Red Hat to confirm in writing how it treats your DR design, any developer use, and any affinity rules you rely on to limit Virtual Datacenters scope. A written answer at signature is worth more than a debate during a review.

How do you stay Red Hat compliant before a renewal?

Make the reconciliation a quarterly habit. Virtual platforms change weekly and Simple Content Access hides the drift, so a yearly check misses it. A quarterly reconciliation catches a gap while it is still small.

For audit response in detail, see the IBM Red Hat audit defense guide. For what a review notice looks like and how to reply, read Red Hat audit triggers and response. For the commercial side of the renewal, see RHEL negotiation and our guide to developer subscriptions in the enterprise.

What to do next

1. This week. Export current subscriptions and tiers from the Red Hat subscriptions service, and check the "last seen" dates for stale systems.
2. This month. Get Insights, Satellite and virt who reporting from every cluster, so the inventory covers physical, virtual, cloud and container platforms.
3. This quarter. Match each running instance to a subscription and a support tier, and flag standby nodes, clones, developer subscriptions and converted CentOS systems.
4. For OpenShift. Right size worker nodes to scheduled demand and taint control plane and infra nodes so application pods stay off them.
5. With Red Hat. Ask for written confirmation of your DR categories, developer use and any affinity rules that limit Virtual Datacenters scope.
6. Every quarter after. Repeat the reconciliation, feed it into renewal planning, and diary the 30 day non renewal notice date.

Frequently asked questions