Session replay needs cookie consent in France, even when used only to fix bugs

A common setup in a software product: session replay (Hotjar, Microsoft Clarity, FullStory, PostHog or Sentry) runs inside the logged-in app, each recording is tagged with the signed-in customer's email so a bug report can be matched to a video, and there is no consent prompt after login. On 5 November 2026 France's data protection regulator, the CNIL, published its final recommendation on these tools, and that setup breaks it twice 2. The CNIL says a replay tool needs the visitor's consent before it records anything, even when the only use is finding bugs, and that a recording made to fix bugs should not be tied to the user's account. It also wants forms, images, account details and chatbot conversations hidden by default. The recommendation covers any company offering its product to people in the EU, and the CNIL fined the French electronics retailer Fnac Darty 7 million euros on 22 October 2026 for an app tracker that ran although users had refused.

I read the twelve-page recommendation and the CNIL's answers to the public consultation. Below is what they say, which parts are law and which are advice, and, in the last section, what to change in a product that records sessions.

Which parts of the CNIL's session replay recommendation are law?

The consent rule is law. The specific settings the CNIL suggests are advice, and a company may use others if it can show they meet the law 1. The GDPR duties behind those settings are law too: collect only the data a purpose needs, keep it no longer than needed, and protect it by design and by default 5. Regulators can fine for breaking any of these.

The consent rule comes from the EU's ePrivacy Directive, the rule behind every cookie banner, which every EU country has written into its own law 4. The CNIL says its recommendation applies to companies based in the EU and to companies elsewhere that offer their product to people in the EU or track their behaviour 1. Other EU regulators are not bound by the CNIL's reading. I would still treat it as the baseline for EU users, because the exemption it interprets (the "strictly necessary" exemption that lets some cookies skip the banner) is the same text in every member state. The UK has its own rules, and the analytics exemption it introduced in February 2026 does not cover replay either (see the post on UK analytics cookies).

Does session replay need consent if it is only used to fix bugs?

Yes, according to the CNIL. The ePrivacy rule exempts storage or access on a device only where it is strictly necessary to provide a service the user explicitly asked for 4. During the consultation, one respondent argued that replay used for detecting faults or for security is necessary in that sense. The CNIL rejected this: necessity is judged by the service the user asked for, and the tool's usefulness to the company does not count 3. The company could provide its service without the tool, so by its nature replay is never strictly necessary 1.

Some analytics can skip consent in France: the CNIL lets audience measurement tools run without consent, even when they are used to detect navigation problems, as long as they only produce anonymous statistics. Replay does not qualify, because it records and rebuilds one person's individual visit 1.

The recommendation makes no exception for the logged-in part of a product, which often has no consent prompt at all. I wrote about scripts that run after login in the post on trackers inside a logged-in app.

What the consent request has to say

The CNIL names three purposes for which replay can be used: finding and understanding technical errors, improving the user experience, and handling customer support requests 1. Each one gets its own choice, and the company decides which purposes it pursues before recording starts. Several respondents asked for one broad purpose such as "improving the service". The CNIL refused, because a broad label would let a company decide what a recording was for after watching it 3.

On the first screen of the consent banner, each purpose gets a short label, with more detail one click away. The CNIL suggests wording such as "[Company] records and views your actions while you browse in order to fix technical problems" (my translation) 1. It also asks for a separate short notice on that first screen saying that the site uses session replay, because few people know these tools exist.

When a user withdraws consent, the tool must stop reading its cookies or identifiers, and the company must delete the recordings unless another legal basis justifies keeping them. If the vendor stores them, the company tells the vendor to delete them too 1.

What should a session replay tool hide by default?

Anything a user types or that shows their account, plus images. The CNIL asks vendors to offer a masking tool that, when nobody has configured it, hides at least these 1:

• images
• forms and text fields
• fields filled in by the app, such as account details
• mouse movements and clicks on on-screen keypads, which can reveal a PIN
• conversations with chatbots, both the questions and the answers

