OpenText’s Praveen Patil Kulkarni explains why unpatched legacy systems remain easy targets as AI accelerates cyberattacks.
Some of the most damaging cyberattacks on Indian enterprises do not rely on clever new techniques. They exploit flaws disclosed years ago and never fixed. In banking, manufacturing, telecom and government, systems built to run for decades sit alongside modern cloud applications, often unpatched, poorly monitored and sometimes supported by vendors that no longer exist.
In this conversation with CISO Forum, Praveen Patil Kulkarni, Director – Security, Risk & Governance at OpenText India, explains why so many organizations stop at vulnerability reports without enforcing a remediation deadline. Drawing on the OpenText 2026 Threat Report, he warns that a known vulnerability now means a known exploit, putting legacy systems within reach of almost any attacker, not just sophisticated groups.
AI is making the problem more urgent. As attacks move from AI-assisted to increasingly autonomous, the window between exposure and exploitation is shrinking fast. Kulkarni makes the case for continuous vulnerability management, prioritizing flaws by exposure rather than severity, and using segmentation, tighter access and monitoring where patching is not possible. He also offers CISOs a practical way to frame modernization for boards and names the mistake he sees organizations repeat most often.
CISO Forum: Attackers still succeed with vulnerabilities that were disclosed years ago. Why do known flaws remain exploitable in so many Indian enterprises?
Praveen Patil Kulkarni: When you look at IT and how it’s built, it’s generally designed for functionality. You need to achieve a specific business objective, whether customer-facing or internal, such as automating a process. It’s always been built for functionality, and when you build a stack—hardware, servers, storage, networking, middleware, database, or application—that’s how it’s put together.
When I look at this, I consider not only what already exists or what to upgrade, but also the new stack. For the business team or the IT team, the priority is to get the stack and the application up and running. It depends on who their stakeholders are; they can be either internal or external. In the process, security often takes a back seat. This is not always the norm, and the trend is changing as more checks and balances come into place. But generally, when the IT stack is built, it is put into production for functionality, and security comes later as a post-factor. Once you build a stack, you move on to security configuration checks, vulnerability analysis, and related tasks.
It comes first as a post-factor. Second, if you look at any organization, there are baseline practices you’re supposed to put in place: asset management, configuration management, vulnerability management, and patch management. Those are the baselines, and this is not a one-time activity; it is continuous. Organizations in which the security function is sophisticated and mature consistently follow this. But when you look at organizations in general, there are gaps in this. What happens is that when you take up security as a post facto measure and build the whole system in place, you conduct a vulnerability analysis and identify vulnerabilities. What we’re seeing is that a lot of organizations are now doing this. The second step is that most organizations have now begun conducting vulnerability analyses. I think what is very heartening, at least in the Indian scenario, is that there is no regulatory pressure to conduct a vulnerability analysis.
For example, they say you should do an application security test. So what happens is that you do a vulnerability analysis and have a vulnerability report. What we’ve seen is that a few organizations generally move to the next step, but quite a few organizations stop here. You have a vulnerability report. We’ve seen policies up to here. So when you look at organizational security policies, we need to have a vulnerability analysis.
Very few organizations have now taken the last step: putting a policy in place stating that if a vulnerability is identified, there is a timeline for fixing it. So vulnerabilities could be many. You could have critical, high, or medium; ideally, you should have a policy in place stating that any critical vulnerability identified must be fixed within the next time frame.
Those kinds of policies are missing. So what happens is that, when you do a vulnerability analysis, we’ve seen that all the legacy vulnerabilities, whether it’s an SQL injection, a code injection, or a cross-site scripting, most of them still appear. They can be fixed very, very quickly. But what we generally see is that, though it appears in the vulnerability report, the time taken to fix it stems from a lack of clarity about when to fix it.
They still appear in systems; it is all about implementing a policy, establishing checks and balances, and enforcing remediation. That last part is still not a norm across organizations. So when these vulnerabilities are present, they become an easy playground for your attackers.
CISO Forum: What does the OpenText 2026 Threat Report say about aging systems and end-of-life software? Which findings should Indian CISOs worry about most?
Praveen Patil Kulkarni: When you look at aging systems and end-of-life software, the biggest problem with this part of IT is that you could have multiple applications. Still, for older applications and software, patches are generally not available. So, for you to take preventive action on those vulnerabilities becomes very, very limited. They become a weak point in your cybersecurity posture.
The new applications that come in have all the right integrations and proper security checks and balances, but the older ones are where you have a big problem. Also, in the older applications, authentication is at a lower level. Now you have the new zero-trust methodology and protocols that ensure your authentication and authorization meet the latest security norms, unlike the older ones.
This becomes a weak point and an entry point for attackers. The worry point for CISOs is when you have legacy applications or end-of-life software. Known vulnerabilities mean known exploits. Most access to these exploits is open. So the biggest problem for a CISO is a vulnerability that requires an exploit.
That’s when it becomes really, really dangerous. So the biggest worry for CISOs is that when there is an old system and a known vulnerability, there is a known exploit. That means the time between exposure and attack becomes very, very short. Also, a bigger problem for the CISO is that you don’t need an APT to attack you. Anybody can attack you because the exploit is already there. Anybody can use any run-of-the-mill attack tool to compromise you. That means the number of potential attackers who can look at compromising the IT integrity of your organization goes up.
Most attackers use this as an entry point. Your legacy system could be sitting somewhere for compliance purposes. You may have it running, or it could be part of an older organization that you’ve taken over, but your policy says seven years; I need to run it. So you’re running it. But if somebody compromises that system, he can move laterally into your main system. It becomes an entry point for CISOs and a source of concern for them.
CISO Forum: Many Indian organizations run critical systems in banking, manufacturing, telecom, and government that were built to last decades. How does a long technology lifecycle quietly enlarge the attack surface?
Praveen Patil Kulkarni: When organizations have been running for a long time, they accumulate many flavors of IT: hardware, operating systems, middleware, and applications. Over time, the rate of change keeps getting shorter. The technology platforms on which we architect and run IT are changing. So, when you have a mix of new and old, it can lead to various issues. New systems use the latest code. That code is not a single code. It includes components written by the organization, third-party code, and integrated components. In newer applications, all of these are the latest.
Because newer code uses current development methods and security is integrated into the CI/CD pipeline, it is more secure. Its integrations also use the latest secure protocols and integrate with security tools such as SOC and EDR.
Security tools manage and monitor these systems. Legacy systems do not have that. Earlier, software was built only for functionality. Over the years, cybersecurity has become critical due to the increasing number of attacks. In legacy software, the code was not designed to be secure, and all components are end-of-life. There is another facet to this problem: in an acquired application, the best-case scenario is that the organization is still ongoing. Then the organization is still there, and there may be a network issue from his end.
Primarily, when you look at newer applications, the code is new. Organizations now have application security built into the CI/CD pipeline, so the code that comes out is fairly secure. Integrations use the latest protocols, which are again secure. They also integrate with security monitoring tools. When you look at legacy software, all of this is not there. The code earlier was written for functionality. Security in code was not there 10, 15 years ago, or 15, 20 years ago.
Another problem is that when you have a legacy application within your organization, the best-case scenario is that the company is still operating. Then the OEM that supplied the software is still operational. If a vulnerability is identified, you can reach out to the organization, and they can see what code changes are needed to fix it. Or, if there is a third-party component in the code, they can update it and give it to you.
There is a middle ground: the company is still there, but the software is end-of-life. Then development activity on that software will be limited. If you go with a list of vulnerabilities, they may not fix all of them. They may fix a couple, and for the others, they would fix the critical ones and leave the medium- and low-priority ones out.
The biggest problem is when the company is no longer operational. If an organization has been in operation for 50-odd years and its applications are 20-plus years old. The organization that supplied you is no longer operational; fixing that vulnerability becomes a problem. Patching is no longer an option.
What you will then need to do is determine what kind of control to place in front of the application to secure it. Another interesting scenario is that what is secure today, as is, with no change, may not be secure tomorrow. The reason is that researchers are looking for vulnerabilities and new ways to compromise systems, while attackers are looking for new ways to exploit them. An application today may be clean, but a month later you may suddenly see CVEs being published for it.
As your IT landscape grows and your configurations keep changing, the scale of your attack surface increases. With older systems, the process may not have been that good, even if there is now a documented process and every change manager needs to go through it. When you look at a legacy system as it is, there were some 20-odd changes made to it; you do not know what is and what was. So it becomes difficult to identify your weak points. Integration is part of that.
One of the biggest problems with legacy systems is that when you try to plug one into something new, the newer systems, architectures, and integration protocols have already changed. So when you look at an older system, you have to do what is called a custom wrapping of it. That wrapper becomes the most vulnerable part of it. And when you upgrade your system, the wrapper needs to be redone. These integration points, or where your APIs are talking to each other, especially with older systems, become a big point. I did not mention authentication: when you look at legacy systems, authentication is still done in older ways. Some of these legacy systems also do not integrate with your latest monitoring tools, whether a SOC or a VDR is in place. If you cannot monitor your systems, you cannot secure them. These are the kind of problems that one would have.
CISO Forum: Where does technical debt turn into security debt? Which blind spots are most often missed: unsupported operating systems, shadow assets, unmanaged third-party components, or something else?
Praveen Patil Kulkarni: One of the primary bedrocks of cybersecurity is asset management. If you don’t have visibility into all the IT assets within an organization, the situation becomes unmanageable. Shadow IT accentuates that, especially when past projects outlive their intended lifespan. They were supposed to be decommissioned, but decommissioning requires effort, time, and money.
These systems are therefore not decommissioned for whatever reason. You could have test systems or POCs that you put in place for a vendor, and they remain on a system with an external-facing IP. All of this creates and increases your attack surface. Another big problem is unsupported software, legacy systems, and old systems that cannot be patched, can be patched only to a limited extent, or are not monitored. Third-party components are also a major issue, especially when they are old. The biggest problem there is the visibility of the source: where did this application come from, what is the credibility of that source, and what vulnerabilities does it currently have while running in production in your systems? Undocumented integrations are a big problem, especially when you take an old system and try to integrate it into the new architecture using custom wrappers. That is a clear problem.
Another issue with old systems, from an identity and access management perspective, is that the organization changes every year. People move out, new people come in, and people change roles. So you’ll always have identities that can either be orphan identities or identities that don’t have the right set of policies in place.
Sometimes vendors are also an internal axis. As you scale up time, the problem becomes exponential. If you have external vendors with access to your systems and you no longer work with them, but that access persists for whatever reason, it can become a big problem. And I go back to my point that if you don’t monitor, then you cannot secure. One of the biggest problems with these systems is that most of them cannot be properly monitored, making them difficult to secure.
CISO Forum: Is AI creating new attack methods, or just making old ones faster and better targeted? What does this mean for a team still running unpatched legacy systems?
Praveen Patil Kulkarni: There is a methodology cyber attackers use, and it has multiple steps. You do not need to follow all of them; a subset can still compromise a system. Over the last two to three years, we saw AI emerge from an attack perspective. First, we saw AI-assisted attacks, where attackers used AI for small scripting, malware, code, and a few exploits. Last year, we saw AI-augmented attacks, where attackers used AI for recon, both active and passive, and to develop malware and payloads.
The trickiest part of a cyberattack is delivery and exploitation. If the victim does not double-click, the payload or backdoor does not execute on the system. There are multiple ways to do it. With AI, this process was iterative, reducing the time to find the right delivery and exploitation method. As we looked at AI-augmented attacks, AI agents began running many of these steps, including privilege escalation and lateral movement.
Quite a bit of the cyberattack is now automated and controlled. What is especially worrying this year is the shift toward autonomous AI attacks, in which AI agents can observe the software stack, identify zero-day vulnerabilities, and exploit them. In some cases, we have seen them bring down whole systems. The attack methodology remains the same, but with AI, the time is shrinking.
The time to attack is shrinking, which means the time to defend is narrowing for organizations. In the context of legacy systems, an attacker using an AI tool can gain access very quickly. Because of that, exploitation is now fast and cheap, especially when the system already reflects what it has learned.
Your attack becomes very fast, and because it is already pre-built, you do not need to spend time. So it becomes really, really cheap. Also, the chances of an organization running a legacy system getting attacked are now very high. That is our perspective on these attacks on legacy systems.
CISO Forum: Phishing, reconnaissance, and exploit development are becoming faster and harder to detect. At what point do scheduled patch cycles stop being enough?
Praveen Patil Kulkarni: Patching is never redundant. Asset management, configuration management, vulnerability management, and patch management are fundamental to cybersecurity and will remain so.
How much time are you taking to patch? A failure occurs when the time to patch exceeds the time to attack. If an asset cannot be patched, put a compensatory control in place. For zero-day vulnerabilities, do you have a system in place to address attacks that exploit them?
Use a system that can address these attacks exploiting zero-day vulnerabilities through behavioral analytics or similar methods. If an attacker is using compromised credentials, there is no vulnerability; the credentials themselves become the vulnerability. Patching can fix vulnerability, but if credentials are lost due to phishing or human error, it cannot be fixed. That requires a different approach.
The biggest advantage of patching is that it stops cheap exploitation at scale and automation. From an AI perspective, when vulnerability is known, the pace at which you can exploit it is high. For cybersecurity experts, identifying vulnerabilities and patching them reduces your attack surface and narrows the pool of potential attackers.
If you can fix known vulnerabilities, most lower-end attackers will not be able to compromise you, and then you need to worry about your APTs and higher-order threat actors.
CISO Forum: Why should enterprises move from periodic patching to continuous vulnerability and exposure management? What does that look like in practice for a mid-sized Indian company?
Praveen Patil Kulkarni: With automated attacks, attackers used automated tools earlier, and now, as AI increases the speed of attacks and the likelihood of exploitation, the ask from the organization is twofold. First, you need an external view of what is visible to an attacker within your organization. Second, you need a view of what is vulnerable within that.
Because the likelihood of exploitation or attack is increasing, the window for vulnerability discovery and patching needs to narrow. Depending on the vertical you are in, different sectors have different cyber exposures. BFSI, government, and the public sector are generally more prone to attacks than other sectors. So, depending on the type of attack and the vertical you are in, the frequency of vulnerability discovery and patching needs to increase.
There is a concept now being adopted by organizations: continuous vulnerability discovery and patching. When vulnerabilities are discovered, organizations are beginning to realize that it’s not necessary to fix all the vulnerabilities at once. Because physically, it’s not possible. Instead, organizations are looking at what vulnerabilities are exploitable.
That is what you fix first. So triage is by exposure, not severity. You can have a very severe vulnerability, but if it is not externally facing, it takes lower priority. When I look at mid-sized companies, it depends on the vertical they’re in. Then the point is: Are you a potential target or not? What is the risk level for your organization and you’re vertical?
Second is: what kind of resources do you have for cyber? If you have an ideal scenario with no budget constraints and all resources at your disposal, an ideal approach would be for organizations to have already a red team and a blue team, with the red team being offensive. The blue team is defensive, so the teams are identifying vulnerabilities and patching them continuously.
In continuous mode, depending on the frequency you set, the other team is finding new ways to exploit those systems. Together, you reduce your attack surface and the number of potential attackers.
Now, I’m going to look at another example where you don’t have all the budgets that you have, and the problem with cyber is resources and the skill set of resources. If you don’t have all these skill sets within your organization but still want to achieve something similar to what I said, you can outsource it to a managed security service provider. They will do it for you at the frequency you request, and they can align remediation timelines to that cadence.
CISO Forum: Some legacy systems cannot be patched or replaced without disrupting operations. What compensating controls work best, such as segmentation, virtual patching, monitoring, or tighter access?
Praveen Patil Kulkarni: When you look at old systems, there are two sets of problems. One is that when a vulnerability is discovered, a patch sometimes takes time to be released. The patch delivery and access itself takes time. And the other, you know, extreme problem is the patch is not acceptable, in the sense that the patch is not available simply because there is no team managing that software.
One of the first things that organizations generally do is put a compensatory control interface. If there are four or five CVEs to address, you can sometimes handle them at the WAF level. Some WAFs would manage those CVEs for you, or you can put an intrusion protection second. What organizations should do is reduce the exposure of their application.
If it’s internet-facing, can the application be taken down? Another way is to harden the application. Next, you look at access: who has access, and you completely restrict it to only those resources that absolutely and critically need access to that application. And when you look at additive access management, there are concepts of least privilege.
So you put that least privilege in place so only those who are authorized and authorized to perform that action are allowed to access and allowed to take those actions only. If that application, though legacy, is still critical, then there is a practice called Privileged Access Management, in which you record every action that occurs on it. So you can do that.
You can enable multi-factor authentication on that application for you, or for your given users. If it contains critical data, you can encrypt that data.
For that portion, you can segment your legacy systems into a separate network, so that even if there is a compromise, the attack doesn’t extend beyond that network. And critically, if those systems can be integrated into your monitoring systems, then they should be. Monitored and managed securely.
CISO Forum: How should CISOs make the business case for modernization to boards that view legacy upgrades as a cost rather than a risk reducer? Which metrics or risk framing persuade them?
Praveen Patil Kulkarni: The first question organizations should ask is: What is this legacy system being used for? For legacy purposes, keep a system active for about 7 years. If the legacy system is used only for reporting, the organization does not need to run the whole system. Instead, organizations can archive the data and use simple query engines to run reports in the same format as the old system.
By doing so, you retire the hardware and operating system, eliminating the vulnerability. The archived data and query engines can run on the newer system. So that vulnerability can be completely avoided. But if the legacy application is active, you cannot archive it. In that case, people can use different approaches.
This is a simple example of a risk-to-cost evaluation an organization can do. If the risk is low and the cost is high, then modernizing becomes unviable. In that case, you put a compensatory control in front of it and run it. But if the risk is high and the cost is low, that makes a case for modernization. I am giving you a black-and-white scenario; there are many reasons in between, but organizations can decide based on the evaluated risk and cost.
CISO Forum: If a CISO in India has one quarter and a limited budget, what three things should they prioritize to reduce legacy-driven exposure? What mistake do you see organizations repeat?
Praveen Patil Kulkarni: The primary mistake organizations make is treating a legacy system as just another IT asset. The risk a legacy system poses is very different from that of a system acquired and put into production last year. So, you cannot categorize or classify a legacy system from a risk perspective the same as the others. It needs a very different classification and, hence, a different set of controls, checks, and balances.
The first is that, to the extent feasible, vulnerability discovery and patching should be done. Along with that, you need to harden in place and put some compensatory controls. The second is reducing exposure to that application, both external and internal. Restrict complete access.
The third part is the data that the application has. Staying with the point of vulnerability, when we look at legacy systems, it’s all about vulnerability management and access to those systems.
If you look at what we drive, we primarily drive around five solutions. One is security operations, and that’s what we do with our ArcSight solution, which monitors everything. It’s a pan-organization tool that manages all operations and security activities. The second, which applies to this conversation, is our application security management using Fortify. We also handle data security with Voltage, identity and access management with NetIQ, and forensic tools such as EnCase.
When I look at the topic we’re discussing right now, I think Fortify, as an application security tool, is very apt for organizations because, whilst most vulnerability management tools just run scans and produce reports, with Fortify, an organization can actually run the whole vulnerability management practice. What Fortify does is not only identify vulnerabilities but also help organizations triage them. So what is important to fix and what is not vulnerability.
For example, we have an AI integration that audits all incoming results and can identify what’s a true positive and what’s a false positive. It’s able to help you triage. It also helps you monitor and manage remediation. If your developers are doing the remediation, you can run the whole governance program, where, let’s say, you have given team 100 vulnerabilities. When it comes back, you know how many were tagged as false positives, how many were fixed, and how many are still running in production. We can make this into a continuous process.
So for a CISO, at any given point in time, let’s say an organization is running 200 applications, he has a real-time dashboard where he knows how many critical vulnerabilities are still there across those 200 applications in production. You might have put a compensatory control in front of it, but it still exposes you to vulnerability. It’s a continuous dashboard. That’s one thing that we do. And the second thing here, which is relevant, is an Adaki solution, which is an identity and access management solution.
It addresses a few of the things that I talked about: authentication, authorization, least privilege, privilege access control management, and zero trust architecture. And lastly, SOC, which is Oxide.
What one organization can do is segment its legacy systems into a separate block, where the security management you apply there is at a higher level than elsewhere. OpenText cybersecurity helps organizations manage all the systems, and we can offer solutions that let you monitor and manage your legacy systems more effectively.
