Ubuntu 25.10 EOL July 1, 2026 – Action Plan

With Ubuntu 25.10 'Questing Quokka' reaching end of life on July 1, 2026, you have roughly three months left before Canonical stops providing any patches, fixes, or support. This isn't an LTS release, so there is no extended security maintenance window. If a full migration to a supported release is no longer feasible in that timeframe, your focus must shift to containment, hardening, documentation, and securing post-EOL support. Below is a concrete action plan designed for IT leaders who need to manage risk without panic.

What Changes on July 1, 2026

When a non-LTS Ubuntu release reaches end of life, three things happen simultaneously:

• No more security patches – Canonical stops publishing updates for any vulnerabilities discovered after the EOL date, including critical and zero-day flaws.
• No more bug fixes – Kernel, driver, and application bugs remain unpatched.
• No vendor SLAs – Canonical’s support team will not accept tickets or provide assistance for 25.10 systems.

After July 1, any system still running Questing Quokka will accumulate unpatched vulnerabilities. This creates compliance gaps (PCI DSS, SOC 2, ISO 27001), increases cyber-insurance scrutiny, and exposes the organisation to exploit risk.

Why a Full Migration May Not Be Realistic

A planned migration from 25.10 to a supported release (such as the current LTS) typically takes several months of testing, application validation, and cutover scheduling. With only three months left, attempting a full estate-wide migration often leads to rushed testing, unplanned downtime, or partially migrated systems that become harder to manage. For environments with many specialised workloads or compliance constraints, a safer interim strategy is to isolate and protect the remaining systems while committing to a slower, controlled migration later.

The Last-Three-Months Action Checklist

Use the following week-by-week plan to reduce exposure and prepare for day one after EOL. Adjust timelines based on your estate size and complexity.

Weeks 1–2: Complete Inventory and Categorisation

• Scan your entire network for any host running Ubuntu 25.10 (check os-release, /etc/lsb-release, or inventory tools).
• Categorise each system by function: production, development, test, or internal tool.
• Determine which systems can be upgraded or decommissioned in the remaining eight weeks, and which must remain on 25.10 for operational reasons (e.g., vendor lock, incompatible software).
• Flag all systems that cannot be migrated before July 1. These become your high-risk candidates for isolation.

Weeks 3–4: Isolation and Network Segmentation

• Move non-migratable 25.10 systems into a segregated VLAN with strict firewall rules blocking inbound traffic from the internet and from less-trusted internal zones.
• Disable any unnecessary services (SSH from outside, exposed APIs, unused ports) on these systems.
• Verify that critical application dependencies still work after isolation – test connectivity to databases, authentication servers, and monitoring tools.
• Limit administrative access to a small, audited set of jump-box credentials.

Weeks 5–6: Hardening and Configuration Lockdown

• Apply all remaining Canonical patches before the July 1 deadline. Use apt update && apt upgrade to get every available fix.
• Review and tighten system configurations: disable root login over SSH, enforce key-based authentication, enable auditd logging, and remove unused packages.
• Implement runtime protections such as AppArmor profiles, SELinux (if applicable), or filesystem integrity monitoring via AIDE or Tripwire.
• Set up local logging and centralised aggregation (e.g., syslog to a SIEM) so you can detect anomalous activity after patches stop.

Weeks 7–8: Documentation and Audit Preparation

• Create a formal risk register listing every 25.10 system, its function, mitigating controls, and the reason it cannot be upgraded. Include the fact that it will be unsupported after July 1.
• Update your internal compliance documentation – flag these systems to auditors and your cyber-insurance carrier. Many policies require a documented plan for end-of-life software.
• Attach a remediation timeline for each system (e.g., “migration to Ubuntu 24.04 LTS planned in Q4 2026”).
• Brief your incident response team that these systems may require additional monitoring and that no vendor patches will be available for any discovered vulnerabilities.

Weeks 9–10: Secure a Post-EOL Support Contract

• Contact a third-party maintenance provider that specialises in extended support for end-of-life Ubuntu releases. A third-party support contract ensures you receive critical security patches and technical assistance after the vendor’s official support ends.
• Negotiate a support agreement that covers the 25.10 systems you intend to keep running for the next 6–12 months. This buys you time to complete a safe, planned migration.
• Verify that the provider’s patching process includes backported fixes for known CVEs and can integrate with your existing update workflows.

Weeks 11–12: Final Validation and Go-Live for Support

• Test the third-party patching mechanism on a non-production 25.10 system to ensure compatibility.
• Set up monitoring alerts for any new critical vulnerabilities that affect the unsupported kernel or libraries.
• Communicate the final state to operations, security, and procurement teams. Confirm that the third-party support contract is in place and that internal isolation controls are active.
• After July 1, treat all 25.10 systems as exception devices – review their continued need every quarter and enforce a strict decommission or upgrade plan.

Documenting Exposure for Auditors and Insurers

After July 1, any 25.10 system is effectively running unsupported software. Auditors will expect:

• A complete inventory of unsupported systems.
• A business justification for each one.
• Evidence of compensating controls (isolation, hardening, restricted access).
• A realistic upgrade timeline.
• A signed support contract that covers patching after the vendor’s EOL.

Providing this proactively demonstrates due diligence and reduces the likelihood of compliance findings or coverage gaps.

The Role of Third-Party Support

Canonical’s support stops on July 1, but third-party maintenance providers can fill the gap. They produce independent security patches and offer technical assistance for Ubuntu 25.10 without forcing a migration. This is not a licence to defer upgrades indefinitely – it is a safety net that allows you to decommission unsupported systems on your own schedule, not the vendor’s. Contact our team to discuss how we can support your post-EOL Ubuntu estate.

Summary

You cannot stop the EOL clock, but you can prepare for it. Use the next three months to identify every Ubuntu 25.10 host, isolate and harden the ones that must stay, document your risk position, and line up a support contract that covers day one after July 1. By following this checklist, you turn a looming deadline into a controlled, manageable transition.