Last Updated: April 3, 2026

Legacy Software Vulnerabilities: The 2026 Risk Assessment Guide

If you’re running business-critical systems on software that hasn’t been meaningfully updated in five years—or longer—you’re not alone. We’ve been building and maintaining software in Nashville since 1992, and we’ve seen the same pattern play out dozens of times: businesses delay upgrades until a security incident forces their hand. The problem is, by then the damage is already done.

Legacy software vulnerabilities are security weaknesses in outdated systems that no longer receive patches, leaving them exposed to modern cyber threats. These unpatched systems become entry points for ransomware, data breaches, and compliance violations that can cost businesses millions in remediation and lost revenue.

The security landscape in 2026 looks dramatically different than it did even three years ago. AI-powered attack tools have lowered the barrier for cybercriminals, regulatory requirements have tightened, and the average cost of a data breach has climbed to $4.88 million according to IBM’s latest research. Yet we still regularly encounter organizations running Windows Server 2012, SQL Server 2008, or custom applications built on frameworks that haven’t been supported since 2019.

This guide draws from our three decades of experience helping companies assess, secure, and ultimately modernize their legacy systems. We’ll walk you through the actual risks you’re facing, show you what a comprehensive security assessment looks like in 2026, and give you concrete strategies for protecting your systems while planning your path forward.

What Qualifies as Legacy Software in 2026?

Not all old software is legacy software. The distinction matters because it determines your risk profile and your options for mitigation.

Legacy software is any system that no longer receives security updates from its vendor, runs on deprecated technology stacks, or lacks compatibility with modern security tools. That’s the technical definition. In practical terms, it’s software that you’re afraid to touch because nobody fully understands how it works anymore.

Here’s what we’re typically seeing classified as legacy in 2026:

Operating Systems Past End-of-Life

Windows Server 2012 and 2012 R2 reached extended support end in October 2023. Windows 10 reaches end-of-life in October 2025. If you’re still running these in production environments without extended security updates, you’re operating with known, documented vulnerabilities that attackers actively scan for.

We worked with a Nashville healthcare organization last year that was running patient scheduling software on Windows Server 2008 R2—seven years past its support deadline. They’d avoided upgrading because the scheduling software vendor had gone out of business. The irony? They were spending $80,000 annually on enhanced security monitoring for that single server, when a complete system replacement would have cost $120,000 one time.

Unsupported Databases and Middleware

SQL Server 2012 ended extended support in July 2022. Oracle 11g reached the same milestone in 2020. Yet both are still widely deployed, particularly in manufacturing and financial services where database migrations feel risky.

The middleware layer is often overlooked. We recently encountered an enterprise running IBM WebSphere 8.5, which reached end-of-service in April 2022. Their application stack was processing credit card transactions. The cybersecurity risk assessment revealed 37 known critical vulnerabilities with no patches available.

Custom Applications on Deprecated Frameworks

This is where things get complicated. Your business logic might be sound, but if it’s running on .NET Framework 3.5, PHP 5.6, or Python 2.7, you’ve got a problem. These frameworks have known security issues that will never be fixed.

Custom applications present a unique challenge because there’s no vendor to push updates. Conducting regular software code audits becomes essential—someone needs to take ownership of security maintenance, and that someone is you.

Commercial Software Without Vendor Support

Vendor abandonment is more common than people realize. Companies get acquired, products get sunset, or vendors simply go out of business. You’re left with software that works perfectly until it doesn’t—and when it breaks, there’s nobody to call.

The 2026 Legacy Software Vulnerability Landscape

The threat environment has evolved substantially, and legacy systems are increasingly targeted specifically because attackers know they’re easier to compromise.

AI-Powered Vulnerability Scanning

Attackers now use AI tools to automatically identify legacy systems on networks and match them against vulnerability databases in real-time. What used to take a skilled hacker days of reconnaissance now happens in minutes. The automated exploitation that follows is equally sophisticated.

CISA’s Known Exploited Vulnerabilities catalog has grown 34% year-over-year, with legacy system vulnerabilities representing 61% of the additions in 2025. These aren’t theoretical risks—they’re vulnerabilities being actively exploited in the wild.

Ransomware Targeting Legacy Infrastructure

Ransomware groups have become increasingly sophisticated in their reconnaissance. They specifically hunt for legacy systems because they know these environments often lack modern endpoint detection, have minimal network segmentation, and are critical enough that companies will pay to restore them.

