Python 3.10 end of life: business checks

Python 3.10 end of life matters if a business system relies on that version and its security maintenance has ended. Python is a programming language. Its runtime is the software that executes applications written in that language. Your company may depend on it through a reporting job, website, integration or supplier's application without staff ever opening a Python file.

Ask the person who operates each relevant system which runtime it actually uses and who supports that installation. Then decide whether to migrate, replace or retire it, or obtain evidence for a separate support arrangement. A version number alone does not establish that an incident has occurred, and installing a newer version without checking the application can interrupt the work it performs.

What ended on 1 October 2026

The Python core team's announcement identifies Python 3.10.22 as the final release of Python 3.10 and says no further upstream security updates will follow. The official release page records its release and end-of-life date as 1 October 2026.

"Upstream" means the original Python project in this context. The final patch does not renew its support period. End of life also does not mean that every application using the version stops running on that date. It means the business needs to establish how it will maintain the affected service from here.

A distributor or application supplier may have a different commitment. Treat that as something to verify for the actual installation, rather than assuming it exists or that the upstream announcement invalidates every separate agreement. The Python notice does not establish a universal legal or certification deadline for your company.

Find the running dependency, not just a familiar product name

Give the technical owner a list of important business workflows and ask which depend on Python. Include scheduled work that staff may notice only when an expected report fails to arrive. For a hosted application, ask its operator for the relevant support evidence instead of asking an ordinary user to change its environment.

The record should identify the application and location, the runtime actually executing it, the date and method of that check, and the person responsible for maintenance. A developer's laptop can run a different version from the production service. Likewise, the host's default Python version may not identify the runtime packaged with a particular application.

Connect the technical finding to a business owner. The administrator can confirm a version; the finance manager can explain why an overnight reconciliation matters and what happens if its output is wrong. Both are needed for a useful decision.

If the supplier cannot establish the version or support position, record it as unknown and assign an evidence request. Do not convert missing information into either "supported" or "definitely vulnerable".

Ask what the support commitment actually covers

Request a dated statement or contract reference covering the exact package or build. It should explain who supplies security fixes, which components are covered, how fixes reach your installation, any required entitlement and when that commitment ends. Ask who assesses relevant notices and who verifies that the deployed service received an applicable fix.

A contract for application helpdesk support is not automatically a commitment to maintain its runtime. Support for an operating system also needs to be checked against the particular package or separately installed runtime in use. An assurance such as "we keep everything current" leaves the evidence and responsibility unclear.

If a supplier proposes temporary support while the business migrates, record the limitations and the exit plan. A documented commitment may inform that decision, but it does not prove compatibility, configuration security or the quality of the application's own code. Use the ICT supplier risk guide to connect the evidence request with ownership and contractual dependencies.

A fictional SME inventory and decision

Consider a fictional distribution business reviewing three systems. The findings and outcomes below are illustrative, not a client engagement or claims about named suppliers.

The reconciliation job needs action first because it has an identified unsupported upstream dependency and a current business purpose. The portal's finding narrows this task. The utility's owner has evidence for retirement. Three entries produce different decisions rather than one instruction to upgrade every machine.

For the reconciliation job, the managing director approves preparation and testing. Production release remains conditional on the finance manager accepting the result and the developer demonstrating a workable recovery procedure. The inventory entry remains open while those conditions are unmet. In this example, the director records a temporary exception for the existing job, with a review on 7 October and the developer responsible for returning test evidence. The administrator verifies its access restrictions and the finance manager checks each output during that period. Those measures address access and detection of incorrect results; they do not supply missing upstream fixes. If the exposure cannot be accepted, the operations lead must use an approved alternative workflow rather than assume the old job can continue indefinitely.

Choose a destination the application can use

Have the technical owner identify the runtime, libraries, connectors and operating environment that must work together. A dependency is another component the application relies on. Changing Python can require changes to those components or to the application's own code.

