Eight EULA Clauses Security Teams Should Check in 2026

Date: 5 November 2026

 From 11 September 2026, manufacturers of software and connected products sold in the EU have to warn the authorities within 24 hours of learning that a vulnerability in their product is being actively exploited. On 9 December 2026 a second change follows: under the new Product Liability Directive, software counts as a product, and liability towards an injured person can no longer be excluded by contract. Both rules land on a document that security teams rarely open, the end-user licence agreement (EULA). 

 

Legal and procurement usually sign the licence off. Yet the EULA decides who patches, for how long patches keep coming, what telemetry leaves your network and who pays after an incident. Below are eight clauses worth a security review, for buyers and for vendors alike.

Why the Licence is a Security Document

Most vendor risk reviews look at certifications, penetration test summaries and questionnaires. Those describe what the vendor does today. The licence is where those promises become obligations, or where they disappear behind phrases like "at our sole discretion". If the EULA says nothing about security updates, the vendor has no contractual duty to ship them, however good its marketing sounds.

Regulators have noticed the gap. The EU's Cyber Resilience Act (CRA) and the UK's product security regime now set minimum duties that a licence cannot water down for the products they cover. A good licence review checks whether the vendor's terms match those duties.

1. Security updates and the support period

Under Article 13(8) of the CRA, the support period for a product with digital elements must be at least five years, or shorter only when the product is expected to be used for less time. Article 13(19) adds that the end date, at least the month and the year, must be shown clearly at the time of purchase. These obligations apply to products placed on the EU market from 11 December 2027, and the CRA expects security updates to be free of charge.

In the UK, the PSTI product security regime has applied to consumer connectable products since 29 April 2024. Manufacturers must publish the minimum length of time for which security updates will be provided.

What to look for in the licence:

• a stated support end date, or a clear reference to where the vendor publishes it;
• a commitment that security fixes are not tied to buying a new major version;
• notice before the vendor shortens support or drops a product line.

A licence that says updates are provided "if and when available" gives you nothing to rely on.

2. Vulnerability reporting and disclosure

Article 14 of the CRA, in force from 11 September 2026, requires manufacturers to send an early warning about an actively exploited vulnerability within 24 hours of becoming aware of it, through the single reporting platform run by ENISA. Breaches of the essential requirements and of the obligations in Articles 13 and 14 can lead to fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. The UK regime asks for something simpler but just as useful: a published way to report security issues, with timescales for acknowledgement and status updates.

The regulator will hear about an exploited flaw. You will hear about it only if your contract says so. For business software, ask for a named security contact, a deadline for telling customers about incidents that affect them, and a duty to cooperate during your own investigation. If your playbooks do not yet cover vendor notifications, adding a step to an existing incident response plan template is a quick fix.

3. Automatic updates and change control

The CRA's essential requirements say that, where applicable, security updates should install automatically by default, with a clear and easy opt-out, a notice to users and the option to postpone them for a while. That suits consumers. Enterprises usually need the opposite — the right to test patches in staging before they reach production.

Check that the licence lets you delay non-critical updates, explains how critical fixes are flagged and does not cancel support or warranty because you held an update back for testing.

4. Telemetry and data collection

Many EULAs give the vendor a broad right to collect "usage data" and "diagnostics". Read the definitions. Crash reports can contain file paths, user names and fragments of documents. If the vendor processes personal data on your behalf, Article 28 of the GDPR requires a written processing agreement that sets out what it may do with that data.

Useful terms here are a list of the data categories collected, the hosting location, a switch to turn off non-essential telemetry, and a ban on using your data to train models without consent.

5. Reverse engineering and security testing

Almost every licence bans reverse engineering. In the EU that ban has limits. The Software Directive (2009/24/EC) lets a lawful user observe, study and test how a program works (Article 5(3)) and decompile it when that is needed for interoperability (Article 6). Contract terms that override these rights are void under Article 8.

These rights are narrow, though. They do not amount to a general permission to run penetration tests, fuzz the product or publish findings. If your team plans to test vendor software, get written permission in the licence or a separate testing authorisation, with scope, notice and disclosure rules. Vendors who run a bug bounty or a coordinated disclosure policy usually agree without a fight.

6. Liability caps after a security incident

Business licences often cap liability at the fees paid in the previous twelve months and exclude data loss and indirect damage. After a breach that cap may cover a fraction of the response costs. A common compromise is a separate, higher cap for breaches of security and confidentiality obligations.

For harm to individuals, the Product Liability Directive (EU) 2024/2853 changes the picture for products placed on the market after 9 December 2026:

• Software is expressly a product (Article 4(1));
• Courts assessing a defect take into account safety-relevant cybersecurity requirements (Article 7(2)(f));
• A manufacturer cannot escape liability when the defect comes from a lack of software updates needed to keep the product safe, if those updates were within its control (Article 11(2)(c));
• Compensable damage includes destruction or corruption of data not used for professional purposes (Article 6(1)(c));
• Liability towards the injured person cannot be limited or excluded by a contract term (Article 15).

Business-to-business losses stay a matter of contract. Consumer-facing software, however, can no longer hide behind an "as is" clause for these claims.

7. Open-source components and the SBOM

The CRA requires manufacturers to identify and document the components in their products, including by drawing up a software bill of materials (SBOM) in a common machine-readable format that covers at least the top-level dependencies. The SBOM sits in the vendor's technical documentation. If you want a copy, or want to hear quickly when a component in your stack has a known vulnerability, write that into the contract.

The licence should also keep open-source notices intact. A EULA cannot take away rights that the GPL, MIT or Apache licences give users of those components.

8. Termination, data return and deletion

Security risk does not end when the licence does. Check how long you have to export your data and in what format, whether the vendor confirms deletion in writing, and when API keys, service accounts and integrations are revoked. Old credentials left behind after a contract ends are a common way in.

A Short Checklist for Your Next Licence Review

• Is there a stated support period with an end date?
• Who do we contact about a vulnerability, and how fast will the vendor tell us about incidents?
• Can we postpone updates for testing without losing support?
• What telemetry is collected, and can we switch it off?
• Are we allowed to test the product, and under which rules?
• Is there a separate liability cap for security failures?
• Will the vendor share its SBOM or vulnerability information?
• What happens to our data and credentials when the contract ends?

If you are on the vendor side, the same list works in reverse: each "no" is a question your enterprise customers will soon ask. For the legal groundwork, including what a EULA is, how click-to-accept terms hold up in court and how a EULA differs from terms of service, see the guide by DS Solutions.