The average ransomware payment in 2025 was $2.3 million, but that figure doesn’t include recovery costs, which typically run three to five times the ransom amount. For systems running legacy software, recovery is even more complex because you can’t simply restore to clean backups if the underlying platform is compromised.

Supply Chain Vulnerabilities

Legacy systems typically rely on equally outdated dependencies—libraries, plugins, and third-party components that also no longer receive updates. The 2025 Verizon Data Breach Investigations Report found that 68% of breaches involving legacy systems started with a compromised third-party component.

Take the Log4j vulnerability that emerged in late 2021. Systems still vulnerable to Log4Shell in 2026 are almost exclusively legacy environments where patching would require extensive testing or application rewrites. Attackers know this and actively scan for these specific signatures.

Zero-Day Accumulation

Here’s something most people don’t consider: zero-day vulnerabilities don’t disappear when software reaches end-of-life. They simply never get patched. Over time, legacy systems accumulate an ever-growing list of known vulnerabilities for which no fixes exist or will ever exist.

Windows Server 2012, for example, had 23 critical vulnerabilities discovered after its extended support ended. Anyone running it without extended security updates is operating with those 23 known weaknesses permanently embedded in their infrastructure.

Real-World Impact: Case Studies and Cost Analysis

The abstract risk of legacy software vulnerabilities becomes concrete when you see what actually happens when these systems are compromised. Here are three incidents from the past 18 months that illustrate different failure modes.

Case Study: Healthcare Provider Ransomware Attack

A mid-sized healthcare network in the Southeast experienced a ransomware attack in July 2025 that shut down patient care systems for six days. The entry point was a legacy patient portal running on an unsupported version of Apache Tomcat.

The breakdown:

• Direct ransom payment: $1.8 million
• Recovery and restoration: $4.2 million
• Regulatory fines (HIPAA violations): $2.1 million
• Legal costs and patient notification: $800,000
• Lost revenue during downtime: $3.4 million
• Total impact: $12.3 million

The legacy portal had been on the “to-do” list for modernization for three years. The estimated cost to rebuild it properly was $450,000. The organization paid 27 times that amount because they waited until after an incident.

Case Study: Manufacturing Data Breach

A Tennessee manufacturing company discovered in March 2025 that their production management system—running on SQL Server 2008—had been compromised for at least eight months. Attackers had been exfiltrating intellectual property, including proprietary manufacturing processes and customer contracts.

The legacy database was segregated on a VLAN, which gave them a false sense of security. What they didn’t account for was that their monitoring tools couldn’t inspect the older TLS version the legacy system used, creating a blind spot in their security operations.

Impact included:

• Loss of competitive advantage as proprietary processes appeared in competitor products
• Breach notification to 847 customers and partners
• Three major contracts canceled due to security concerns
• Emergency database migration completed in 45 days under extreme pressure

The financial impact exceeded $8 million, but the reputational damage was arguably worse. Two years later, they’re still fighting the perception that their security is inadequate.

Case Study: Financial Services Compliance Violation

A financial services firm faced a different consequence in late 2025: they lost the ability to process certain transaction types because their legacy trading system couldn’t meet new regulatory requirements for transaction logging and auditability.

They weren’t breached. They weren’t attacked. They simply woke up one day to find their core system was no longer compliant with updated regulations, and there was no patch available because the software had been end-of-life for four years.

The emergency modernization cost $6.7 million and took seven months. During that period, they had to route certain transactions through a third-party processor at significantly higher costs, eroding their margins and frustrating clients.

The Real Cost Comparison

Let’s look at the numbers side-by-side. This table shows the actual costs from organizations we’ve worked with over the past two years:

The pattern is consistent: reactive responses cost 3-27 times more than proactive modernization. And these figures don’t capture the intangible costs—executive time consumed by crisis management, employee stress, customer trust erosion, and strategic opportunities missed while dealing with the incident.

Your Legacy Software Risk Assessment Framework

Understanding your exposure requires a systematic approach. We’ve refined this framework over hundreds of assessments, and it gives you a realistic picture of where you stand.

Step 1: Create Your Software Inventory

You can’t assess risk for systems you don’t know exist. Shadow IT is real, and legacy systems are often the least documented.