Compare a maintained application release with a targeted code change, replacement or retirement. If the supplier supports only certain combinations, obtain its current compatibility guidance. A temporary support arrangement, where one is actually available and evidenced, needs a defined duration and migration owner.

The Python announcement lists security-only support for 3.11 until October 2027 and for 3.12 until October 2028. Those dates help assess the remaining maintenance horizon; they are not recommendations to choose either version for every system. Confirm the support and compatibility of the proposed destination when planning the change.

For the fictional reconciliation job, the developer selects a candidate only after checking its dependencies. The business also asks how much work would recur at the next support deadline. Choosing the smallest immediate change may create another migration sooner, while a larger change may need more testing. Record that trade-off before approving the scope.

Fail the change when the business result is wrong

The developer builds an isolated test environment using fictional orders. It cannot send customer messages, create live invoices or write to production systems. The finance manager agrees the expected result before the test.

In this example, 25 test orders contain one cancellation. The job should produce 24 payable entries and one cancellation exception. After the runtime and dependency changes, the job finishes without a technical error but produces 25 payable entries. The cancelled order has reached the wrong output.

The finance manager rejects the result. The developer stops the proposed rollout and investigates the handling of cancelled orders. A successful process exit has not established that the business calculation is correct. The observed failure also does not, by itself, prove whether the runtime, a changed library, configuration or existing application logic caused it.

After correcting the identified cause, the developer repeats the same case and the other agreed acceptance checks. These include duplicate inputs, missing required fields and recovery after an interrupted test run. The finance manager verifies that the output contains the expected 24 entries and the cancellation exception. The developer retains the test inputs, expected outputs, actual results and exact tested configuration.

The retest supports that candidate within its tested scope. Release still needs the recovery check, a controlled change window and a named person available to assess the first production result. If those conditions are missing, the business defers release with an owner and a dated action. It does not treat an untested upgrade as the only alternative to doing nothing.

Agree recovery and reconciliation before release

The developer records the application version, dependencies, configuration and data state needed for recovery. If the change also alters stored data, returning to an earlier runtime alone may not restore a compatible service. Test the chosen recovery method in isolation and identify any changes it cannot reverse.

The finance manager owns the rule for deciding which reconciliation output is authoritative. The developer owns the technical restoration and the record of work processed before failure. The operations lead owns staff instructions and the fallback workflow. The managing director approves any temporary return to the earlier environment with its support exposure made explicit.

Suppose a separate fictional recovery exercise stops after producing results for seven of the 25 test orders. The team records which seven completed, checks whether any downstream test records were created and agrees how to handle them before rerunning work. The developer prevents duplicate processing using the tested reconciliation procedure, and finance compares the final result with all 25 original order identifiers.

The recovery test passes only when the expected entries and exception remain correct and no order has been lost or counted twice. A restarted service with duplicate financial output has not recovered the business process.

For production, use the actual processed-work record and approved method. Do not assume a backup restores later transactions or that reverting application files reverses downstream actions. Keep any temporary use of the earlier environment visible in the risk decision and migration plan.

Keep the evidence after the upgrade

Close the support finding when the team has verified the running destination, completed the agreed business checks and handed maintenance responsibility to a named owner. Retain the support end date, dependency record, supplier commitments, failed tests and corrective actions. An installation ticket alone does not show that these conditions were met.

For systems still awaiting action, record the affected service, support gap, interim measures, accountable decision maker and next review date. Ask the technical owner to explain what the interim measures reduce and what remains unresolved. They do not extend upstream support.

Start with one important system whose Python version or support owner is unknown. Obtain that evidence before commissioning a blanket upgrade. If your organisation needs help turning supplier answers into a gap assessment, prioritised actions and an evidence plan, my IT compliance consulting can help scope that work with your existing technical team.

Discuss your software-support review with the system inventory, support statements and the business workflow that must continue. We can agree the responsibilities and evidence needed for the decision. Application changes, hosting support and any certification assessment require their own agreed scope.