On top of masking, the tool should block passwords and bank details from ever being collected, and give the company access roles that decide who can watch which recordings, reviewed when people leave or change jobs. Masked data can still be unmasked later by a few authorised people, but only through an approval step.

Vendor defaults differ. Sentry's session replay documentation says its browser SDK masks all text and blocks images and video by default. PostHog's privacy controls mask input fields by default but leave other text visible unless the team masks it. Microsoft Clarity's masking settings default to "Balanced", which masks input fields, drop-down menus, numbers and email addresses, and leaves images and other text visible. Of these three, only Sentry starts close to what the CNIL describes.

The default matters because a product changes after the tool is installed. When researchers at Princeton found replay scripts on 482 of the 50,000 most visited sites in 2017, they pointed out that redacting sensitive fields has to be redone every time the site or the app behind it changes. With masking on by default, the fields on a new screen stay hidden until someone unmasks them. With masking off, they are recorded until someone notices.

How long can recordings be kept, and can they be tied to a user?

It depends on the purpose, and the CNIL gives a table for it 1. In short:

For bug fixing and design work, the CNIL sees no reason to link a recording to a user's identity. The tool should use a random session ID, which may be short-lived, so separate visits by the same person cannot be joined up or matched to an account. Customer support is the one purpose where a link is allowed, because the support team has to find the session of the person who wrote in. Even then the CNIL recommends a pseudonymous ID (a code derived from the account, such as a hash of the account number, that does not show who the person is). The few hours of retention are the CNIL's suggestion: a company whose support requests arrive later can keep recordings longer if it documents when those requests come in 1.

The CNIL also asks companies to record fewer sessions. Three methods are named: record a random sample, record only when a set event happens (such as an error), or record everything and quickly delete the sessions that turn out not to be needed, such as visits where nothing went wrong or support requests that are closed 1. These follow from the GDPR's rules that data must be limited to what the purpose needs and kept no longer than it needs 5. A vendor should let the company delete a single session, so a deletion request can be honoured.

This settles the setup from the opening. Matching a customer's bug report to that customer's session is the support purpose: the link is allowed, but as a pseudonymous ID instead of the email, the CNIL recommends checking with the user before unmasking anything, and the recording is kept for hours unless you document that reports arrive later 1. Where the same recording is also kept for bug fixing, the CNIL says the company may have to strip the user ID out once the support period ends, and keep the recording for bug fixing without it 3.

If you run session replay in a product used in the EU, what should you change?

Once replay waits for consent, it records fewer sessions. My own choice would be to keep it where a single session tells you something statistics cannot, such as a bug report or a support ticket, and to answer design questions with aggregate analytics. These steps follow the recommendation:

1. Keep recording off until the user agrees, in the logged-in product as well as on the marketing site. Give each purpose its own choice, and add the short notice that you use session replay.
2. Mask the CNIL's list by default, then unmask what you need. Inputs, forms, images, fields that show account details, chatbot transcripts and on-screen keypads. In PostHog that means masking the elements that show account data and images on top of the default input mask; in Clarity, Strict mode covers it. Check avatars that load as background images, which media blocking can miss.
3. Stop tagging recordings with the user's email. For bug fixing, record without any user link. To match a support request to a session, use a pseudonymous ID and strip it when the support period ends.
4. Set retention per purpose: a few months for bugs and design work, a few hours after the session for support unless you can document why longer is needed, and delete sessions in which nothing went wrong.
5. Read your replay vendor's DPA for any clause that lets it use recordings to improve its own product. If there is one, the CNIL says the vendor becomes a controller for that use and shares responsibility for the consent with you, so the contract should say who proves consent was collected and how that proof is kept and audited 1. I went through how vendor roles are decided in the post on which vendors need a DPA.
6. Name the tool, the purposes and the retention in your Cookie Policy and Privacy Policy.

These settings and documents go out of date as the product ships. A pull request that adds a replay SDK, a new purpose or a support integration changes what the Cookie Policy and Privacy Policy have to say. Lawcel, the tool we build, reads each pull request and flags changes like these that affect a company's legal documents.