Notifications
Clear all
Topic starter
10/07/2026 9:27 pm
TL;DR: When Zend Framework support ended in 2016, many PHP systems stayed in production because replatforming was expensive, risky, and slow, leaving unpatched code, inherited vulnerabilities, and unsupported runtime dependencies in place, according to Cybertrust Japan. The real issue is not framework age alone but the governance gap that lets obsolete components remain trusted infrastructure.
NHIMG editorial — based on content published by Cybertrust Japan: EOL after Zend Framework and the risks and solutions for companies that cannot be replaced
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
Questions worth separating out
Q: What breaks when an EOL framework is left in production?
A: The main failure is not immediate service outage but unmanaged exposure.
Q: Why do legacy PHP systems create security debt for IAM teams?
A: Legacy PHP systems often keep service accounts, embedded credentials, and support access in place long after ownership has changed.
Q: How can organisations tell whether an EOL application is still acceptable risk?
A: A system is only defensible if the organisation can show current ownership, documented dependencies, controlled access, and a time-bound exit plan.
Practitioner guidance
- Map EOL application dependencies now Identify every Zend Framework instance, its hosting platform, upstream libraries, and business owner.
- Inventory and rotate legacy secrets Search code repositories, deployment files, config stores, and CI/CD pipelines for passwords, API keys, and tokens tied to the application.
- Assign a decommissioning decision for each system Classify each EOL application as migrate, extend with support, reduce scope, or retire.
What's in the full article
Cybertrust Japan's full article covers the operational detail this post intentionally leaves for the source:
- Why Zend Framework stayed in production after official support ended and the practical business constraints behind that choice
- Three concrete remediation paths for unsupported PHP systems, including migration, extended support, and functional retirement
- How teams should evaluate cost, time, and residual security risk before deciding whether to keep or replace a legacy stack
👉 Read Cybertrust Japan's analysis of Zend Framework EOL risk and remediation options →
Zend Framework EOL: what legacy PHP teams need to do now?
Explore further
10/07/2026 9:49 pm
Unsupported application frameworks become governance problems, not just patching problems. Once an application framework reaches EOL, the organisation inherits every security obligation the vendor stopped carrying. That shifts the burden from maintenance to governance, because access control, dependency tracking, and remediation discipline all have to close the gap. For IAM and PAM teams, the important question is which identities and secrets still depend on the old stack.
A question worth separating out:
Q: Who should be accountable for unsupported business applications?
A: Accountability should sit with the business owner, not only with IT operations or security. Security teams can assess exposure, but they cannot justify indefinite use of unsupported software on behalf of the business. Governance should require a named owner, a remediation deadline, and a recorded decision for every system that remains in service.
👉 Read our full editorial: Zend Framework EOL leaves legacy PHP systems with security debt
