SAP's EU Antitrust Settlement and the Cloud Security Incident Response Playbook
Here's something most security teams don't think about until it's too late: your ERP vendor holding a gun to your maintenance renewal can be a genuine operational risk. The European Commission just proved it, wrapping up its investigation into SAP after the company agreed to abolish reinstatement fees and cap back-maintenance charges for legacy products.
On the surface, this is a competition story. SAP was making it prohibitively expensive for customers to walk away from their support contracts and shop around for third-party alternatives. The EC said that behavior restricted competition in the aftermarket for maintenance services, leaving European businesses with fewer choices and higher costs. SAP's response? They agreed to stop charging those punitive reinstatement fees, capped the back-maintenance penalties, and clarified that customers can freely choose different support providers.
But if you're a security or compliance analyst reading this, the real story is what it exposes about vendor lock-in as an incident vector. Most cloud security incident response playbooks I've reviewed treat vendor failure as a footnote. This settlement should force that conversation into the main text.
The Investigation: How SAP Restricted the Aftermarket
The European Commission launched its formal investigation in September 2025, targeting SAP's behavior in the aftermarket for maintenance and support services across Europe. The concern was specific: SAP was using its market position to make third-party support providers less attractive, effectively creating a moat around its own maintenance revenue.
In October 2025, SAP published what it called "commitments" — essentially a voluntary agreement to change its practices. The language was careful. SAP said the commitments aimed at "improving the financial attractiveness for customers who wish to reinstate SAP maintenance and support services," which is corporate speak for: we'll make it cheaper to come back if you leave us.
The final agreement, confirmed by the Commission on July 9, 2026, includes four concrete commitments:
- Eliminate reinstatement fees entirely for customers returning to SAP support after a gap.
- Cap back-maintenance fees, reducing the penalty for lapsing customers who want to rejoin.
- Clarify support conditions so customers can freely select different maintenance providers and support levels.
- Improve transparency through better guidance, training, and independent oversight of on-premise support operations.
These commitments are legally binding and will remain in force globally for ten years. That's significant — it means SAP can't just revert to the old practices once the Commission looks away.
Building a Cloud Security Incident Response Playbook Around Vendor Lock-In Risks
This is where I want to get specific, because most incident response frameworks completely ignore what happened here.
A cloud security incident response playbook should account for vendor lock-in as a potential disruption scenario. Not the dramatic "vendor goes bankrupt overnight" kind of lock-in, but the slow-burn version: your vendor makes it financially painful to switch providers, so you stay even when their support quality degrades or their security posture becomes inadequate.
The SAP-ECC situation is a textbook case. Mainstream support for ECC ends in December 2027. After that, customers can extend maintenance until December 2030 by paying an additional 2% on their maintenance fees. But here's the kicker: Gartner data from Q4 2024 showed only 39% of the roughly 35,000 worldwide ECC customers had actually purchased or subscribed to S/4HANA licenses. That means 61% — over 21,000 organizations — are sitting on legacy ERP systems with a hard support deadline approaching and limited migration progress.
When you're one of those organizations, the vendor's ability to charge steep reinstatement fees becomes a coercive tool. You can't easily bring in a third-party provider like Rimini Street without facing financial penalties that make the switch unviable. That's not a market outcome — it's a lock-in mechanism, and it creates real security exposure.
Your incident response playbook should include vendor lock-in as a risk category. Specifically:
- Assessment phase: Document which critical systems have maintenance lock-in and what the financial cost of switching would be.
- Detection phase: Monitor vendor support quality, security patch cadence, and responsiveness as early warning indicators.
- Response phase: Pre-negotiate third-party support agreements so you can activate them without penalty when vendor performance drops below acceptable thresholds.
- Recovery phase: Maintain documented migration paths and test them regularly, not just on paper.
The ECC Support Cliff: Numbers That Matter to Security Teams
Let's talk about the actual numbers, because they're uncomfortable.
Of the approximately 35,000 ECC customers worldwide, only about 13,650 had moved to S/4HANA by Q4 2024. That leaves roughly 21,350 organizations running on a platform whose mainstream support ends in less than two years. These aren't small companies either — ECC runs the back office for many of Europe's largest enterprises.
Kingfisher, the retailer behind B&Q and Screwfix in the UK, made a public statement at a Gartner conference last year explaining their decision. They chose Rimini Street to support ECC 6.0 because they saw "insufficient value in migrating to SAP S/4HANA." That's a direct admission: the migration path wasn't compelling enough to justify the cost and disruption, so they went third-party.
For security teams managing these environments, this creates a specific compliance challenge. Third-party support providers may not offer the same level of security patching, vulnerability disclosure timelines, or audit documentation that your compliance framework requires. If you're operating under ISO 27001, SOC 2, or any regulated framework, you need to verify that your third-party maintenance provider meets the same security obligations as the original vendor.
The EC's decision helps here. By clarifying that customers can freely choose different support providers, it removes the financial penalty that was preventing organizations from exercising that choice. But the security team's job doesn't end there — you still need to validate that any third-party provider you bring in can meet your compliance requirements.
What This Means for 365 and Cloud Migration Security
The European Commission's executive VP Teresa Ribera made a point that security teams should pay attention to. She said the decision gives customers "more freedom to choose maintenance and support services without unfair restrictions" and noted that the commitments "should serve as a warning against practices with similar effects in the cloud markets, where customers are increasingly moving."
That last part is critical. SAP's on-premise maintenance practices were the subject of this investigation, but Ribera explicitly connected them to cloud markets. The concern is clear: if vendors can use similar lock-in tactics in cloud environments — where data migration is often more complex and costly than on-premise support switching — the security implications multiply.
For organizations managing Microsoft 365 environments alongside SAP systems, this creates an interesting dynamic. Your 365 tenant is already a cloud-native deployment with its own security posture, compliance framework, and incident response requirements. But if your ERP layer remains on-premise with legacy support constraints, you've got a hybrid security model where one component has genuine vendor flexibility and the other doesn't.
That asymmetry matters for incident response. When you're building your cloud security incident response playbook, you need to account for the fact that different components of your technology stack may have very different vendor flexibility profiles. The 365 side might allow relatively easy provider switching or self-hosted alternatives. The SAP ECC side, post-settlement, now has improved flexibility but still carries the weight of a platform whose mainstream support is ending.
The practical takeaway: map your vendor flexibility by component. Document which systems you can realistically migrate or switch providers for, and which are genuinely locked in. Use that map to prioritize your incident response planning — the systems with the least flexibility deserve the most robust contingency planning.
Enforcement and the Ten-Year Commitment
The ten-year duration of SAP's commitments is worth emphasizing. That's not a voluntary code of conduct that gets updated annually — it's a legally binding agreement enforced by the European Commission. SAP can't simply wait out the investigation and revert to its previous practices.
For security and compliance teams, this duration provides a stable planning horizon. You can make migration decisions based on the knowledge that SAP won't re-introduce punitive reinstatement fees next year. That stability matters when you're evaluating whether to invest in S/4HANA migration now or extend with third-party support through 2030.
SAP's own statement emphasized that its maintenance practices align with "industry standards" and that customers have "a broad range of deployment, licensing, and support options across its on-premise and cloud products." The company also noted that the decision "relates solely to on-premise maintenance policies and does not concern SAP's cloud offerings."
That distinction is important but also somewhat disingenuous. The cloud transition SAP is pushing — toward what they call an "AI-enabled autonomous enterprise" — requires significant investment and organizational change. If customers feel coerced into that transition by on-premise support penalties, the competitive dynamics Ribera warned about could simply migrate to the cloud layer.
The Commission's warning about "practices with similar effects in the cloud markets" suggests they're watching. Security teams should watch too, because vendor lock-in in cloud environments often comes with even higher switching costs than on-premise support.
Action Items for Security and Compliance Teams
Here's what I'd recommend your team do with this information, starting this week:
1. Audit your ERP maintenance posture. Identify which systems are running on legacy platforms with approaching support cliffs. Document the financial cost of switching to third-party providers versus continuing with vendor support.
2. Review your incident response playbook for vendor lock-in scenarios. Does it account for the possibility that a critical vendor makes it difficult to switch providers? If not, add it. The SAP case shows this isn't theoretical.
3. Pre-negotiate third-party support agreements. Don't wait until you need them. Establish relationships with providers like Rimini Street now, understand their security patching capabilities, and verify they meet your compliance framework requirements.
4. Map vendor flexibility across your technology stack. Which systems can you realistically migrate or switch providers for? Which are locked in? Use this map to prioritize incident response planning and migration investment.
5. Monitor the cloud market. The EC's warning about similar practices in cloud markets isn't hypothetical. Watch for vendor behavior that mirrors what SAP was doing — subtle financial penalties, unclear support conditions, restricted third-party options.
The European Commission's settlement with SAP is a competition win. But for security and compliance teams, it's also a reminder: vendor lock-in isn't just a procurement problem. It's an incident response risk, and your playbook should reflect that.