Warranties are the backbone of any software contract. Yet in many deals, they get buried in boilerplate or swapped away without proper thought. Here is a clear-eyed look at how warranties work in software transactions — and how to negotiate them sensibly.
What a warranty actually does
A warranty is a contractual promise about the state of something — either at a specific point in time, or on a continuing basis throughout the contract. In a software transaction, the supplier is typically making promises about what the software does, how reliably it performs, whether the customer’s use of it will attract third-party claims, and whether it complies with applicable law.
What makes a warranty legally significant — as opposed to a sales claim or a general assurance — is that its breach gives rise to a contractual remedy. The customer does not need to show that the supplier was negligent, or that it acted in bad faith. If the warranty was given and it turns out to be false, the breach exists as a matter of fact. The customer can then pursue whatever remedy the contract provides: correction, price reduction, or, if the breach is serious enough, termination.
This strict-liability character is why warranty negotiations matter. A supplier who agrees to warrant something is agreeing to be held to that standard regardless of how hard they tried, how reasonable their belief was, or what caused the failure.
The core warranties in a software contract
1. Conformance with specification
This is the central performance warranty: the software will perform materially in accordance with its specification or documentation. The word “materially” is there for good reason. Software is complex, and minor bugs or edge-case failures are an unavoidable reality of any deployment. Materiality means the software must do what it says it does in all substantial respects — not that it must be flawless.
The practical issue is rarely the wording of the warranty itself, but what it is measured against. What, exactly, is the “specification”? Suppliers should ensure that the agreed scope is documented with precision. Referencing vague marketing materials or product roadmaps as the specification exposes the supplier to obligations they may never have intended to assume. Customers, conversely, should check carefully that the specification reflects the functionality they were sold — because the contract, not the sales deck, will ultimately define the supplier’s obligations.
For traditional software licences, this warranty is typically time-limited — a period of 90 to 180 days post-delivery during which the customer can raise conformance failures and the supplier must remedy them. For SaaS, the concept is usually replaced by service levels expressed in an SLA: uptime commitments, response times for incidents, and resolution targets. The SLA functions as a rolling, ongoing performance warranty for the duration of the subscription.
What happens when the warranty is breached? This is where the contract needs to earn its keep. A well-drafted agreement should spell out a clear remedy framework: the supplier must correct the non-conformance within a defined period or provide a workaround delivering equivalent functionality. If the issue persists (or cannot be remedied at all), the customer should have a right to terminate and recover relevant fees. A warranty that simply promises conformance, without addressing the remedy, leaves the customer reliant on general damages principles. In practice, those claims are harder to prove and even harder to quantify.
2. IP non-infringement
The supplier warrants that the software does not infringe any third party’s intellectual property rights — typically patents, copyright, and trade secrets. This warranty exists because the customer is in no position to carry out meaningful due diligence on the software’s codebase. They cannot audit every line of code, verify the provenance of open-source components, or assess whether any functionality overlaps with a third party’s patent portfolio. They are entirely reliant on the supplier’s assurance.
The IP warranty is almost always paired with an indemnity: if a third party brings an infringement claim against the customer, the supplier will take over the defence of that claim and cover the customer’s costs and any resulting liability. The indemnity is what makes the warranty practically useful — because the harm the customer faces from an IP claim is not a breach of contract with the supplier; it is litigation with a stranger. The supplier’s indemnity steps the customer out of that exposure.
Two negotiating points consistently arise here. First, customers push for the IP indemnity to sit outside the general liability cap. This is commercially rational: if a successful infringement claim means the customer must stop using the software entirely, the resulting disruption and switching costs will far exceed a liability cap set at, say, one year’s licence fees. Suppliers resist this because uncapped IP indemnity exposure can be very large. A common landing zone is a separate, higher sub-cap for IP indemnity claims — larger than the general cap but not truly uncapped.
Second, suppliers typically include carve-outs to the IP warranty: it will not apply where the infringement arises from the customer’s own modifications to the software, from combining it with other products the supplier did not supply, or from the customer’s use outside the permitted scope. These carve-outs are reasonable — the supplier cannot be responsible for infringement it did not cause — but customers should ensure they are tightly drafted and not so broad as to undermine the warranty in practice.
3. No malicious code
Software contracts frequently include a warranty that the supplier will not knowingly introduce malicious code — such as viruses, ransomware, backdoors, or similar — into the software.
The “knowingly” qualifier is deliberate. Modern software relies on complex supply chains: open‑source libraries, third‑party frameworks, automated dependency updates. Even sophisticated suppliers cannot guarantee that every component is immune from compromise.
An absolute “no malicious code” warranty is therefore commercially unrealistic. What is reasonable is for the supplier to warrant that it will not intentionally introduce malicious code and that it will follow sound development and security practices designed to detect and prevent it.
In practice, this warranty works best when paired with operational obligations: vulnerability scanning, secure development practices, incident notification, and remediation commitments.
4. Compliance with law
Customers often ask suppliers to warrant that the software or service complies with “all applicable law”. Suppliers almost always resist — and with good reason.
What is “applicable” depends on the customer’s industry, how the software is used, and where it is deployed. A single, unqualified warranty can inadvertently turn a software supplier into the customer’s regulatory insurer.
A well-drafted clause should identify the specific laws in scope, tie compliance to the software as built and operated (not as configured or used by the customer) and include appropriate carve-outs where changes in law require product modifications that the supplier commits to make within a reasonable period.
What is usually excluded from software warranties?
Suppliers almost always exclude or disclaim warranties relating to:
- fitness for a particular purpose
- uninterrupted or error‑free operation
- absolute security
- meeting customer business outcomes.
These exclusions reflect commercial reality. Agile delivery models, shared cloud infrastructure, and third‑party dependencies make absolute promises impossible to honour.
For customers, this means warranties should focus on objective, testable standards, not aspirational statements.
Final thoughts
Most warranty provisions only get real attention once something has started to go wrong. The system is not performing as expected, patience is running thin, and the contract becomes the first place everyone looks to understand where responsibility sits. That is when gaps and ambiguities tend to surface.
That is why warranties are worth a proper look before the contract is signed. If you are reviewing a software or SaaS contract and want a pragmatic sense-check on the warranty position, book a free call with our lawyers. We regularly negotiate software contracts for both providers and customers, and we are always happy to talk things through.
