The CNIL wants vendor remote access opened per job and logged by name

A common setup at a software company: a customer files a ticket, a support engineer opens the internal admin panel, clicks "log in as user", and is looking at that customer's records. Nobody at the customer approved it, the access never expires, and three engineers share the support login, so the logs cannot say which of them it was.

On 9 November 2026 France's data protection regulator, the CNIL, announced ten fines of 3,000 to 20,000 euros against French local authorities and one public body for weak security 1. One of the failings it lists is the network version of that setup: outside providers, software vendors among them, could get into the authorities' networks at any time, without permission for each visit, or through accounts several of the vendor's employees shared. The CNIL says it inspected those providers too, and that its future checks will cover them. Its security guidance says a vendor's access should be opened by the customer for each job, closed when the job ends, and recorded by both sides with the names of the people who did the work 2. The vendor carries its own legal duty here: GDPR's security article binds the company handling the data as well as its customer, and Sweden's regulator has already fined a software vendor under it.

Does the CNIL's guidance cover support access in a hosted product?

In my reading, yes. The guidance is the CNIL's security guide, a set of short chapters on how the CNIL reads GDPR Article 32 (the duty to keep personal data secure) and what an inspected organisation can expect to be measured against. Its chapter on maintenance by outside providers is written for installed software, where the vendor reaches into the customer's network. In a hosted product the customer's data sits in the vendor's own systems, and the chapter that fits is the one on access rights. It asks for access limited to the data each person needs, every grant approved by a manager, and temporary permissions withdrawn once the reason for them has passed 7. Together with Article 32, which applies to the vendor as well as the customer 5, that leads to the same per-job model for a support engineer's "log in as user".

Enterprise and public-sector buyers already get this from their largest suppliers. Google Cloud's Access Approval makes Google staff get a customer administrator's approval before accessing customer data, and its Access Transparency logs record what they did and why. Microsoft's Customer Lockbox does the same for several Microsoft 365 services once a customer turns it on, with each approval lasting at most four hours. A small vendor can build a simpler version, but a buyer who has seen these will ask how support access works.

Can the software vendor be fined too?

Yes. Article 32 applies to the vendor handling the data as well as to the customer, and a regulator can fine either one for breaking it 5. Sweden's regulator, IMY, fined the HR software vendor Miljödata under Article 32 after a breach of its customers' data, which I wrote about in the post on that fine.

The fines on the French authorities were small because the CNIL used its simplified procedure, a quick written process that can be used against any organisation, companies included. It caps a fine at 20,000 euros for an organisation with turnover under 50 million euros and 100,000 euros above that 6. The CNIL says it is devoting half of its 2026 inspections and enforcement actions to data security 1.

The customer is exposed as well. GDPR lets it use only vendors that give "sufficient guarantees" of appropriate security 5, so a vendor's open-ended access is a gap in the customer's security too. The announcement does not say whether any provider received a sanction of its own this time.

What else did the CNIL find at the French local authorities?

Mostly basic security gaps on the authorities' own side: remote logins without MFA for administrators, logs that were incomplete or not analysed soon after, flat networks, servers on operating systems their maker no longer updates, and weak passwords, some sent to users in clear text (my translation) 1. Several authorities were also fined for skipping impact assessments. The CNIL says some had already suffered breaches that "could have been avoided" with the right measures. These bodies were examined because local-authority cybersecurity was one of the CNIL's inspection themes for 2025.

If your staff can get into customer systems or customer data, what should you change?

This is for anyone who sells software to companies or public bodies and whose team can reach customer data: support, on-call engineering, or an installer who keeps a remote tool on the customer's machines. If you sell in France, the CNIL has said its checks cover customers' providers, and a customer found with your standing access open can be sanctioned for it. Anywhere in the EU, Article 32 binds you directly, and a regulator can fine you for breaking it.

1. List every standing way in. Remote-desktop tools left installed at customer sites, VPN logins, a "log in as user" button in your admin panel, database access for on-call engineers, and any shared support account.
2. Give every person their own account with MFA. The CNIL's guide tells organisations to forbid accounts shared between several users. Where one cannot go yet, its fallback is a manager's sign-off, a way to trace the actions done with it, and a password change when someone stops needing it 3.
3. Make access per job. The customer, or a request tied to a support ticket, opens it, and it expires on its own. The guide lists "full or permanent access to systems for remote maintenance" as something not to do 2. Keep a separate emergency path for outages, when nobody at the customer can approve in time: limited in time, logged, and reported to the customer afterwards. Google's approval process may let outage requests through automatically for the same reason.
4. Keep a register of each access and let the customer see it. The CNIL's model contract clause has both sides keep a register of the dates, what was done and the names of the people who did it 2, with logs kept for six months to a year 4.
5. Write it into your DPA's security annex. Say how support access is granted, how long it lasts and what is recorded, so the customer can check the guarantees GDPR asks it to check. The CNIL ties these checks to NIS2, the EU cybersecurity law France is still writing into national law, which the CNIL says puts new security requirements on local authorities and which reaches their suppliers through the supply-chain terms in their contracts. I listed what it wants in a supplier contract in the post on NIS2 supplier clauses.

That annex goes out of date when an engineer ships a new admin tool. A pull request that adds a "log in as user" feature makes your DPA's description of who can see customer data wrong. Lawcel is a compliance tool for software companies: it reads each pull request and flags the ones that make a legal document out of date, like that one, so your team can update the annex before the feature ships.