Your inventory needs to capture:

• Application name and version: Including point releases and patches
• Technology stack: OS, database, middleware, frameworks, and key dependencies
• Support status: Current vendor support commitments and end-of-life dates
• Business function: What processes depend on this system
• Data classification: What types of data it processes and stores
• Network exposure: Internet-facing, internal only, or isolated
• Integration points: What other systems connect to it
• Maintenance history: When it was last patched, upgraded, or modified

We typically find that companies discover 15-30% more legacy systems than they initially believed they had once they conduct a thorough inventory. Often these are departmental systems that IT knows about but doesn’t actively manage.

Step 2: Vulnerability Assessment

With your inventory complete, the next step is identifying specific vulnerabilities. This isn’t just running a vulnerability scanner—though that’s part of it.

Automated scanning: Use commercial tools like Tenable, Qualys, or Rapid7 to identify known CVEs. For legacy systems, expect a long list. We recently scanned a Windows Server 2008 environment and found 247 vulnerabilities, 89 of which were rated critical or high severity.

Manual assessment: Automated tools miss context. You need humans to evaluate architecture, configuration weaknesses, and logic flaws. This is particularly important for custom applications where generic scanners provide limited value.

Penetration testing: Simulate actual attack scenarios against your legacy systems. We recommend this annually at minimum for systems processing sensitive data. Many organizations partnering with managed IT services providers include regular penetration testing as part of their ongoing security posture.

Dependency analysis: Map all libraries, plugins, and third-party components. Run them through vulnerability databases like the National Vulnerability Database and CISA’s Known Exploited Vulnerabilities catalog.

Step 3: Impact and Likelihood Analysis

Not all vulnerabilities carry equal risk. A critical vulnerability in an isolated system running your parking lot gate is less concerning than a medium-severity vulnerability in your customer database.

Use this matrix to prioritize:

Systems that rate “High” in three or more categories need immediate attention. Those are your critical risks, and they should drive both your mitigation strategy and your modernization roadmap.

Step 4: Compliance Gap Analysis

Regulatory requirements have tightened significantly around cybersecurity. Your legacy systems may put you out of compliance even if they haven’t been breached.

Key frameworks to evaluate against:

• HIPAA Security Rule: For healthcare organizations, legacy systems often can’t meet current encryption, access control, and audit logging requirements
• PCI DSS 4.0: Released in 2022, with enforcement ramping up through 2025. Legacy payment systems frequently violate multiple requirements
• SOC 2: If you’re a service provider, legacy systems make it nearly impossible to achieve SOC 2 Type II certification
• GDPR and state privacy laws: Data protection and breach notification requirements often exceed what legacy systems can support
• Industry-specific regulations: Financial services (GLBA, SEC), manufacturing (CMMC for defense contractors), and others have specific technology requirements

Companies providing compliance audits as part of their security practice see these gaps consistently: legacy systems that were compliant when deployed are no longer sufficient as regulations evolve.

Step 5: Total Cost of Ownership Analysis

Legacy systems often appear cheaper to maintain than they actually are because organizations don’t capture all the costs.

True TCO includes:

• Direct maintenance: Staff time, contractor support, vendor fees
• Extended security updates: Microsoft ESU, third-party patch management services
• Enhanced monitoring: Additional security tools needed because modern EDR/XDR doesn’t support old systems
• Workarounds: Manual processes, integration middleware, duplicate data entry
• Opportunity cost: Features you can’t implement, integrations you can’t build, optimizations you can’t pursue
• Risk premium: Cyber insurance surcharges, customer security questionnaire failures, lost business due to security concerns

In our experience, when you calculate true TCO, legacy systems cost 2-4 times what organizations initially estimate. That math changes the ROI calculation for modernization dramatically.

Immediate Mitigation Strategies

Modernization takes time. You need to reduce risk now while you plan your long-term approach. Here’s what actually works based on our experience securing legacy environments.

Network Segmentation and Isolation

This is your first line of defense. Legacy systems should live on segregated network segments with strict firewall rules controlling what can communicate with them.

Micro-segmentation: Don’t just create a “legacy VLAN” and call it done. Each legacy system should have its own segment with explicit allow rules. Default deny everything else.

Zero-trust access: Implement identity-based access rather than network-based access. Users authenticate and receive time-limited access to specific systems, not blanket network access.

