Python 3.10 End of Life (October 2026): Security and Migration Guide

Python 3.10 reaches end of life on October 31, 2026. After that date, the Python Software Foundation will no longer release security patches, bug fixes, or source-only updates for the 3.10 branch. If you run Python 3.10 in production today, you have roughly seven months to plan your next move.

This is not a distant planning exercise. Python 3.9 already hit EOL in October 2025, and teams that delayed their migration from 3.8 (EOL October 2024) are still catching up. Python 3.10 is the next domino, and the ripple effects extend far beyond CPython itself: libraries are dropping 3.10 from their test matrices, cloud providers are deprecating 3.10 runtimes, and compliance frameworks (including the EU Cyber Resilience Act, which mandates timely vulnerability handling for products with digital elements) increasingly flag EOL language runtimes as audit findings.

Python 3.10 was a significant release. It introduced structural pattern matching (match/case statements), improved error messages with precise line-of-code indicators, and ParamSpec for better typing support. These features created a natural adoption floor: code written specifically for 3.10+ cannot easily be backported to 3.9, making the transition feel one-directional. That adoption is exactly why so many production systems still run 3.10 today.

Here is what you need to know and what you need to do before the deadline. (For a complete list of every Python version's support status, see our Python end-of-life dates and support timeline.)

‍

What Changes When Python 3.10 Goes EOL

Python follows a predictable five-year support lifecycle. For versions before 3.13, each release gets roughly 18 months of active bug fixes, followed by three and a half years of security-only patches. (Starting with Python 3.13, the bug-fix phase was extended to two full years.) Python 3.10 was first released in October 2021, entered its security-only phase in April 2023, and will reach full end of life on October 31, 2026.

After that date, three things stop happening:

The PSF stops publishing security patches. Any new CVE discovered in CPython 3.10 will go unpatched upstream. In 2025 alone, Python had 12 published security vulnerabilities, including issues in urllib.parse, http.client, and xml.dom.minidom with CVSS scores reaching 9.1. These kinds of issues will continue to surface after EOL, but fixes will only land in supported branches (3.11+).

No more source releases are published. During the security-only phase, the PSF still releases source tarballs for critical fixes. After EOL, even those stop. You cannot build a patched 3.10 from an official source.

The upstream community moves on. CI pipelines, testing infrastructure, and contributor attention shift to actively supported versions. Bug reports filed against 3.10 will be closed as "won't fix."

‍

The Library Ecosystem Is Already Moving

CPython reaching EOL is only half the story. The Python package ecosystem sets its own deprecation schedules, and many major libraries are already dropping Python 3.10 support ahead of the October deadline.

The Scientific Python community's SPEC 0 policy recommends dropping support for Python versions three years after their initial release. Since Python 3.10 was released in October 2021, SPEC 0 allowed projects to drop 3.10 as early as October 2024. Libraries that follow SPEC 0 (including NumPy, SciPy, Matplotlib, scikit-learn, pandas, and IPython) are progressively removing 3.10 from their supported version matrices.

This means that even before Python 3.10 reaches EOL, you may already be unable to receive security updates for critical dependencies if they have dropped 3.10 support. The practical effect: your exposure window is wider than CPython's EOL date alone suggests.

Django follows a similar pattern. Django 5.2 LTS (released April 2025, supported through April 2028) supports Python 3.10, but future Django releases are expected to require Python 3.12 or later. If you are running Django on Python 3.10, your upgrade ceiling is Django 5.2, and you will eventually need to move both your Python version and your Django version forward together.

‍

The Distribution Support Nuance Most Teams Miss

Here is where things get complicated, and where most Python EOL guides fall short. The CPython upstream EOL date does not tell the full story if you deploy on Linux distributions with their own support timelines.

Ubuntu 22.04 LTS and Python 3.10

Ubuntu 22.04 LTS ships Python 3.10 as its default system interpreter. Standard Ubuntu support for 22.04 runs through April 2027, which means Canonical will continue to backport security patches to Python 3.10 on Ubuntu 22.04 for approximately six months after upstream EOL.

With Ubuntu Pro (free for up to five machines for personal use), that coverage extends through April 2032. Canonical's ESM (Expanded Security Maintenance) patches critical and important CVEs for Python 3.10 on Ubuntu 22.04 even after the PSF stops issuing updates.

The catch: this coverage applies to the CPython interpreter package only. It does not extend to PyPI packages, frameworks, or any third-party libraries you install via pip. Your Django, Flask, requests, or cryptography packages still follow their own upstream support schedules, which are governed by the library maintainers, not by Canonical.

RHEL 9 and Python 3.9

Red Hat Enterprise Linux 9 ships Python 3.9 as its default interpreter and provides backported security patches through RHEL 9's full lifecycle (approximately May 2032). This creates a gap: Python 3.9 is already EOL upstream, but RHEL 9 users continue to receive Red Hat-maintained patches for critical CVEs (typically CVSS 7.0+). However, Red Hat's coverage is selective: lower-severity issues and bugs outside Red Hat's triage threshold may go unpatched.

If you are on RHEL 9 and considering a move to Python 3.10, be aware that 3.10 is available as an Application Stream but does not receive the same level of Red Hat backport coverage as the default 3.9 interpreter.

Amazon Linux 2023

Amazon Linux 2023 ships Python 3.9 as the default, with support planned through March 2028. Python 3.10 is not the default and does not receive the same lifecycle guarantees. If you run Python 3.10 on AL2023 via a manual installation or alternate package, you are relying on upstream support, which ends in October 2026.

Debian 12 (Bookworm)

Debian 12 ships Python 3.11 as the default interpreter, with security support through approximately June 2028. If you are on Debian 12, the Python 3.10 EOL does not directly affect your system interpreter, but any locally installed 3.10 environments or containers based on 3.10 are still subject to the upstream deadline.

Alpine and Minimal Container Images

Alpine Linux tracks upstream closely and typically drops support for a Python version shortly after its upstream EOL. If you build Docker images on python:3.10-alpine, expect those base images to stop receiving updates soon after October 2026. This is also true for Chainguard/Wolfi images, which align tightly with upstream release cycles.

The key takeaway: distribution support can buy you time for the CPython interpreter, but it cannot protect your full Python application stack. Your pip-installed dependencies, your frameworks, and your build tooling all follow their own EOL schedules.

‍

Cloud Platform Deprecation Timelines

Cloud providers follow upstream EOL with their own phased deprecation windows. These timelines matter because they affect when you can no longer deploy or update applications using a given Python version.

AWS Lambda

AWS follows a staged deprecation for Lambda runtimes after upstream EOL. Based on the pattern established with Python 3.9 (upstream EOL October 2025, Lambda end-of-support December 2025, function create blocked August 2026, function update blocked September 2026), you should expect a similar timeline for Python 3.10. AWS Lambda's Python 3.10 runtime runs on Amazon Linux 2, which is itself scheduled for EOL on June 30, 2026. AWS has stated that AL2-based runtimes (including Python 3.10) will continue receiving critical patches until their deprecation dates, but the recommendation is to migrate to an Amazon Linux 2023-based runtime as soon as possible.

Azure App Service

Microsoft has already announced that extended support for Python 3.10 on Azure App Service ends on October 1, 2026. After that date, applications will continue running but will no longer receive security updates or customer service for the Python 3.10 runtime.

Google Cloud Functions and Cloud Run

Google Cloud typically deprecates Python runtimes within a few months of upstream EOL, with a grace period for existing deployments. Check your runtime configuration and plan to move to Python 3.12 or later.

Heroku

Heroku has already deprecated Python 3.10 in accordance with its version support policy. Apps using Python 3.10 will continue to build, but deprecation warnings are shown, and the runtime will eventually be removed.

‍

The Django Connection: A Compound EOL Problem

For teams running Django on Python 3.10, the EOL picture is particularly compressed. Django 4.2 LTS, the most widely deployed Django LTS release, reaches its own end of life on April 30, 2026, six months before Python 3.10's EOL. Django 3.2 LTS has been EOL since April 2024.

This means that if you are running Django 4.2 on Python 3.10, both your web framework and your language runtime are going end-of-life in the same calendar year. The upgrade path forward requires moving to Django 5.2 LTS (which supports Python 3.10 through 3.14) and then eventually to a newer Django release, while simultaneously upgrading your Python version.

This compound migration is exactly the scenario where teams get stuck. The Django upgrade alone can require significant refactoring, especially if you are jumping from 4.2 to 6.0 across multiple deprecation cycles. Adding a Python version bump on top of that increases the surface area for breaking changes.

For teams that cannot complete both migrations before their respective EOL dates, HeroDevs provides Never-Ending Support (NES) for Django, covering versions 3.2 and 4.2 with ongoing security patches, compliance guarantees, and drop-in compatibility. NES for Django lets you decouple the Django upgrade from the Python upgrade and tackle them on your own timeline rather than under deadline pressure.

‍

How to Audit Your Python 3.10 Exposure

Python 3.10 can be embedded across your infrastructure in places that are easy to overlook. A thorough audit should cover these areas:

Docker base images: Check your Dockerfiles and image tags. Images built on python:3.10, ubuntu:22.04 (which defaults to 3.10), or any derivative need attention.

CI/CD runner configurations: GitHub Actions, GitLab CI, Jenkins, and other CI platforms may have Python 3.10 pinned in workflow files, .python-version files, or pyproject.toml specifying requires-python = ">=3.10".

Cloud function runtimes: Audit your AWS Lambda functions, Azure Functions, Google Cloud Functions, and any other serverless deployments for Python 3.10 runtimes.

Virtual environments and pinfiles: Check pyproject.toml, setup.cfg, .python-version, Pipfile, and tox.ini across all repositories.

System interpreters on servers and VMs: Any Ubuntu 22.04 server running the default Python is running 3.10.

Managed services: Tools like Jupyter notebooks, Airflow DAGs, and data pipeline orchestrators may be running Python 3.10 without explicit configuration, inherited from the underlying platform defaults.

‍

Your Options Before October 2026

Upgrade to Python 3.12 or 3.13

The most direct path. Python 3.12 offers significant performance improvements (up to 5% faster at baseline, with more gains from the per-interpreter GIL work), better error messages, and support through October 2028. Python 3.13 extends that runway to October 2029 and includes experimental free-threaded mode. If your dependency graph supports it, targeting 3.12 or 3.13 gives you the longest support window.

Key compatibility considerations when upgrading from 3.10: the distutils module was removed in Python 3.12 (deprecated since 3.10, replaced by setuptools). The imp module was also removed in 3.12. If you use asyncio extensively, some API changes between 3.10 and 3.12 may require attention.

Leverage Distribution Support

If you run Ubuntu 22.04 with Ubuntu Pro, Canonical will continue patching CPython 3.10 through 2032. This is a viable bridge strategy if your primary concern is the interpreter itself and you can manage your dependency updates independently. Remember that this does not cover PyPI packages.

Adopt Never-Ending Support

For teams that need continued security coverage for their full Python application stack (including frameworks like Django) beyond upstream EOL, HeroDevs' Never-Ending Support provides ongoing CVE patches, compliance documentation, and compatibility guarantees. NES is designed for exactly this scenario: you know you need to migrate eventually, but you need to do it on your schedule, not the upstream community's.

‍

The Python EOL Timeline at a Glance

For planning purposes, here is where every active and recently EOL Python version stands:

• Python 3.8: EOL October 2024. No longer receiving any patches.
• Python 3.9: EOL October 2025. No longer receiving upstream patches. RHEL 9 provides backported coverage through ~2032.
• Python 3.10: EOL October 31, 2026. Currently in security-only phase. Ubuntu 22.04 provides extended coverage through 2027 (standard) or 2032 (Ubuntu Pro).
• Python 3.11: EOL October 2027. Currently in security-only phase.
• Python 3.12: EOL October 2028. Currently in security-only phase.
• Python 3.13: EOL October 2029. Currently receiving active bug fixes.
• Python 3.14: Released October 2025. Currently receiving active bug fixes. EOL October 2030.

‍

Taking Action

The Python ecosystem's annual release cadence makes EOL events predictable. The teams that struggle are the ones that wait until after a version reaches end of life to start migrating. Whether you upgrade to 3.12+, leverage distribution-provided patches, or adopt Never-Ending Support, the key is having a plan before October 31.

Start by auditing your Python 3.10 footprint across Docker images, CI pipelines, cloud runtimes, and virtual environments. Identify your dependency constraints (especially Django version compatibility). Set a target Python version for new development. And if migration is not feasible on the upstream timeline, explore NES to keep your applications secure and compliant while you work through the upgrade at your own pace.

Contact HeroDevs to learn how Never-Ending Support keeps your Python and Django applications secure after upstream support ends.