It is Friday morning when the security team receives an advisory about a newly disclosed vulnerability in a framework used by one of the company's core applications.
There is already a patched version, so the problem initially looks straightforward: update the framework, test the application and deploy the fix.
Then engineering checks production.
The application is not one version behind. It is several major releases behind. The patched framework requires a newer runtime, but upgrading that runtime breaks two older libraries. One of those libraries supports an integration built years ago by a developer who has since left the company, and nobody is confident that the existing regression tests cover the workflow properly.
What looked like a security patch has suddenly become a modernization project.
Until that morning, none of this was particularly visible. Customers could still log in, transactions were completing and the application had been operating reliably enough that upgrading it never seemed urgent. Yet the moment a serious vulnerability appeared, the real cost of letting the application age became clear: the business no longer had a simple way to make it secure.
That is the central security risk of running an outdated application.
The problem is not simply that old software may contain vulnerabilities. It is that, as an application falls further behind supported technology, the organisation gradually loses its ability to respond when those vulnerabilities are discovered.
An outdated framework may depend on an outdated runtime. Older dependencies may no longer have maintained upgrade paths. Legacy APIs can preserve authorization models the rest of the product has moved beyond, while aging authentication and cryptographic choices may reflect security guidance that has since changed. Eventually, correcting one weakness means disturbing several layers of technology at once.
OWASP's 2025 Top 10 captures this broader problem in its category on Software Supply Chain Failures, which includes vulnerable, unsupported and outdated software across frameworks, libraries, runtimes, databases, APIs and other parts of the application stack.
For Levelworks, this is where Secure and Current & Updated App Health become closely connected. An application does not need to run the newest version of every technology. It does need to remain current enough that security problems can be corrected without turning every urgent fix into a risky migration.
Teams sometimes describe an application as outdated when its user interface looks old or its codebase was written many years ago.
Those things do not automatically make it insecure.
A ten-year-old application that is actively maintained, runs on supported technology, receives security updates and has well-tested upgrade paths may be in a much stronger position than a three-year-old system whose dependencies and infrastructure have been abandoned.
Security-relevant age appears across several layers:
Layer
What can become outdated
Application code
Security assumptions, libraries, validation patterns
Framework
Supported versions, security fixes, default protections
Runtime
Language/runtime security patches
Dependencies
Direct and transitive vulnerable components
Operating environment
OS, containers, middleware, web servers
Database
Supported releases and security corrections
Authentication
Old protocols, flows or security assumptions
Cryptography
Algorithms, libraries, key sizes and migration capabilities
APIs
Deprecated versions and old authorization models
Deployment process
Tooling too fragile to apply security fixes safely
The risk does not come from one layer being old in isolation.
It comes from the relationships between them.
An old framework may require an old runtime. Updating the runtime may require changing libraries. Changing those libraries may break application behaviour that has little automated test coverage. As a result, the team postpones the entire upgrade.
Over time, the application develops a technology chain that is increasingly difficult to move.
That is when age becomes a security problem.
One of the clearest risks is exposure to vulnerabilities that have already been discovered and documented.
A production application may depend on hundreds of software components once direct libraries, transitive dependencies, frameworks, runtimes, containers and infrastructure packages are counted.
Those components continue being researched after your application goes live.
A vulnerability disclosed tomorrow may affect software you installed two years ago.
If the application is actively maintained, the team can assess whether it is affected and move toward an appropriate fix.
If the technology stack has been neglected, the organisation may discover that the secure version is far beyond what its application can currently support.
OWASP recommends tracking the versions of direct and transitive components, monitoring them for vulnerabilities and upgrading platforms, frameworks and dependencies in a risk-based and timely manner. It also calls out reliance on components that are not updateable as part of the broader software supply-chain problem.
This creates an uncomfortable situation that is common in older applications:
The vulnerability may be easy to identify but difficult to remove.
The security problem is no longer just the vulnerable component. It is the maintenance debt surrounding it.
[Internal Link: “How Outdated Dependencies Create Security Risks in Your App”]
Supported software has an important security property that is easy to overlook:
There is still someone maintaining it.
When researchers discover a significant flaw, a supported product may receive a security release, advisory or mitigation guidance.
Once a technology reaches end of life, that expectation changes.
The UK's National Cyber Security Centre warns that obsolete products compound security risk because they no longer receive security updates, increasing the likelihood that exploitable vulnerabilities become known without being corrected by the developer. Its guidance is unusually direct: there is no risk-free method of continuing to use obsolete technology, and replacing it is ultimately the effective way to remove that obsolete-product risk. NCSC: Obsolete Products
This distinction is important.
A currently supported framework that happens to be one minor release behind is not the same security condition as a framework whose entire release line has been abandoned.
The second creates uncertainty about future remediation.
A vulnerability does not need to exist today for unsupported software to deserve attention. The security concern is that if a serious weakness appears tomorrow, the normal patch path may no longer exist.
A newly disclosed vulnerability is no longer private engineering knowledge.
Advisories, proof-of-concept research, patch differences and technical write-ups can make the weakness increasingly understandable to defenders and attackers alike.
CISA's Known Exploited Vulnerabilities Catalog exists to help organisations distinguish vulnerabilities that are merely known from vulnerabilities for which there is evidence of exploitation and prioritize remediation accordingly. CISA's broader guidance recommends prioritizing known exploited vulnerabilities on internet-facing assets within a risk-informed timeframe.
For an outdated application, this can create a growing mismatch:
The application's functionality may remain completely stable throughout.
Security risk and functional stability are not the same thing.
Security advice changes because attacks change and because years of production experience reveal weaknesses that were not understood when a technology was introduced.
Authentication provides a useful example.
OAuth 2.0 itself is not an obsolete technology, but its security guidance has evolved significantly. The IETF's RFC 9700: Best Current Practice for OAuth 2.0 Security updates earlier recommendations based on practical experience, addresses newer threats and deprecates some modes of operation now considered less secure or insecure.
That illustrates a wider issue with applications that stop evolving.
A security design can remain technically functional while becoming inconsistent with current security practice.
Similar drift can affect:
An outdated application may therefore suffer from more than an unpatched CVE.
Its security architecture can age.
[Internal Link: “What Happens When Your App Uses an Outdated Framework?”]
Cryptographic mechanisms often feel permanent because they are embedded deep inside applications and usually work silently.
They are not permanent.
Computing capabilities improve, cryptanalysis advances and standards change.
NIST's current work on cryptographic agility defines crypto agility as the capability to replace and adapt cryptographic algorithms across applications and infrastructure while preserving security and operations. Its 2026 guidance explicitly treats migration capability as an engineering concern because cryptographic transitions will continue to be necessary.
SHA-1 provides a familiar historical example. NIST has progressively restricted its use as weaknesses in the algorithm became better understood and has announced its transition away from SHA-1 for remaining cryptographic protection use cases. NIST: Retiring SHA-1
The broader lesson is more important than the individual algorithm.
If an application has hard-coded security mechanisms so deeply that replacing an algorithm, certificate model or cryptographic library would require a major rewrite, the security risk includes lack of adaptability.
A healthy application should not assume that today's security primitive will remain appropriate forever.
Applications evolve unevenly.
The main product may use a current API while older integrations continue calling previous versions.
That creates a common security problem: newer endpoints receive current testing and controls, while older endpoints remain available because something still depends on them.
Imagine:
/api/v4/accounts
uses current authorization logic, but:
/api/v1/accounts
remains operational for an old integration.
If v1 exposes more data, uses weaker authentication or applies outdated authorization assumptions, it becomes another route to the same underlying application.
The fact that most users never touch it does not reduce its importance to an attacker.
OWASP's API security guidance identifies poor API inventory and lingering versions as an important security concern because undocumented or obsolete endpoints can remain exposed after teams have moved their attention elsewhere.
Outdated applications frequently contain exactly these forgotten surfaces because removing them carries compatibility risk.
The result is a growing security perimeter without a corresponding growth in ownership.
Older systems often begin with relatively simple user models.
Perhaps the original application had:
Years later, the business introduces departments, account owners, support agents, external partners, regional administrators and machine identities.
If the authorization model does not evolve at the same pace, old assumptions can remain embedded throughout the application.
A user may still be authorized based on a broad role even though modern business rules require object-level, tenant-level or function-level restrictions.
The vulnerability here is not necessarily caused by software age alone.
Age gives outdated authorization assumptions more time to diverge from the organisation they are supposed to represent.
This is particularly dangerous because the application may continue doing exactly what it was programmed to do.
The problem is that what it was programmed to allow is no longer what the business intends.
Imagine a serious vulnerability is discovered in the framework supporting a business-critical application.
The security team wants it corrected immediately.
Engineering responds:
We cannot upgrade the framework without upgrading the runtime.
The runtime upgrade requires a newer database driver.
The database driver no longer supports one custom integration.
Nobody has tested that integration recently, and the engineer who built it left three years ago.
This chain is where outdated applications become expensive security liabilities.
What should have been vulnerability remediation has become application modernization under incident pressure.
NIST's Secure Software Development Framework recommends practices designed not only to reduce vulnerabilities in released software but also to mitigate the impact of unaddressed vulnerabilities and address their root causes so they are less likely to recur.
For an aging application, one of those root conditions can simply be that safe change has become too difficult.
This is why Seamlessly Updatable matters to security even though it is not a security control in the narrow sense.
The ability to deploy security corrections is part of the application's security posture.
Teams often avoid updating old applications because changes feel risky.
The reasoning usually sounds sensible:
It still works. Touching it could break something.
For a short period, postponing change may indeed reduce operational risk.
Over a long period, however, the strategy reverses itself.
The more updates that are skipped:
Eventually, a security vulnerability forces change.
Now the organisation must perform the largest upgrade under the shortest deadline.
That is the paradox of outdated software:
Avoiding small controlled changes can make the eventual security change much more dangerous.
This is one reason Levelworks treats Current & Updated as an App Health dimension rather than cosmetic housekeeping.
Being current enough to change safely is a resilience property.
Security risk in an outdated application often becomes entangled with testing debt.
Suppose a framework upgrade changes:
The team may know the upgrade is necessary but lack confidence that important workflows will survive it.
Without adequate regression coverage, every security update becomes a manual investigation.
This leads to delay.
Delay increases version gaps.
Larger version gaps make the next update more complex.
The cycle becomes self-reinforcing.
This is where Tested contributes directly to Secure.
Test coverage cannot prevent a security vulnerability from being announced, but it can reduce the uncertainty involved in adopting the correction.
If an organisation must temporarily continue operating an outdated application, visibility becomes especially important.
You need to know whether:
NCSC guidance on obsolete technology specifically discusses compensating measures where immediate migration is impossible, while making clear that these measures do not eliminate the underlying risk.
Monitoring should therefore not be used as an excuse to keep unsupported software indefinitely.
It is a way to reduce uncertainty during a controlled transition.
For Levelworks, this illustrates how Observable can help manage weaknesses elsewhere in App Health without magically making those weaknesses disappear.
Some security obligations require organisations to maintain supported systems, apply security updates, manage known vulnerabilities or demonstrate that risk is being controlled.
An application running unsupported software can therefore create a governance problem even if no successful attack has occurred.
The exact requirement depends on:
This is another reason security decisions around aging applications need documentation.
If an unsupported component cannot yet be replaced, the organisation should be able to explain:
“Everybody knows the system is old” is not risk management.
There is a danger of overcorrecting.
A component being old does not automatically justify replacing an entire application.
Security decisions should distinguish between:
The application is a few releases behind but still on supported technology and can receive security fixes.
This is usually manageable maintenance.
Important components are approaching end of support or several versions behind, but the application has a realistic upgrade path.
This calls for planned modernization before urgency removes your options.
Some important components no longer receive normal security support, but compensating controls and a migration plan exist.
Risk is higher and should be explicitly owned.
Multiple core technologies are unsupported, security corrections are difficult to apply, tests are weak and even minor modernization produces major compatibility problems.
At this point, the application may require significant modernization or replacement rather than another isolated patch.
The correct decision depends on the business value of the system, risk exposure and modernization effort.
[Internal Link: “Legacy Application Maintenance: Maintain, Modernize or Rebuild?”]
If you inherit an aging system, avoid beginning with a generic instruction to “update everything.”
Start by understanding where the security constraints actually are.
Identify:
Compare this with what is actually deployed, not merely what old documentation says should be deployed.
For each major component, establish whether it is:
This immediately separates ordinary version lag from genuine security exposure.
Use reputable vulnerability data and vendor advisories to determine which deployed versions contain known weaknesses.
Prioritize based on:
Do not treat raw vulnerability counts as risk scores.
Review whether older assumptions remain appropriate around:
Some of the most important risks in an outdated application will not appear in a dependency scanner.
This is easy to overlook.
Ask:
If not, inability to remediate may itself be one of the highest security risks.
Once the inventory is clear, prioritize.
A useful matrix might look like this:
Condition
Security concern
Priority
Supported component, minor versions behind, no material known exposure
Low immediate security impact
Routine maintenance
Known vulnerability with limited exposure and mitigation available
Controlled but real exposure
Planned remediation
End-of-support framework on an important application
Future vulnerabilities may have no normal patch path
High
Known exploited vulnerability on internet-facing software
Credible active threat
Urgent
Legacy authentication or authorization protecting sensitive data
Architectural security weakness
High
Unsupported stack that cannot be upgraded safely
Vulnerability plus loss of remediation capability
Strategic priority
This is more useful than simply asking how many years old the application is.
Security depends on supportability, exposure and ability to respond.
Sometimes immediate modernization is impossible.
A business-critical legacy system may need six months of work before it can be replaced safely.
In that situation, compensating controls may reduce risk while the transition happens.
Depending on the application, these could include:
These measures should be treated as temporary risk reduction, not proof that the underlying problem has disappeared.
The longer the application remains obsolete, the more assumptions around those compensating controls need to be revisited.
NIST's SSDF frames secure software work across the lifecycle rather than as a single release milestone. That lifecycle perspective is especially useful for older applications because the consequences of maintenance decisions accumulate gradually.
Maintaining supported technology does more than close today's vulnerability.
It preserves tomorrow's options.
You can adopt a security release without first rewriting half the application. You can respond to a newly deprecated authentication flow without redesigning your identity architecture under pressure. You can replace a cryptographic primitive because the application was built with enough flexibility to change it.
That is the deeper security value of keeping an application current.
Many old applications are worth keeping.
They may contain years of business knowledge, serve important customers and perform processes that would be expensive to recreate.
Age alone is not a security diagnosis.
The real warning sign is when the application can no longer keep pace with changing security requirements.
An application becomes increasingly dangerous when vulnerabilities cannot be patched easily, core technology has lost support, security designs remain frozen around old assumptions, deprecated interfaces cannot be retired and every necessary upgrade carries so much uncertainty that the organisation postpones it again.
At that point, Secure is no longer just a question of whether a vulnerability exists today.
It becomes a question of whether the application is still capable of remaining secure tomorrow.
For Levelworks, that is why Secure, Current & Updated, Tested, Observable and Seamlessly Updatable often converge in aging applications. Weakness in one area makes the others harder to maintain.
The practical objective is not to chase the newest technology.
It is to prevent the application from becoming so outdated that the next security problem arrives faster than the organisation can safely fix it.
