NIS2 in 2026: what changes for SaaS vendor security

Where NIS2 stands in France

The directive was due to be transposed by 17 October 2024. In France, the bill on the resilience of critical infrastructure and strengthening of cybersecurity carries the transposition, and ANSSI is already preparing future entities (pre-registration, the ReCyF framework). The details are in our article on NIS2 transposition in France. Be careful with deadlines and control lists until the implementing texts are final.

A vendor is in one of two situations:

• You are an in-scope entity yourself, depending on your sector, size and activity (for instance some cloud computing or managed services).
• You are affected indirectly because your customers must assess their suppliers' security (Article 21 of the directive, "supply chain security").

Either way, the customer asks the same question: if your product is compromised, what does the attacker get on my side?

The flaws NIS2 brings to light

1. Weak isolation between customers

In a multi-tenant SaaS, every customer shares the same database. All it takes is a tenant_id or org_id parameter accepted from the client without a server-side check, and a user at a local authority can read a hospital's data. This is the costliest flaw for a supplier, because it turns an incident at one customer into an incident at all of them. We cover it in multi-tenant HRIS client isolation.

2. Support and admin accounts

A support account able to open any customer workspace, protected by a password alone, is the ideal way in. Phishing or an infected laptop is enough. The impact is that of a supply-chain attack: one account gives access to dozens of customers.

3. Long-lived integration tokens

Connectors to payroll, directories or accounting: these tokens often carry broad rights and never expire. Stolen once, they stay valid for months.

4. Slow patching

NIS2 calls for vulnerability management. A framework or dependency left exposed for weeks after a critical fix is published is exactly what attackers exploit at scale.

5. No usable logs

Without a record of data access (who read what, from which account), you cannot tell a customer what leaked. Yet the directive requires entities to send an early warning within 24 hours and a notification within 72 hours to the authority; they will ask you for that information very quickly.

How to test it

These checks fit in a day on a staging environment, with test accounts:

1. Isolation. Create two test organisations. From organisation A, replay every API request with the resource or organisation ID swapped for B's. Any 200 response with B's data is a critical flaw.
2. Support accounts. List every account that can reach several customers. Check that multi-factor authentication is enforced, that access requires a stated reason and that it is logged.
3. Tokens. Inventory active integration tokens, their scope and creation date. A token older than a year with no rotation is a concrete risk.
4. Patching. Compare your critical dependencies (web framework, ORM, auth library) with the latest fixed versions. Measure the real delay between release and deployment for your last three fixes.
5. Logs. View a test employee record, then ask your team to find the event: who, when, from which address. If the answer takes more than an hour, you will not meet the deadlines.

How to fix it

• Server-side authorization on every resource, with the organisation derived from the session, never from a client parameter. RLS policies or an authorization middleware with automated tests.
• Controlled support access: mandatory MFA, time-limited and approved access, logging the customer can see.
• Narrowly scoped tokens with scheduled rotation.
• A written fix deadline for critical flaws, and monitoring of your dependencies.
• An access log for sensitive data, retained and searchable.
• An evidence pack ready for customer security questionnaires: recent test results, incident procedure, list of subprocessors.

What changes when your product ships an AI agent

An assistant built into the product (searching records, drafting letters, answering employees) inherits all of these flaws and adds one: it reads content an attacker can control. An uploaded document or an incoming message can carry an instruction that pushes the agent to fetch data outside its scope or send it elsewhere. If the agent's tools do not check the user's organisation themselves, tenant isolation rests on the prompt alone.

For a customer subject to NIS2, that agent is part of your supply chain just like your API. It has to be tested as such. The Agent Red Team Express gives you, in five days, an evidence-backed report on what your agent lets through, ready to reuse when customers ask.