Jump boxes: Administrative access to legacy systems should route through hardened jump servers that log all activity. No direct connections from admin workstations.

We helped a manufacturing client implement this for their legacy SCADA systems. The segmentation alone reduced their exploitable attack surface by 73% without touching the legacy applications themselves.

Enhanced Monitoring and Detection

If you can’t patch the vulnerability, you need to detect exploitation attempts immediately.

Network behavior analysis: Baseline normal communication patterns for legacy systems, then alert on deviations. Unusual data volumes, new connection patterns, or off-hours activity all warrant investigation.

File integrity monitoring: Legacy systems typically have stable file systems. Any unauthorized file changes should trigger immediate alerts. Tools like OSSEC or Tripwire work even on older platforms.

Log aggregation and analysis: Ship all logs from legacy systems to a SIEM where you can correlate events across your environment. The legacy system itself might not detect an attack, but patterns across multiple systems often reveal reconnaissance or lateral movement.

Threat intelligence integration: Subscribe to threat feeds relevant to your legacy platforms. When new exploits emerge for Windows Server 2012 or SQL Server 2008, you need to know immediately so you can increase monitoring for those specific attack patterns.

Virtual Patching Through WAF and IPS

When actual patches don’t exist, virtual patching can block known exploits at the network perimeter or inline.

Web application firewalls: For legacy web applications, a properly configured WAF can block SQL injection, XSS, and other OWASP Top 10 attacks before they reach the vulnerable application.

Intrusion prevention systems: IPS devices can detect and block exploit attempts based on signatures. This works particularly well for known vulnerabilities where exploit patterns are well-documented.

Limitations to understand: Virtual patching stops known attacks using known methods. It doesn’t protect against zero-day exploits or novel attack vectors. It’s a mitigation, not a solution.

Application Control and Whitelisting

Legacy systems typically run predictable workloads. Leverage that by implementing strict application control.

Use tools like Windows AppLocker or third-party application whitelisting to ensure only approved executables can run on legacy servers. This prevents ransomware and other malware from executing even if delivered through a vulnerability.

We implemented this for a financial services client running legacy .NET applications. When a phishing attack successfully delivered malware to a workstation that had access to the legacy environment, the application whitelisting prevented the ransomware from executing. The attack failed despite the initial compromise.

Data Protection and Backup Strategies

Assume your legacy system will eventually be compromised. Your backup strategy becomes your recovery strategy.

Immutable backups: Use backup solutions that create write-once-read-many snapshots that ransomware can’t encrypt. Store copies offline or in separate cloud accounts with different credentials.

Testing discipline: Quarterly restoration testing is non-negotiable. We’ve seen too many organizations discover their legacy system backups don’t actually work when they need them in a crisis.

Data minimization: Legacy systems tend to accumulate data forever. Archive and remove historical data that doesn’t need to be online. Fewer data means smaller breach impact.

Vendor Extended Support Options

When available, extended support from vendors can bridge the gap while you plan modernization.

Microsoft offers Extended Security Updates for Windows Server and SQL Server—typically three additional years of critical and important security updates. It’s expensive (costs increase each year), but for business-critical systems it buys valuable time.

Third-party vendors like TuxCare offer extended support for Linux distributions past their EOL dates. These arrangements vary in scope and effectiveness, so evaluate carefully.

The catch: Extended support isn’t indefinite, and it typically covers only critical vulnerabilities. It’s a bridge to modernization, not an alternative.

Building Your Modernization Roadmap

Mitigation buys time, but modernization is the only real solution. The challenge is doing it in a way that doesn’t disrupt operations or consume resources you don’t have.

Assessment and Prioritization

Start by categorizing your legacy systems into one of four buckets:

Retire: Systems that are no longer necessary or whose functionality has been replicated elsewhere. You’d be surprised how often we find legacy systems that nobody actually uses anymore, maintained out of habit or fear.

Replace: Systems where modern off-the-shelf alternatives exist that meet your needs. The business logic isn’t particularly unique, and commercial solutions have matured. This is often the fastest path for standard business functions like accounting, HR, or CRM.

Re-host (Lift and Shift): Move to modern infrastructure without rewriting code. This works for applications that are stable but running on outdated platforms. Containerization or moving to modern OS versions can extend life significantly.

