Omnissa Horizon 8.2206 EOL July 2025: Action Plan

The Clock Is Ticking on Omnissa Horizon 8.2206

Omnissa Horizon 8.2206 — the latest non-LTS release in the 8.x line — will reach end of life (EOL) on July 19, 2025. That is roughly 90 days from today. After that date, Omnissa will stop providing patch releases, security fixes, technical support, and any vendor SLA for this version. If your estate relies on 8.2206, you are facing a hard cut-off.

Important context: 8.2206 is not an LTS release. Upgrading to supported Horizon 8 versions (such as the most recent LTS release, if your environment qualifies) is typically the vendor's recommended path. For most organizations, a full migration to a newer Horizon release before July 19 is no longer realistic — the planning, testing, and roll-out window is simply too tight.

This article outlines what you can achieve in the next three months, and what to do on day one after EOL to keep your environment secure and compliant.

What Changes on July 19, 2025

On the EOL date, the following vendor support ends for Horizon 8.2206:

• No more security patches. Omnissa will not release hotfixes or cumulative updates for newly discovered vulnerabilities.
• No more bug fixes. Neither critical nor routine defects will be addressed by the vendor.
• No vendor technical support. You will no longer be able to open support tickets with Omnissa for 8.2206.
• No vendor SLA guarantees. Any service-level commitments for response or resolution times end.
• No new feature updates. Obviously production feature updates ended at release, but upstream dependent components (e.g., Horizon Agent, Connection Server components) may also fall out of support without vendor alignment.

Your Horizon environment will continue to function, but it becomes an unsupported, unpatched asset. For compliance frameworks (PCI DSS, SOC 2, HIPAA, ISO 27001) this triggers control failures unless you compensate with documented mitigation.

Week-by-Week Action Checklist (12 Weeks to Go)

Below is a practical week-by-week plan. Adjust timing based on your estate size, but the sequence is important.

Weeks 1–2: Inventory and Assessment

• Create a complete inventory of all Horizon 8.2206 components: Connection Servers, Security Servers, Unified Access Gateways, Horizon Agents on RDSH or VDI desktops, and any related management servers.
• Verify version numbers against the Omnissa lifecycle matrix to confirm which are 8.2206.
• Assess dependencies: Which third-party integrations (load balancers, certificates, monitoring tools) are specifically tested against 8.2206? Note any that auto-update or become incompatible after EOL.
• Identify critical vs. non-critical workloads. Prioritize business-essential applications that run on Horizon 8.2206.

Deliverable: A spreadsheet or CMDB report listing every Horizon 8.2206 asset, its location, and its dependency chain.

Weeks 3–4: Isolate and Harden

• Apply any remaining Omnissa patches that are available before July 19. Check the Omnissa lifecycle page for current patch levels.
• Harden configurations: Remove unnecessary services, enforce TLS 1.2 or 1.3, rotate certificates, restrict administrative access, and audit firewall rules.
• Isolate older Horizon environments from the internet where possible. Use network segmentation, VPNs, or DMZs to reduce the attack surface.
• Update backup and disaster recovery procedures specifically for unsupported environments. Ensure standby nodes can be promoted without vendor help.

Deliverable: A hardened, patched configuration baseline for all Horizon 8.2206 assets.

Weeks 5–6: Document for Auditors and Insurers

• Write a risk acceptance memo signed by relevant governance (CISO, compliance officer, business owner). The memo should state:
  • Why 8.2206 is being kept past EOL (e.g., migration timeline constraints, workload criticality).
  • Compensating controls in place (network isolation, restricted access, enhanced monitoring).
  • Planned end date for the unsupported deployment (e.g., target full migration by [month/year]).
• Update your security compliance posture to reflect the unsupported status. If you operate under PCI DSS v3.2.1 or v4.0, ensure compensating controls are documented and testable.
• Notify your cyber insurance carrier if your policy requires reporting of unsupported software. Some policies exclude coverage for breaches involving unpatched, EOL products.

Deliverable: Signed risk acceptance memo, compliance artifact updates, and insurance stakeholder notification.

Weeks 7–8: Evaluate Third-Party Support Options

• Research third-party maintenance providers that support Omnissa Horizon beyond the vendor's EOL date. Reputable providers can deliver:
  • Critical security patches and backports.
  • Technical support for break/fix issues.
  • Custom SLAs aligned to your business needs (e.g., 4-hour response).
• Compare scope: Do they cover the entire Horizon stack (Connection Server, Agents, Security Server) or just the hypervisor layer?
• Request quotes and contract terms — aim for a minimum 12-month agreement to cover your migration window.

Deliverable: At least one third-party support proposal ready for procurement approval.

Weeks 9–10: Execute Support Contract (or Finalize Contingency)

• If you choose third-party support: Finalize the contract before July 19. Ensure the start date is July 19 or July 20 to avoid a coverage gap.
• If you choose not to engage third-party support: Document the decision rationale. Prepare an offline recovery plan — full images of all Horizon components, offline cold backup copies, and independent security control validation.

Deliverable: Signed third-party support agreement or an approved risk-acceptance-without-support plan.

Weeks 11–12: Final Testing and Cutover Preparation

• Test the third-party support channel — open a test ticket (non-production urgency) to verify response process.
• Run a full DR drill that includes recovering an unsupported Horizon environment from backup.
• Update runbooks with post-EOL procedures, including contact numbers for your third-party support vendor.
• Communicate final EOL status to all relevant teams: help desk, NOC, security, and business application owners. Set expectations that no vendor-fresh fixes will arrive.

Deliverable: Verified support channel, updated runbooks, and a communicated cutover plan.

Why Third-Party Support Makes Sense Now

For estates that cannot complete a full migration before July 19, third-party maintenance fills the security and compliance gap. Providers like 3rd Party Support can deliver:

• Critical patches backported to 8.2206 if a vulnerability is discovered after EOL.
• Technical assistance with break-fix issues, log analysis, and configuration guidance.
• SLAs that match your business hours — often better than the original vendor's standard terms for unsupported products.

This lets you focus on the actual migration without rushing a corner-cutting upgrade that introduces risk.

What Not to Do

• Do not treat this as optional. Running a non-LTS release past its EOL without compensating controls is an audit finding waiting to happen.
• Do not wait until July 18. Procurement cycles for third-party support take 2–4 weeks. Start now.
• Do not assume “it works today, so it will work tomorrow.” Vulnerability disclosures for Horizon are common. Without patch support, each new CVE carries unknown downtime risk.

Next Steps

• Inventory your Horizon 8.2206 estate today. Use the checklist above.
• Contact a third-party support provider to discuss coverage for your specific components. Get a proposal in hand before month end.
• Communicate the risk up — share the EOL date with your security and compliance leads now, not after July 19.

Need help evaluating your options? Contact 3rd Party Support for a no-obligation assessment of how third-party maintenance can keep your Horizon 8.2206 environment stable and secure through your migration timeline.