A regulated-finance infrastructure team runs its Enterprise Linux upgrade calendar on its own schedule, inside a segment where policy blocks inbound and outbound traffic. Blocking that traffic does not remove the work. A package still needs a pin, a version still needs a test, and a release still needs to be promoted on the date the team sets. CIQ Enterprise Linux Manager (ELM) runs that entire cycle on infrastructure the team already operates, whether or not the segment has a route out. Federal, defense, and regulated-finance infrastructure leads decide what enters the fleet, when it moves, and what it costs, on every release.
Keep every lifecycle decision inside your own perimeter
That call belongs to the team that runs the fleet, not to a vendor service checking in on it. ELM mirrors the repositories a subscription entitles a team to, builds content views from that mirror, and stages each view through development, test, and production, all on infrastructure the team already owns. A team running ELM controls what enters its fleet, how fast each stage advances, and what the subscription underneath it costs.
Cadence follows the same rule. A team on a strict network policy still sets its own upgrade window, tests a release against its own criteria, and promotes on the date its change process approves, rather than on a schedule a vendor service drives. The fleet a team spends on stays the fleet it actually runs, sized to the segment, not to a subscription tier the segment does not need.
Entitlement resolves at the mirror, not at the host. A connected segment authenticates the mirror against Depot, the CIQ service a subscription checks in against, on whatever schedule the team sets. A disconnected segment imports the same signed content from an ISO image instead, with entitlement already resolved before the content ever leaves a connected system. Either way, hosts install from the mirror the team runs. No per-system check calls out during a rollout, and no subscription-enforcement service runs anywhere in the sequence.
Sign every content view without exporting the key
Content stays where the team put it. Mirrors sync onto storage the team owns, and content views assemble from a hard-link content store, so a new view points at package files already on disk instead of copying them across the segment. Curation and signing happen in the same step: an operator builds a view, and ELM signs it the moment it publishes.
Where does the content signing key live? ELM regenerates and signs content-view metadata at curation, and the CIQ signing key never resides on a customer system. A rollout that reaches RLC Pro hosts carries a signature the team can trace to a specific curation event, not to a key sitting on infrastructure someone else administers.
For federal, defense, and regulated-finance teams
Own the cost, the cadence, and the entitlement for your own estate
Go fully air-gapped when your environment calls for it
Mirroring, curation, dependency resolution, promotion, and rollback all run on infrastructure the team operates, and none of it depends on a route to the internet. A segment with no such route imports content from an ISO image, curates and promotes it exactly as a connected team does, and rolls back to a prior published version the same way. A team decides whether its environment runs connected or air-gapped. ELM runs the same lifecycle either way.
Signed content moves between a connected instance and a disconnected one by offline import and export, so a disconnected segment stays current without ever opening a route to the internet. ELM exports compliance posture against OpenSCAP, STIG, and CIS profiles, tracks which content view version every host in the segment runs, and pairs both with a full audit log of content and lifecycle actions. An auditor reviewing a disconnected segment gets the same evidence an auditor reviewing a connected one gets: what each host runs, when it changed, and who approved it. Teams with cryptographic requirements beyond that pair ELM with RLC Pro Hardened, which ships FIPS 140-3 validated cryptography and STIG-ready configuration.
Offline import and export cover a disconnected segment, one boundary with no route to the internet. Serving live content to many connected remote sites at once is a separate problem from the one this capability solves, and it sits outside this post's scope.
Run the same weekly cycle in a disconnected segment
In a representative deployment, a regulated-finance infrastructure team curates a content view behind a network boundary with no outbound route. The team resolves a dependency conflict before it reaches a host, promotes the view into production on its own schedule, then rolls it back once, mid-cycle, to confirm the path works before an incident forces the question. Federal, defense, and regulated-finance teams run that cycle every week inside a disconnected segment, with the same content views, the same promotion stages, and the same rollback path a connected team runs.
The infrastructure team that owns the segment also owns the decision to run it disconnected. Nothing about that decision changes what ELM does. It changes where the mirror pulls from and how content crosses the boundary. Curation, promotion, and rollback run exactly as they do on a connected instance.
