Patching is not a security strategy — it is a change-management decision with financial, operational, and risk consequences.
CIOs already know that today’s threats move quickly. And compounding this challenge is the growing use of automation by attackers to identify and exploit weaknesses.
Vice President for Cyber Security and Products at Spinnaker Support.
Much of the early work that once took time now happens almost instantly. When a new vulnerability becomes public, attackers now validate it against real software estates within days, sometimes hours, using automation and AI-driven discovery techniques that surface exploit paths far faster than human testing ever could.
This compresses the window in which organizations can respond, even when they run disciplined patching processes.
Enterprise systems, however, operate on a different timeline. ERP platforms evolve slowly because they sit at the center of financial, operational and supply-chain processes. Even minor updates can affect integrations, reporting logic or custom extensions built up over many years. By design, these systems change only when it is safe to do so.
So what happens when the mechanisms of attack accelerate, but the mechanisms of enterprise change remain cautious and slow? The result is a widening gap between how risk is created and how it is mitigated.
Attackers move against reachable weaknesses across identity, configuration and architecture, while patches only ever address a subset of known flaws in vendor code. That mismatch means exposure remains, no matter how fast updates are applied.
A patch removes a specific vulnerability, but attackers exploit underlying weaknesses that can span many vulnerabilities, which is why fixing one CVE rarely closes an entire attack path.
The problem with patch-centric security
Patching has become the default response to security risk, but in ERP environments it is a blunt and increasingly fragile tool. These systems are built from layers of custom code, older modules and tightly coupled integrations that no standard vendor model reflects, making updates inherently unpredictable.
As pressure to patch faster has increased, many organizations have been forced to accept more operational risk in exchange for perceived security. Systems break, interfaces fail and critical workflows are disrupted, even while large parts of the environment remain unpatchable or unsupported.
ERP platforms are not designed to move at the speed of modern vulnerability discovery, yet patch-first security assumes that they must.
Why CIOs are adapting defense-in-depth for application landscapes
Many CIOs are revisiting defense-in-depth and re-interpreting it for complex application environments rather than just networks or endpoints. This is not because they want to move away from patching, but because patching has become a high-stakes liability decision.
If a rushed update damages a core ERP process, the vendor absorbs much of the blame. If a known weakness is exploited before a patch is applied, the organization owns the failure. That imbalance makes reliance on a single control increasingly risky.
Defense-in-depth offers a way to spread that risk. Rather than depending on patches alone, it ensures the organization has more than one line of protection during the long periods in which updates cannot be applied, or do not yet exist.
In practice, it is less about accumulating tools and more about shaping the environment so that no single control acts as a silver bullet.
Zero Trust models assume breach, require continuous verification, and minimize blast radius. Patching plays a role, but its contribution is narrow:
– It addresses yesterday’s identified flaw, not today’s unknown or tomorrow’s zeroday
– It does nothing to improve identity governance, segmentation, authentication strength, or detection capabilities
– It requires dependence on a single vendor’s timelines and disclosure practices
Defense in Depth, by contrast, supports Zero Trust by adding compensating layers: hardened configurations, privilege reduction, lateral movement controls, monitoring, and rapid mitigations independent of vendor patch cycles.
For ERP systems, this begins with a stronger configuration baseline, clearer insight into how weaknesses play out in the organization’s own estate, and response processes that reflect how the system actually operates.
Unlike patching, which produces a narrow, one-time reduction in risk, these controls compound over time, reducing whole classes of attack.
Hardening the parts the organization controls
Configuration hardening is one of the most effective first steps. Many weaknesses stem from settings or privileges that were never fully revisited, or from interfaces left active out of habit rather than necessity.
These are structural weaknesses in how the system is operated, not defects in vendor code, and they will never be eliminated by patching. It is also one of the few areas where CIOs have complete agency.
Hardening does not depend on release cycles or development roadmaps and can be improved incrementally, reducing risk immediately.
Understanding vulnerabilities in your own estate
Visibility forms the next layer. A vendor advisory may describe how a flaw works in a standard product, but few organizations operate anything close to that. Custom workflows, older modules and third-party extensions all influence how a weakness is actually exposed.
CIOs therefore need analysis grounded in their own environments. Knowing whether a vulnerability is genuinely reachable, how custom code alters its addressability and whether existing controls already reduce the risk helps teams focus on what matters most, rather than reacting to severity scores that may not apply to their estate.
Response capabilities aligned with how the organization operates
When something does go wrong, how your organization responds is the defining test of resilience. Teams need clarity on which processes are affected, how data moves across the environment and where isolation can occur without unnecessary disruption. A layered security model supports this.
A hardened baseline limits exposure, better visibility shortens investigation time, and a response process designed around the organization’s architecture enables faster, more confident decisions.
Governance, compliance and control of the roadmap
Regulators and auditors expect evidence of ongoing oversight rather than reassurance that systems are simply up to date. Frameworks such as ISO27001 make this explicit by treating patching as only one small element of Protect and Govern, alongside identity, detection, response and recovery.
They want to see how risk is managed between major updates and how compliance is maintained when vendor roadmaps do not align with business priorities.
For many CIOs, the underlying issue is control. They need the flexibility to decide when an upgrade is appropriate, how to sequence change and how to demonstrate compliance without being pushed into disruptive timelines.
A layered, defense-in-depth approach supports this by strengthening the measures the organization can shape directly.
A steadier foundation for long-term resilience
Resilience is increasingly something constructed within the environment rather than delivered through patches alone. CIOs still rely on vendor fixes, but they complement them with controls they own: configuration choices, estate-specific insight and response processes tailored to how their systems operate.
Building confidence through independence
This move towards independence does not mean jettisoning your vendor, but it does mean strengthening the layers of protection that sit alongside vendor support. In many environments this also means being realistic about where patches are delayed, unavailable or no longer produced, including in legacy or heavily customized systems.
Many organizations therefore work with third-party support partners who bring a platform-specific view and provide assurance, expertise and continuity across these estates. These relationships give CIOs options to maintain compliance, manage risk and keep systems stable without relying on a single route to protection.
The end product is a more confident and cost-balanced operating model. Threats may move quickly and vendor schedules may not always align with your own, but your organization is no longer defined by either.
Instead, security aligns with your operational reality, shaped by continuity, control and the freedom to make decisions on your own timeline.
We’ve featured the best online cybersecurity course.
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro
https://cdn.mos.cms.futurecdn.net/cx5grhZaQenj2jCrCzkbJK-970-80.jpg
Source link