Re-architect: Complete rebuild of custom applications that embody critical business logic. This is the most expensive option but necessary when the application is truly differentiated and central to your competitive advantage.

Priority should be determined by the risk assessment framework we covered earlier. Focus first on high-risk systems with the greatest business impact.

Phased Modernization Approach

Don’t try to modernize everything at once. We’ve seen that strategy fail more times than we can count.

Phase 1: Quick wins (3-6 months) — Retire unused systems, implement immediate security controls, and complete lift-and-shift migrations for low-complexity systems.

Phase 2: Commercial replacements (6-12 months) — Replace systems where good commercial alternatives exist. This requires business process assessment to ensure the replacement meets actual needs, not just technical specifications.

Phase 3: Custom modernization (12-24 months) — Tackle the complex custom applications that require significant development. For businesses pursuing custom software development, this phase benefits from experienced partners who understand both legacy system migration and modern architecture patterns.

Phase 4: Optimization and integration (ongoing) — Once modernized, focus on integration between systems, process optimization, and leveraging new capabilities the legacy environment couldn’t support.

Data Migration Strategies

Data migration kills more modernization projects than technical complexity. Plan for this carefully.

Data quality assessment: Legacy systems accumulate decades of dirty data. Identify data quality issues early—duplicates, orphaned records, inconsistent formats, missing required fields.

Extract, transform, load (ETL): Build robust ETL processes with extensive validation. Plan for multiple test migrations before the production cutover.

Parallel operation: When possible, run old and new systems in parallel for a period. Write to both, validate consistency, then gradually shift read operations to the new system once confidence is established.

Historical data strategy: Not all historical data needs to move to the new system. Consider keeping the legacy system in read-only mode for historical reference while new transactions flow through the modernized platform.

Team and Resource Planning

Modernization requires specialized skills that many IT departments don’t have in-house.

Legacy system expertise: You need people who understand the old system deeply enough to extract business rules and data relationships. Often this is your existing staff or long-term contractors.

Modern development skills: Building the replacement requires current architecture patterns, frameworks, and security practices. This is where partnerships with application development specialists or leveraging staff augmentation can bridge skill gaps without permanent headcount increases.

Project management: Modernization projects have complex dependencies, business process implications, and change management requirements. Strong PM discipline is essential.

Business stakeholder engagement: The business must stay engaged throughout. Technical teams can’t make business process decisions. Regular working sessions with business stakeholders prevent the “this isn’t what we needed” moment at go-live.

Risk Management During Transition

The modernization process itself creates risk. Plan for it.

Rollback planning: Every migration needs a tested rollback procedure. When things go wrong at cutover, you need the ability to return to the old system within your maintenance window.

Incremental cutover: When possible, migrate in pieces—by business unit, by customer segment, or by functionality. This limits blast radius if issues emerge.

Enhanced support during transition: Plan for elevated support coverage during cutovers and the initial stability period. Issues will emerge that testing didn’t catch, and rapid response prevents small problems from becoming business disruptions.

Communication strategy: Keep stakeholders informed—both internal users and external customers if the system affects them. Manage expectations around functionality, performance, and the learning curve with new systems.

Compliance and Regulatory Considerations

The regulatory landscape around cybersecurity has fundamentally shifted over the past several years. Legacy software vulnerabilities now create direct compliance exposure in ways they didn’t previously.

SEC Cybersecurity Rules (2024)

Public companies now face disclosure requirements around material cybersecurity incidents and must describe their cybersecurity risk management processes. Legacy systems with known vulnerabilities represent identifiable risks that boards and executives must address.

We’re seeing this drive prioritization for financial services clients. When you have to disclose your cybersecurity posture publicly, running business-critical functions on unsupported platforms becomes untenable from a governance perspective.

HIPAA and Healthcare

The HHS Office for Civil Rights has made it clear that legacy systems don’t get a pass on HIPAA requirements. If your systems can’t meet encryption standards, can’t produce required audit logs, or can’t implement proper access controls due to technical limitations, you’re in violation.

OCR settlements increasingly include required security measures around legacy system modernization. They’re not just fining organizations; they’re mandating technical corrections with oversight.

PCI DSS 4.0

Payment Card Industry standards have gotten significantly more prescriptive. PCI DSS 4.0 includes specific requirements around multi-factor authentication, encryption, logging, and incident response that many legacy payment systems simply can’t meet.

