The Most Underused Cybersecurity Strategy Is to Have Less to Defend

The critical PHP vulnerabilities disclosed on October 21, 2026, exposed a fundamental challenge in enterprise cybersecurity that extends well beyond PHP.

Two vulnerabilities, each rated 9.2 on the CVSS scale, raised concerns about unauthenticated remote code execution across affected PHP installations. CISA, the NSA, and cybersecurity agencies across Europe issued urgent advisories. Several Dutch government websites, including the National Cyber Security Centre’s own site, were temporarily taken offline as a precaution.

The concern was understandable. According to W3Techs, PHP is used by approximately 69% of websites whose server-side programming language can be identified.

By October 23, further investigation suggested that exploitation was more difficult than initially feared, although immediate patching remained necessary.

What made the incident particularly revealing was a point in CISA’s advisory: PHP is often embedded within other software, and its presence may not be directly observable.

For a large enterprise running thousands of applications, that creates a difficult operational problem. Knowing which servers run PHP is one thing. Identifying every affected business application, the vulnerable components within it, its exposure to attackers, the data it can access, and its dependencies on other systems is quite another.

And there is an equally important question that rarely receives attention during a vulnerability crisis: How many of these applications and dependencies are still necessary?

This is where enterprise cybersecurity and technology strategy converge.

For decades, organizations have invested heavily in protecting increasingly complex technology landscapes. Yet a substantial portion of that complexity is the cumulative result of technology decisions made over many years, often without systematically revisiting whether the underlying applications, functionality, and integrations are still required.

One of the greatest opportunities to strengthen enterprise cybersecurity may lie in reducing the technology risks that no longer need to exist.

01Technology Complexity Has Become a Structural Security Risk

Verizon’s 2026 Data Breach Investigations Report found that vulnerability exploitation accounted for 31% of breaches in its dataset, surpassing stolen credentials as the leading initial-access vector. Third-party involvement was identified in 48% of breaches, a 60% increase over the previous year.

The underlying software landscape is growing more complex.

Black Duck’s 2026 Open Source Security and Risk Analysis report, based on commercial codebase audits, found an average of 1,180 open-source components per application, up 30% year over year. The average number of identified vulnerabilities per audited codebase more than doubled to 581. These findings describe the audited population rather than all enterprise applications, but they illustrate the scale of dependencies behind modern software.

At the enterprise level, that complexity compounds.

Applications accumulate through acquisitions, business initiatives, regulatory requirements, and successive waves of digital transformation. Multiple platforms perform overlapping functions. Custom applications survive long after their original business purpose has diminished. Legacy frameworks remain embedded in production systems. Integrations, interfaces, and privileged accounts often outlive the processes they were created to support.

Every additional application introduces software components, identities, configurations, data access, interfaces, and operational dependencies that need to be secured.

Not every component represents material risk. But unnecessary components create security obligations without necessarily contributing corresponding business value.

The consequence is a technology landscape whose size, interconnectedness, and technical diversity can make comprehensive security increasingly difficult.

CISA’s June 2026 analysis underscores the challenge. Citing Verizon research, it reported that only 26% of vulnerabilities in its Known Exploited Vulnerabilities catalog were fully remediated by organizations in the study during 2025. The median time to full resolution reached 43 days.

These findings do not establish that application proliferation caused the breaches or remediation delays. They do, however, raise an important question about the sustainability of securing an ever-expanding software estate.

The more technology an enterprise operates, the more it must understand, maintain, monitor, patch, and protect. Reducing unnecessary technology can permanently remove some of those obligations.

02The Attack Surface Extends Far Beyond Applications and Servers

An enterprise application is not an isolated asset. It is part of a network of software, infrastructure, identities, data, and dependencies.

Consider an internal application developed fifteen years ago to support a specialized business process.

The application serves fewer than thirty users. Its functionality overlaps with a newer enterprise platform, but the older system remains operational because its dependencies have never been fully assessed.

It runs on an unsupported framework, maintains a privileged connection to a production database, and exchanges data with several downstream applications.

