SAP’s 2027 deadline for mainstream maintenance on core Business Suite 7 applications is generating a lot of noise about migration timelines and the costs associated with moving to S/4HANA. Extended maintenance remains available through 2030, but as a security professional, the most pressing question for me is why so many enterprises still feel like they have no real choice in the matter. Vendor dependency is becoming a security risk in its own right, and most organizations have not yet built the frameworks to recognize it.

When dependency becomes a security risk

Typical security concerns focus on vulnerabilities, threat actors, ransomware, and compliance requirements. Vendor dependency is rarely at the forefront of security strategy. Yet, excessive reliance on a one provider can create risk in the same way as any other infrastructure concentration.

Following Broadcom’s 2023 acquisition of VMware, customers found out just how quickly they can become exposed when a major technology supplier changes pricing, licensing, or strategy, and how little say they have in the matter. The result of these decisions involves significant costs, increased operational risk, and a fear of change, diminishing innovation.

The consequences of that exposure can be severe. In 2017, Merck suffered an estimated $1.4 billion in damages after the Russian-led NotPetya attack infiltrated through a compromised software update mechanism, affecting 40,000 Merck devices and paralyzing global operations. The legal dispute with insurers over whether the losses were covered ran until 2024. Although this attack didn't target Merck directly, it moved through systems they depended on but didn't control. The operational damage was immediate. That’s the nature of concentrated vendor risk; the decision that creates the exposure is often made long before the incident occurs.

Recent research surveyed more than 2,000 CIOs and senior IT decision-makers at large US and UK enterprises running IBM, HCL, VMware/Broadcom or SAP at meaningful scale. Among them, 434 ran SAP as their primary enterprise software platform. The findings reveal nearly 70% of US SAP customers would feel exposed if SAP were acquired, sold, or wound down. This reinforces concern that an acquiring organization would prioritize short-term returns over long-term product development, effectively reducing customer choice and forcing decisions that may not align with business objectives. Nearly two-thirds report their technology strategy shaped more by vendor release cycles than their own business priorities. That is a significant transfer of control.

The myth: Security only comes from vendor patches

One assumption I encounter repeatedly is that only the OEM can properly address vulnerabilities in their software, and that remediation requires vendor-issued patches tied to active subscriptions. It’s a form of blind trust that is rarely examined, and it is one that vendors have little incentive to correct. Security teams will often accept a patch’s effectiveness when it comes from a vendor, even when they have limited knowledge of what was changed or how it addressed an issue. That assumption becomes even more questionable when the software is absorbed through mergers, acquisitions, or years of inherited ownership.

Closely linked is the assumption that maintaining OEM support and staying on an n-1 version is the only path to regulatory compliance. While patching remains an important security control, the reality is this mindset can oversimplify how risk is actually managed. More flexible, risk-based approaches can meet compliance requirements without strict vendor dependency.

I’ve seen this play out across sectors. When security teams can’t quantify and communicate risk in terms that translate to business decisions, the default is to defer to the vendor’s framework. That framework was designed to serve vendors interests, not organizational ones. Engineering cultures that favor routine patching over more nuanced, risk-driven strategies aren’t wrong to value simplicity, but they are often optimizing for what is easy to audit rather than what actually reduces exposure.

Most security leasers I speak to understand this dynamic at some level. OEMs are commercially driven entities. Their support timelines, subscription models, and upgrade cycles are designed to serve shareholder value. That is not a criticism, it is simply a fact that should inform how enterprises approach dependency.

Compliance as a route to security

The same pattern appears in how organizations think about compliance. Most compliance frameworks are designed to ensure organizations can demonstrate effective risk management. They do not mandate a specific software version or require upgrades on a vendor’s commercial timeline. The requirement is to show that risk is understood, controlled and documented.

Many organizations assume that maintaining OEM support and operating on a vendor-approved version is the only way to satisfy regulatory requirements. However, most compliance frameworks are designed to ensure organizations can demonstrate effective risk management, not blind adherence to a particular vendor roadmap.

Compliance frameworks generally require organizations to identify risks, implement appropriate controls, document decisions, and demonstrate due diligence. They do not typically mandate a specific software version or require organizations to upgrade according to a vendor's commercial timeline. The key requirement is the ability to demonstrate that your risk approach is reasonable and a lack of negligence in risk management.

Because compliance audits often favor simple, measurable outcomes, and because many audit firms are incentivized to apply standardized frameworks that are more cost-effective, many organizations default to a "patch-and-upgrade" approach. The average cost of a US SAP customer's most recent vendor-mandated change was $12.34 million. Organizations are absorbing that cost not because the business case is clear, but because the compliance optics are. Running the latest supported version is easy to explain in an audit. A risk-based rationale requires the right skills and resources coupled with more documentation, more context, and more organizational maturity to defend, so it rarely gets chosen.

The result is that compliance frequently becomes a substitute for security-first approaches.

Why organizations struggle to take a risk-based approach

Some managed service providers may also be reluctant to move away from a patch-centric model as it aligns with predictable margins and lower-cost delivery models. Adopting a risk-based approach can be seen as commercially disruptive at face-value, the reality is different.

These dependencies also compound at a systemic level. When multiple major banks or critical infrastructure operators rely on the same underlying platform, a single vendor's commercial decision creates shared exposure across an entire sector. That is a resilience question, a sovereignty question, and increasingly a geopolitical one.

The industry has operated under an OEM-controlled narrative for over two decades. That has shaped generations of engineers and security professionals to treat vendor dependency as a given rather than a choice. The assumption that security, compliance, and support must come from the OEM is so deeply embedded that it is rarely examined, even when its limitations become visible after a significant incident.

Resilience means going beyond upgrades

The SAP deadline is ultimately exposing a much larger issue than ERP modernization. It forces organizations to examine how much control they truly have over systems and whether their security strategies are driven by business priorities or vendor-led timelines.

In an interconnected world, resilience depends on reducing unnecessary dependencies and maintaining flexibility, and therefore, choice.

A risk-based approach provides a more pragmatic and effective path forward. It recognizes that risk can never be fully eliminated and instead focuses on identifying, assessing, and mitigating risk to an acceptable level.

This approach enables security leaders to prioritize what matters most, balancing security with business objectives within operational constraints. This ensures that organizations can demonstrate due diligence rather than striving for unattainable absolute security.

The SAP deadline is a useful forcing function. The lesson extends well beyond a single vendor. The organizations that come out of this in the strongest position will be the ones that used the moment to genuinely examine who controls their technology decisions. Those that don't will keep deferring to someone else's roadmap, and paying accordingly.