The transition period is ending in 2026. Organizations processing card payments on legacy platforms need to either modernize or stop processing cards. There’s no middle ground.

State Privacy Laws

California’s CPRA, Virginia’s CDPA, and similar laws in a dozen other states create requirements around data security that legacy systems often can’t satisfy. Specifically:

• Data minimization requirements that legacy systems designed to retain everything violate
• Access and deletion rights that legacy architectures can’t efficiently support
• Breach notification timelines that require detection and investigation capabilities legacy systems lack
• Security requirement assessments that expose known vulnerabilities

The patchwork of state laws creates complexity, but the underlying theme is consistent: if you can’t secure the data properly, you shouldn’t be collecting it.

Industry-Specific Requirements

Defense contractors face CMMC (Cybersecurity Maturity Model Certification) requirements that mandate specific technical controls. Legacy systems routinely fail CMMC Level 2 assessments, which blocks organizations from bidding on DoD contracts.

Financial institutions face GLBA, SOX, and various regulatory requirements from OCC, FDIC, and the Federal Reserve around technology risk management. Examinations increasingly focus on legacy system risk.

The common thread: regulators are no longer accepting “it’s a legacy system” as justification for security weaknesses. The compliance grace period for legacy technology is over.

Frequently Asked Questions

What are the security risks of using legacy software?

Legacy software creates security risks through unpatched vulnerabilities that attackers actively exploit, incompatibility with modern security tools, lack of current encryption and authentication standards, and accumulation of security weaknesses over time. These systems become entry points for ransomware, data breaches, and lateral movement within networks, with average breach costs exceeding $4.8 million plus regulatory penalties.

How long can we safely continue using legacy software?

There’s no universal safe timeline—it depends on your specific risk factors. Systems that are network-isolated, process non-sensitive data, and have strong compensating controls can potentially operate longer. Internet-facing systems or those processing regulated data should be modernized within 12-18 months of reaching end-of-life. The key question isn’t “how long can we use it” but “what’s our risk tolerance and what’s the cost if we’re wrong?”

What’s the difference between legacy software and outdated software?

Outdated software is behind on updates but still within its support lifecycle—you can patch it, you just haven’t yet. Legacy software has reached end-of-life with no patches available regardless of what you do. Outdated software represents a process problem you can fix; legacy software represents an architecture problem that requires modernization.

Can we just keep our legacy systems isolated from the internet?

Network isolation reduces risk but doesn’t eliminate it. The 2025 Verizon DBIR found that 38% of breaches involving isolated legacy systems started from insider threats or lateral movement after initial compromise elsewhere. Isolation also creates operational challenges around updates, monitoring, and integration. It’s a valuable mitigation tactic but not a long-term strategy.

What’s the average cost to modernize a legacy application?

Cost varies enormously based on complexity, but typical ranges for mid-market companies are $200K-$800K for straightforward commercial replacements, $500K-$2M for custom application rebuilds, and $2M-$10M+ for complex enterprise systems. These figures include discovery, development, migration, and stabilization. The real question is ROI: what’s the cost of not modernizing when you factor in security risk, operational inefficiency, and opportunity cost?

Should we modernize incrementally or do a complete system replacement?

Incremental modernization typically carries less risk and spreads costs over time, making it preferable when the legacy system is complex or deeply integrated. Complete replacement makes sense when the legacy system is relatively standalone, when good commercial alternatives exist, or when the architecture is so problematic that incremental fixes don’t address fundamental issues. Most organizations find that a phased approach focusing on highest-risk components first provides the best balance.

How do we maintain business continuity during legacy system modernization?

Successful modernization maintains continuity through parallel operation (running old and new systems simultaneously during transition), phased cutover (migrating segments rather than everything at once), comprehensive rollback planning, extensive testing with real business scenarios, and elevated support coverage during transitions. The key is accepting that modernization takes longer than you’d like but forcing speed creates risk that undermines the entire effort.

What security controls should we implement immediately for legacy systems?

Immediate priorities are network segmentation to isolate legacy systems with strict firewall rules, enhanced monitoring and alerting to detect exploitation attempts, application whitelisting to prevent unauthorized code execution, virtual patching through WAF or IPS where applicable, and immutable backups tested quarterly. These controls don’t fix the underlying vulnerability but significantly reduce exploitability and impact while you plan modernization.