The vulnerability scanner may accurately identify weaknesses in its operating environment. The identity system may record its service account. The CMDB may list its owner and infrastructure. Application security tools may identify vulnerable libraries.

But these findings, viewed independently, do not fully explain the business risk.

An attacker exploiting the application might gain access to a critical database or use its existing privileges to reach other systems. The application has limited business importance, yet its connections could make it a consequential security exposure.

Retiring it safely could eliminate far more than its direct vulnerabilities. It could remove a privileged access path, obsolete integrations, an unsupported software stack, and an ongoing set of security obligations.

This is an illustrative scenario, but the underlying architectural problem is common to complex enterprises.

The security significance of an application is determined not simply by what it does, but also by what it can access and what other systems depend on it.

That understanding requires connecting application portfolios, infrastructure, source-code composition, identity privileges, data flows, dependencies, and security findings.

The recent PHP incident demonstrated why this matters. A server-level scan may identify a vulnerable PHP installation, but it cannot by itself establish which business capabilities depend on it, whether the vulnerable functionality is reachable, or what operational consequences remediation might create.

Software composition analysis adds important visibility, but it also has limitations. Black Duck’s 2026 research found that 16% of open-source components in its audited codebases required deeper analysis beyond conventional package-manager and manifest detection.

No single inventory or scanning method provides the entire picture.

Security tools increasingly offer valuable contextual capabilities. Nevertheless, connecting technical exposure to application-level dependencies and business consequences remains a difficult problem in large, heterogeneous estates.

03Application Rationalization Is More Than a Cost Initiative

Application rationalization has traditionally been associated with reducing licensing costs, eliminating duplication, simplifying operations, and modernizing IT.

Its cybersecurity implications are just as important.

Retiring an unnecessary application can remove its vulnerabilities, privileged accounts, interfaces, integrations, and maintenance obligations. Disabling unused features or APIs can eliminate potential attack paths within applications that must remain operational.

Consolidating overlapping platforms can reduce fragmented security configurations, duplicated data repositories, and inconsistent access controls. Modernizing applications with unsupported components, obsolete protocols, or inherently weak architectures can eliminate persistent risks that ordinary patching cannot adequately address.

These changes alter the underlying technology environment rather than merely adding protection around it.

Yet application rationalization is still often evaluated primarily through financial and operational metrics.

An application retirement program may report the number of systems decommissioned or the annual operating costs eliminated, while giving limited attention to security exposure removed.

That misses a substantial part of its value.

Retiring ten applications with limited exposure may deliver less security benefit than eliminating one unnecessary service that maintains privileged access to a critical production system.

Similarly, reducing application count indiscriminately may introduce new risks. Consolidating critical capabilities into one platform can increase the consequences of a compromise or outage. Some redundancy is essential for operational resilience, and certain legacy applications remain adequately secured and economically justified.

The relevant objective is therefore not the smallest possible technology estate. It is a technology landscape that delivers necessary business capabilities with the least avoidable security exposure, unnecessary complexity, and concentration of operational risk.

Application rationalization becomes a cybersecurity discipline when decisions are informed by business necessity, technical exposure, and the consequences of compromise, not simply application count and operating cost.

04Why So Much Unnecessary Risk Remains

The persistence of redundant and vulnerable software is not primarily a failure of executive awareness.

Most experienced CIOs understand the benefits of rationalization. The difficulty lies in determining what can be changed without disrupting the business.

An application with little regular usage may still support an essential quarterly financial process. An undocumented integration may feed a critical manufacturing operation. A legacy database may contain records subject to regulatory retention requirements.

Years of development, acquisitions, and organizational change make these dependencies difficult to reconstruct.

The original developers may have left. Documentation may be incomplete. Ownership may have changed several times. An apparently simple decommissioning decision can carry significant operational uncertainty.

Consequently, the perceived risk of changing an application can exceed the perceived risk of leaving it untouched.

This dynamic explains why unnecessary technology can survive for years, even when its direct business value has largely disappeared.

It also reveals a structural problem in enterprise cybersecurity governance.

Security teams are accountable for identifying and managing exposure, but many of the decisions that create it originate elsewhere: application development, business technology procurement, architecture, platform selection, mergers, and application lifecycle management.

