An unsupported PHP version is a release branch that no longer receives security fixes from the PHP project. As of October 2026, PHP 8.1 and every older branch are end of life, and PHP 8.2 loses security support on December 31, 2026. Healthcare applications on these versions carry unpatched risk to patient data.
Many healthcare portals, booking tools and practice systems still run PHP versions that are past their support dates or close to them. This guide explains what end of life means in practice, how it affects HIPAA risk analysis and what your options are. If you need help with an upgrade, our PHP development services team works with healthcare platforms every day.
How the PHP Support Lifecycle Works
PHP follows a predictable, published lifecycle, which makes support planning easier than for many technologies. A new minor version is released each year, usually in November. Each branch then moves through active support, a security-only period and finally end of life. The dates are listed on the official PHP supported versions page, so there is no guesswork about when a version stops receiving fixes. Understanding these stages helps healthcare teams plan upgrades well ahead of deadlines, instead of discovering an unsupported version during an audit, a customer review or a security incident.
Annual Releases Each November
The PHP project ships a new minor version roughly every November, such as PHP 8.4 in November 2024 and PHP 8.5 in November 2025. Each release brings new features, performance improvements and deprecations that prepare developers for future changes in the language.
Active Support for Two Years
For the first two years, a branch receives regular bug fixes and security fixes in frequent point releases. This is the most comfortable period to run a version, because problems of every kind are fixed and released on a regular, predictable schedule by the project.
Security-Only Support for Two More Years
After active support ends, the branch receives fixes only for critical security issues, released as needed. Ordinary bugs are no longer fixed. Under the current policy, this phase lasts two years and ends on December 31 of the final year.
End of Life
Once security support ends, the branch is end of life. The PHP project publishes no further fixes, including for critical vulnerabilities. Applications on end-of-life versions remain exposed to every new flaw discovered after that date unless another party supplies a patch.
The Policy Change Applied in 2024
PHP extended the security-only phase from one year to two years and aligned end dates to December 31. The change applied to branches still supported at the time, which is why PHP 8.1 received an extra year and reached end of life on December 31, 2025.
Where to Check Official Dates
The official supported versions page on php.net lists current branches with their active and security support end dates, along with a table of end-of-life branches. Use it as the single source of truth when recording support dates in your risk register or upgrade plans.
Where Each PHP Version Stands in October 2026
The table of supported versions changes every year, so healthcare teams should check it regularly rather than relying on memory. As of October 2026, the picture is clear. Everything older than PHP 8.2 is end of life. PHP 8.2 is in its final months of security support. PHP 8.3 is in security-only support, while PHP 8.4 and 8.5 are in active support. The sections below summarize each branch, with dates taken from the official PHP schedule. Confirm them against php.net before recording them in compliance documents or sharing them with auditors.
PHP 7.4 and Older
PHP 7.4 reached end of life on November 28, 2022, under the earlier support policy, and older 7.x and 5.x branches ended before that. Systems on these versions have gone years without official fixes and should be treated as high-priority risks.
PHP 8.0
PHP 8.0 reached end of life in 2023 and receives no official fixes. Applications on 8.0 often upgrade reasonably smoothly to later 8.x releases, because the biggest breaking changes arrived in 8.0 itself, but every new vulnerability remains unpatched until they do.
PHP 8.1
PHP 8.1 reached end of life on December 31, 2025, with 8.1.34 as its final release. It is now unsupported. Teams still on 8.1 should plan an upgrade immediately, ideally to a branch with several years of security support remaining.
PHP 8.2
PHP 8.2 is in security-only support, which ends on December 31, 2026. After that date, it becomes end of life. Healthcare organizations on 8.2 have only weeks to plan and test an upgrade before they join the unsupported group. Start that work now.
PHP 8.3
PHP 8.3 left active support on December 31, 2025, and now receives security fixes only until December 31, 2027. It is supported, but teams upgrading from older versions should consider skipping straight to 8.4 or 8.5 for a longer runway.
PHP 8.4 and 8.5
PHP 8.4 is in active support until December 31, 2026, with security fixes until December 31, 2028. PHP 8.5 is in active support until December 31, 2027, with security fixes until December 31, 2029, giving the longest runway of any branch.
What End of Life Means in Practice
End of life does not mean an application stops working. It keeps running exactly as before, which is why unsupported versions linger for so long. The change is invisible until a new vulnerability appears. At that point, supported branches receive fixes within days, while unsupported branches may receive nothing. The October 2026 PHP2Shell disclosure showed this clearly. Teams on supported versions patched quickly, while teams on old versions depended on partial backports, operating system vendors or emergency shutdowns. The points below explain the practical consequences healthcare teams should expect when running an end-of-life version.
No Fixes for New Vulnerabilities
When a flaw is found in PHP, the project fixes supported branches only. End-of-life branches stay vulnerable. Attackers know this, and many automated scanners specifically look for old PHP versions because they are reliably exposed to known, published flaws. A security audit shows your exposure.
Occasional Exceptions Are Not a Plan
For PHP2Shell, security vendors report that the PHP team published minimal source backports for 7.4, 8.0 and 8.1. That was an exception for a severe flaw, not a commitment. Future vulnerabilities may receive no backports at all for end-of-life branches.
Operating System Vendor Support
Some Linux distributions maintain their own patched PHP packages for longer than the PHP project does, within their own support periods. This can extend safe use, but only if you run those vendor packages and keep the operating system itself within its support window.
Paid Extended Support Options
Some vendors sell extended security support for end-of-life PHP versions, releasing their own patches. This can buy time for systems that cannot be upgraded quickly. Evaluate these carefully, include the vendor in your risk analysis and treat the arrangement as temporary.
Frameworks and Libraries Drop Support
Laravel, Symfony, WordPress plugins and Composer packages raise their minimum PHP versions over time. Staying on old PHP eventually blocks framework and library updates, so security fixes in those components also become unavailable, compounding the risk well beyond the PHP runtime itself.
Hosting Providers Retire Versions
Hosting platforms and managed services remove old PHP versions from their offerings, sometimes with short notice. Applications that cannot run on newer versions may face forced upgrades, unexpected outages or migration to less suitable hosting arrangements at an inconvenient moment.
HIPAA and Compliance Implications
HIPAA does not name PHP or any technology, but it does require covered entities and business associates to identify and manage risks to electronic protected health information. Software that no longer receives security fixes is a clear, documentable risk. Auditors, enterprise customers and partners increasingly ask about runtime versions directly. How you record and address unsupported PHP versions affects audit outcomes, sales cycles and your position if an incident occurs. The points below summarize the main compliance considerations. They are general guidance and not legal advice for your specific situation.
Recording the Risk in Your Risk Analysis
Each system on an unsupported PHP version should appear in your risk analysis with its exposure, the data it handles, likelihood, impact and planned remediation. A HIPAA risk assessment can help document these findings in a consistent, defensible way. Update entries as remediation progresses.
Compensating Controls While You Upgrade
If an upgrade cannot happen immediately, compensating controls such as network restrictions, web application firewalls, extra monitoring or extended vendor patches reduce risk. Document each control, why it is sufficient for now and the date by which the upgrade will be completed.
Customer and Partner Security Reviews
Hospitals and payers often require vendors to confirm they run supported software. An unsupported PHP version can delay contracts, trigger remediation clauses or fail a review outright. Upgrading before these reviews avoids difficult conversations and protects revenue from important customers.
Business Associate Responsibilities
If a vendor hosts or maintains PHP applications that handle your patient data, they are typically a business associate. Ask them which PHP versions they run and their upgrade timeline. Our BAA guide explains reasonable security terms to expect. Get their answers in writing.
Consequences After an Incident
If a breach occurs through a known vulnerability in unsupported software, investigators will ask whether the risk was identified and managed. A documented plan with progress helps. An ignored risk can increase scrutiny. Our overview of HIPAA violation penalties explains how enforcement works.
Security Certifications and Frameworks
Frameworks such as SOC 2 and HITRUST expect vulnerability management and supported software. Unsupported PHP versions can become findings during assessments. Our SOC 2 and HITRUST comparison explains how these frameworks treat patching and system maintenance. Fix unsupported versions before your next assessment window to avoid avoidable findings.
How to Find Unsupported PHP in Your Environment
Many healthcare organizations underestimate how much PHP they run. Besides the main portal or practice system, PHP often powers marketing websites, intranet tools, research databases, survey platforms, legacy integrations and applications inside vendor appliances. Some of these are managed by departments or outside agencies without central IT oversight. A thorough inventory is the foundation of any upgrade plan, because you cannot fix what you do not know exists. The steps below help build an accurate list, including the exact versions in use and who is responsible for each system that runs PHP.
Scan Servers and Containers
Use configuration management tools, vulnerability scanners and container image scanning to identify every host and image with PHP installed. Record the installed packages and versions. Container images are easy to overlook, because old base images can linger in registries and deployments for years.
Check the Runtime Serving Requests
The command-line PHP version may differ from the PHP-FPM or web server module that actually serves traffic. Check the active runtime for each application, including the package revision, since operating system backports may carry older version numbers while still containing important security fixes.
Review Hosting and Cloud Accounts
Shared hosting, managed WordPress platforms and cloud services each show PHP versions in their control panels. List every account, including ones opened by marketing teams or agencies, and record the PHP version configured for each site, application or environment. Our WordPress development team can help.
Ask Vendors and Agencies
Request written confirmation of PHP versions from vendors and agencies that host or maintain applications for you. Include staging and backup environments. Vendors that cannot answer quickly may not be tracking versions themselves, which is useful information for your vendor risk review.
Check Frameworks and Platforms
Record the framework and platform versions alongside PHP, such as Laravel, CodeIgniter, Drupal or WordPress. Drupal 7, for example, reached end of life in January 2025. A supported PHP version does not help much if the framework above it is unsupported.
Assign Owners and Dates
For every system found, record an owner, the PHP and framework versions, the data handled, internet exposure and the support end date. This inventory becomes the basis for prioritizing upgrades and reporting progress to leadership and compliance teams over the following months.
Your Options for Each Situation
Once you know which systems run unsupported or soon-to-be-unsupported PHP, the next step is choosing a path for each one. There is rarely a single answer for the whole organization. A well-structured application may need a simple version upgrade, while an old custom portal may need replacement or a phased migration to a different stack. Some systems can simply be retired. The options below cover the most common situations. Choose based on the system’s importance, the data it handles, its code quality and how long it needs to remain in service.
Upgrade Within PHP 8
Applications on PHP 8.0, 8.1 or 8.2 can usually move to 8.4 or 8.5 with manageable changes, such as handling deprecated dynamic properties and stricter type behavior. Automated refactoring tools and compatibility scans speed this work and reduce the risk of missed issues.
Upgrade From PHP 7 to PHP 8
Moving from PHP 7.x to 8.x involves more breaking changes, including stricter comparisons, removed functions and changes to error handling. It is still often the most economical path for structured applications, especially when combined with a framework upgrade to a supported version.
Buy Time With Extended Support
Where an upgrade will take months, operating system vendor packages or paid extended support can reduce exposure in the meantime. Treat this as a bridge with a firm end date and document it in your risk analysis, never as a permanent arrangement.
Isolate Systems That Cannot Be Fixed Quickly
Systems that cannot be upgraded or patched soon can be removed from internet access, restricted to VPN users or placed behind strict network controls. Isolation reduces exposure while you plan a replacement or upgrade for systems that must keep running.
Replace With a Supported Product
Some custom PHP tools duplicate features now available in supported commercial products or your EHR. Retiring them in favor of a maintained product removes the upgrade burden entirely. Compare total ownership costs before deciding, as our custom software vs SaaS guide explains.
Migrate to a Different Stack
When upgrades are impractical or the product needs different capabilities, a phased migration to Node.js, Next.js and React may make sense. Our software modernization team plans these migrations so the PHP system keeps running until each module is replaced. Each phase is reversible.
Planning Ahead for PHP 8.2 End of Life
PHP 8.2 security support ends on December 31, 2026, which leaves healthcare organizations on 8.2 with very little time. Upgrades need testing, especially for applications that handle clinical, scheduling or billing logic, and many organizations have change freezes around year-end. Planning now avoids running unsupported software from January 2027. The same planning approach applies to later branches as their dates approach, so building a repeatable upgrade process now pays off for years. The steps below focus on getting off PHP 8.2 safely and setting up a routine that prevents future last-minute upgrades.
Choose Your Target Version
PHP 8.4 offers security support until the end of 2028, and PHP 8.5 until the end of 2029. Choose the newest version your frameworks and libraries support, so you gain the longest runway before the next required upgrade arrives. Our Laravel developers confirm compatibility.
Run Compatibility Checks Now
Static analysis and compatibility tools identify code that will break on the target version. Run them early to size the work accurately. Small issues found now are easy to fix, while issues found during a year-end freeze can delay the upgrade into the new year.
Update Frameworks and Dependencies
Confirm that your framework and Composer packages support the target PHP version. Some will need upgrading first. Plan dependency updates in sequence, testing after each step, so problems are easier to isolate and fix without affecting other parts of the application.
Test Clinical and Billing Logic Thoroughly
Run automated tests across eligibility, scheduling, consent and billing rules, and add tests where coverage is missing. Our healthcare automation test engineers build these suites so upgrades do not quietly change how patient-facing features behave. Tests also make every future upgrade faster and far less risky.
Plan Around Change Freezes
Many healthcare organizations restrict changes around year-end, holidays and system downtimes. Schedule the upgrade with these windows in mind, leaving time for staging tests, user acceptance and rollback planning before the December 31 deadline arrives and support ends. Earlier is always safer.
Build a Repeatable Upgrade Routine
Record support dates for every branch in use, review them quarterly and schedule upgrades a year ahead of each deadline. Automated pipelines from our healthcare CI/CD implementation service make each future upgrade faster and safer. Upgrades then become routine maintenance instead of emergencies.
Frequently Asked Questions
These are the questions healthcare IT leaders ask most often about unsupported PHP versions. The answers reflect the official PHP support schedule as of October 2026 and our experience upgrading healthcare platforms. Always confirm dates on the official php.net supported versions page before recording them in compliance documents. Your options depend on your applications, frameworks, vendors and the data involved, so treat these answers as a starting point. If you need help assessing your PHP estate or planning an upgrade before the PHP 8.2 deadline, our team can review your situation and recommend next steps.
Does an unsupported PHP version stop working?
No. Applications keep running normally after end of life. The risk is that newly discovered vulnerabilities are not fixed by the PHP project, so your application stays exposed. That is why unsupported versions often remain in production far longer than they should.
Is PHP 8.2 still safe to use?
PHP 8.2 receives security fixes until December 31, 2026. It is supported for now, but the deadline is close. Plan and test an upgrade to PHP 8.4 or 8.5 now, so you are not running unsupported software from January 2027.
Which PHP version should we upgrade to?
Choose the newest version your framework and libraries support. As of October 2026, PHP 8.5 offers security support until the end of 2029 and PHP 8.4 until the end of 2028, giving the longest runway before the next upgrade. Confirm framework support first.
Does HIPAA require us to upgrade PHP?
HIPAA does not name specific software, but it requires you to identify and manage risks to electronic protected health information. Unsupported software is a documentable risk. Upgrading, or applying documented compensating controls with a firm timeline, is how most organizations address it.
How long does a PHP upgrade take?
It depends on the version gap, code quality, framework and test coverage. A move within PHP 8 can be quick for well-structured code. Moving from PHP 7 or upgrading an old framework takes longer. A compatibility scan gives a realistic estimate.
Can extended support replace an upgrade?
Extended support can reduce risk for a limited time, but it is not a long-term substitute. Frameworks and libraries will still drop support for old PHP versions. Use extended support as a bridge while you complete the upgrade. Set a firm end date.
Tell Us About Your PHP Versions
Tell us which PHP versions and frameworks your healthcare applications run today and who hosts them. We will help you prioritize upgrades by risk, plan for the PHP 8.2 deadline and document progress for your compliance team. Book a free consultation.