Most technology leaders assume that when they license software or deploy a vendor's hardware, the intellectual property risk stays with the vendor. If a patent holder claims the product infringes their rights, that's the vendor's problem to handle.
The contract you signed is the primary document that determines whether that assumption is true. In most cases, it isn't.
How Technology Buyers Became the Target
In 2011, a company began mailing demand letters to coffee shops, hotels, and restaurants across the country. The letter said: you owe us money for offering your customers Wi-Fi. These businesses didn't build wireless networking technology. They bought a router, plugged it in, and for that, a company they'd never heard of demanded a few thousand dollars per location.
The equipment makers weren't the target. The buyers were.
That targeting logic has accelerated. In 2025, non-practicing entities (companies that exist solely to acquire and enforce patent rights, building nothing) were behind 55.4% of all patent lawsuits filed in the United States. In high-tech, over 90% of patent litigation came from NPEs. Filings jumped more than 20% year over year. These entities increasingly target organizations that don't have the resources or incentive to fight a $4 million federal court defense, because those organizations settle.
The math is engineered to produce that outcome. When a demand arrives at $200,000 and the alternative is $4 million in defense costs, the decision often has nothing to do with whether you did anything wrong.
Why Vendor Contracts Are Written This Way
Vendors draft their standard agreements to protect the vendor. That's not bad faith. It's whose paper it is. A vendor's legal team writes terms that limit exposure across every customer relationship they have. IP indemnification creates real liability and real cost. Carve-outs reduce that exposure. Liability caps limit what they can owe. From the vendor's side, this is rational risk management.
From the buyer's side, you're signing one contract for one tool deployed in one environment. The vendor knows their standard agreement. You're reading it for the first time.
Many of these protections are negotiable with the right position at the table. They just aren't there by default, and they aren't available once you've already signed.
Three Places Your Coverage Is Probably Weaker Than You Think
Pull your largest SaaS or software agreement. Search the document for the word "defend." Then search for "indemnify." Then find where the contract caps the vendor's total liability.
What you find, or don't find, determines what happens when a demand letter arrives.
The first gap is about who pays while a legal fight is happening. Most vendor agreements include a promise to indemnify, meaning the vendor will typically reimburse you after a dispute resolves, which can take years. What's often missing is a duty to defend, meaning the vendor retains lawyers and covers costs from the moment a claim is filed. Without a duty to defend, you commonly front the entire legal fight yourself and hope to be made whole on the other side. Most standard vendor paper includes "indemnify." It often doesn't include "defend."
The second gap is about how much coverage you actually have. Most technology contracts cap the vendor's total liability at the fees you've paid in the prior 12 months. If you're paying $3,000 a month and a demand arrives at $400,000, the vendor cap is $36,000. Your exposure is everything above that. The indemnification clause can say exactly the right things and still be functionally worthless at those numbers. Getting IP claims treated as a separate uncapped obligation, or subject to a realistic separate ceiling, is a standard position in negotiated enterprise contracts. Enterprise vendors frequently move on this, particularly in larger or strategic deals. The question is whether you knew to ask before signing.
The third gap is the one trolls specifically engineer around. Most IP indemnification clauses void coverage when a claim involves the vendor's product being used in combination with other systems. Your software touches your network, your data, other tools. That's how every enterprise deployment works. A broadly written combination carve-out can allow a vendor to walk away from a claim because your product touched another system, which it does by design. Narrowing that language, limiting it to non-standard uses rather than normal intended deployment, closes that exposure. It requires knowing the clause exists and asking for different terms before you sign.
This Is Not Just a Legal Department Issue
Most technology leaders assume this is a legal department problem. Legal checks whether contract terms are enforceable. Legal doesn't own the operational risk of a tool embedded in your production environment. They don't know how the vendor's product is deployed, or what "combination with other systems" means in the context of your infrastructure. The person who understands that is you, not outside counsel.
IT and legal need to look at this together. The flag needs to come from the technology side.
What Typically Happens When a Demand Arrives
A demand letter arrives on Monday. General counsel is looped in by Tuesday. Someone calls the vendor Wednesday. The vendor reviews the contract, finds that the combination carve-out applies, notes that the claim involves the product running on the buyer's infrastructure, and confirms they're not contractually required to help. The vendor is sympathetic. The contract is clear.
The insurance carrier gets notified Thursday. The policy may or may not cover patent claims. By Friday, there's a settlement demand on the table that costs less than three months of outside counsel, and the only people who read this contract before it was signed worked for the other side.
That scenario plays out more than it should. Your greatest position to change it is before you sign.
If You've Already Signed
Most readers are past the signing window on at least some of their major vendor agreements. There's still something to do.
Find the contracts for your most operationally critical vendors. Read the indemnification section. Look for the word "defend." Look at how the liability cap is structured and whether IP claims are treated separately. Check whether the combination carve-out is written broadly or narrowly. Then check renewal dates.
A renewal is the window. Before you re-sign, you have the option to negotiate terms you couldn't change after the deal was done. Most buyers re-sign the same paper they signed the first time because nobody flagged what was missing. The renewal is the last moment where the outcome of a future demand letter is still within your control.
What Strong Contract Terms Actually Look Like
You don't need perfect contract terms. You need to know where you're accepting risk intentionally versus where a gap exists that you didn't see.
A strong buyer position typically includes a duty to defend, not just a duty to indemnify. IP claims should be carved out of the general liability cap or handled under a realistic separate ceiling. The combination carve-out should be written narrowly, limited to non-standard uses rather than normal deployment. Notice periods for reporting a claim should be reasonable; ten-day windows are a calendar technicality that can void coverage before anyone has had time to respond. And settlement terms should require your consent before a resolution that imposes obligations on your business or restricts your access to the product.
If a vendor won't move on any of these, that's a business decision, not necessarily a deal-breaker. The important part is knowing what risk you're accepting before you sign, not discovering it when the letter arrives.
Technology decisions always carry risk. The goal is to accept that risk knowingly rather than inherit it accidentally.
If a renewal is in front of you, this is where to understand what's actually at stake and what independent representation changes about the outcome.