Each decision may be reasonable in isolation. Collectively, they can produce a technology landscape that becomes progressively harder to understand and secure.

The enterprise may have mature security operations while continuing to accumulate unnecessary exposure through its technology decisions.

Cybersecurity risk is therefore shaped not only by the effectiveness of security controls, but also by the architecture, composition, and governance of the underlying technology estate.

05The Economics of Eliminating Risk Are Different

Most cybersecurity investments are designed to reduce the probability of compromise, improve detection, limit impact, or accelerate recovery.

These capabilities remain indispensable.

Structural risk reduction offers an additional economic benefit: eliminating unnecessary technology can remove some of the recurring costs of protecting it.

Every retained application may require vulnerability management, patching, monitoring, access reviews, compliance evidence, backup, recovery, and incident response readiness.

When an application no longer serves a necessary business purpose, continuing to maintain these obligations can represent an avoidable use of both technology and security resources.

Retirement does entail costs. Data retention, migration, dependency remediation, and decommissioning must be managed properly. Removing an application interface without revoking its credentials or eliminating obsolete services may leave much of the original exposure intact.

Nevertheless, the opportunity is significant.

A security control reduces risk while the underlying technology continues to operate. Properly eliminating an unnecessary application, component, interface, or privileged connection can remove that particular source of exposure and its recurring management burden.

The value is not adequately captured by traditional application rationalization metrics.

More meaningful measures include unsupported components eliminated, exploitable interfaces retired, unnecessary privileged access removed, obsolete integrations decommissioned, and material business risks reduced.

These outcomes make cybersecurity an explicit part of enterprise technology investment decisions, alongside cost, performance, reliability, and business value.

06AI Is Raising the Stakes and Changing What Is Possible

AI is accelerating software development and the introduction of new applications, agents, workflows, and integrations.

The resulting increase in development capacity is valuable. But each new application or agent can introduce dependencies, permissions, interfaces, and data access that require governance.

If the enterprise’s ability to create software grows faster than its ability to understand and manage it, technical complexity and potential security exposure will continue to accumulate.

At the same time, AI-assisted code analysis, software discovery, dependency mapping, and contextual reasoning are improving the feasibility of understanding large, interconnected technology estates.

Activities that once required extensive manual investigation can increasingly be supported by automated technical analysis: identifying software components, reconstructing dependencies, mapping data access, connecting vulnerabilities to business applications, and detecting overlapping or obsolete functionality.

The limitations remain real. Automated findings require validation, dependency inference can be incomplete, and application retirement demands business accountability.

But the economics of maintaining current, detailed technology intelligence are changing.

This creates an opportunity to move beyond periodic portfolio assessments toward continuous evaluation of technical exposure, business necessity, and opportunities for safe simplification.

For enterprises with thousands of applications, that is a material advance in what technology governance can realistically accomplish.

07Cybersecurity Must Address the Technology Landscape Itself

The next critical vulnerability may emerge in a programming language, database, library, runtime, commercial platform, or widely used enterprise service.

Security teams will respond as they should: identify affected systems, assess exploitability, contain exposure, and deploy remediation.

Those responsibilities will not diminish.

But the effectiveness and speed of that response will depend heavily on how well the organization understands the technology it operates.

The recent PHP incident is a useful reminder that vulnerabilities can emerge unexpectedly, while the applications, dependencies, and architectural decisions that determine enterprise exposure may have existed for decades.

Many cyber risks are unavoidable consequences of operating modern technology. Others persist because applications have outlived their purpose, unnecessary privileges remain active, redundant platforms continue to operate, and technical dependencies are poorly understood.

The distinction matters.

The first category requires strong security controls. The second creates an opportunity to eliminate risk at its source.

Ultimately, the enterprise attack surface is not a fixed boundary that security teams must simply defend. To a meaningful extent, it is the accumulated result of technology decisions, and it can be deliberately reduced.

The next major opportunity in enterprise cybersecurity is to become as disciplined about eliminating unnecessary technology risk as we have become about detecting, defending against, and responding to it.