A fix, a workaround and a control are different things

“Patch” gets used for anything that makes a problem go away. For a Sybase estate, and for the security and audit teams that review it, three different responses are involved:

• An SAP-issued correction changes the product itself.
• A workaround changes how the product is used: a configuration change, a restriction on a feature, or a change in the application layer.
• A compensating control reduces exposure around the product, through network segmentation, tighter access, privileged access management or monitoring.

All three have a place in managing risk. They are not interchangeable, and auditors and regulators may treat them differently.

What changes when vendor support ends

With active SAP maintenance, your security team learns about a vulnerability from SAP’s security notes, contains it while it assesses the impact, and closes it with an SAP correction. When maintenance ends, so does the entitlement to new SAP patch releases and the binary files that carry them. Knowing and containing are still possible: public vulnerability information exists, and good controls reduce how reachable a system is. Fixing is the capability that changes, because the corrective code stays with SAP.

Controls have limits on a central database. A payments or core banking database exists to be reached by many other systems, so isolation only goes so far. Each control also has to be designed, documented, tested and kept current as the estate changes.

The practical test is a new engine-level vulnerability disclosed overnight. Under vendor support, the route to a fix is known: a security note, then a patch or an emergency bug fix, then escalation if your configuration needs more. Without it, the honest answer may be that a workaround is being developed. That can be acceptable for some systems, if the business decided so in advance and recorded it in the risk register with an owner and a review date.

The maintenance burden of a workaround

An SAP correction is built against the source, tested across supported configurations, documented, and carried into later releases. When you upgrade, it comes with you.

A workaround from an independent provider without source access usually changes something around the defect rather than the defect itself. That can work, but its cost recurs. It has to be documented and owned. It has to be retested after every operating system update, configuration change, application release or hardware move. Over several years, workarounds accumulate and have to be tested against each other. When the system is eventually upgraded or migrated, each one has to be understood and unwound.

The legal question

If a provider operates without SAP access, the questions are how its fixes are developed and what rights allow them to be used in your environment. There have been court cases on third-party support and intellectual property. If a provider crosses an IP or contractual boundary, the customer can be exposed too, through disruption to the service or questions about the software it runs. Using a third-party provider is not in itself a breach. Contract terms, jurisdiction and what the provider actually does all matter, and describing a fix as “independently authored” doesn’t settle the question.

Before signing with any provider, including us, get written answers to these:

1. How are fixes developed, and from what materials?
2. What rights does the provider rely on to access, modify or distribute anything that touches SAP’s software?
3. Where will that work run in your environment, and under whose licence?
4. If the provider and SAP end up in a dispute, who carries the risk, and what does the indemnity cover?
5. What would it cost to return to vendor support later, and what would have to be undone?

Where Insight fits

With Insight, every fix comes from SAP itself, through SAP’s own maintenance and release process, under tdglobal’s back-to-back arrangement with SAP. Customers keep access to new releases, patches, emergency bug fixes and support content, and their right to apply them rests on SAP’s own terms rather than on a third party’s interpretation. The one limit applies to every provider: once SAP stops producing fixes for an older release, nobody can supply one. In that case, tdglobal tells the customer plainly and helps them choose between upgrading to a release SAP still maintains and putting compensating controls in place, documented as controls rather than presented as fixes.

‍