We scanned fifty HR SaaS platforms in April 2026. The roster included the names you know: Greenhouse, Personio, Deel, Remote, Hibob, CultureAmp, Ashby, SmartRecruiters. These are the tools your payroll, hiring, performance reviews, and employee records actually run on.
On five of the fifty, a session-recording tool was active on the login page.
Not on the marketing site. On the page where employees type their work email and password.
What session recording actually captures
Session recording is a category of analytics software that watches a user navigate a page. The common tools are HotJar, Microsoft Clarity, PostHog session replay, FullStory, LogRocket, Mouseflow, and Smartlook.
In their intended use, they help product teams understand where users get stuck in a sign-up flow or why a checkout abandons. They record mouse movement, scroll position, clicks, and the sequence of DOM mutations. Most of them also record the contents of text inputs.
On a login page, that list is straightforward. Your mouse path. Your keystroke timing. The email you typed. The characters you pasted. If the password field is not correctly marked as sensitive in the tool's configuration, the password itself. If autofill triggered any adjacent field, whatever the browser offered to fill in.
And because these tools batch and send their recordings to a third-party server, a complete replay of your login attempt now exists on someone else's infrastructure. Your HR vendor's analytics provider. Their replication region. Their retention policy. Their subprocessors.
The tool vendors will point out that password fields are masked by default. This is true. It is also a thin defence. The default masks input[type="password"]. It does not automatically mask usernames, email addresses, security questions, one-time codes, or any field where a developer forgot to add the correct class or attribute. In practice, we found recorders configured with the default mask and no additional hardening.
How it got there
The pattern is almost always the same. A marketing team adds a session-recording snippet to the public site to understand visitor behaviour. The snippet is installed via Google Tag Manager, or added to the global layout file, or injected at the CDN. Nobody writes a route-level exclusion for /login, /sign-in, /app/*, or any authenticated path.
The snippet runs on every page. Including the one where your password is typed.
Nobody in the company made a conscious decision to record logins. It is the emergent behaviour of a tool installed globally and never constrained.
The consent angle
Under GDPR, non-essential processing requires informed, affirmative consent before it happens. Session recording is not essential to authenticate a user. It is analytics.
In the five cases we found, four had a consent banner on the marketing site. None of the five gated the recorder behind that consent on the authentication flow. Two of the four banners did not include a reject option at all, meaning the user had no mechanism to decline even in theory.
This is not a grey area. The French DPA (CNIL) has repeatedly fined organisations for firing analytics scripts before consent. The underlying point is simpler than the regulatory text. If the default behaviour of your site is to record what a user is typing before the user has agreed, the defence "the vendor accepted your terms" is not available. Your vendor did not agree on behalf of the employee typing their password.
Why it matters specifically on an HR platform
Every SaaS login page has the same problem in principle. What makes HR software worse is what happens immediately after the login.
An HR platform holds compensation data. National insurance and tax identifiers. Bank account details. Performance reviews. Medical leave records. Termination reasons. Benefits enrolment including dependants and health conditions. An attacker who obtains the replay of a login attempt has the first step toward all of it.
The second problem is the employees themselves. An employee does not choose their HR vendor. They are issued credentials to a platform their employer signed a contract with. They cannot opt out of the platform and keep their job. The argument that a user can simply leave a site they disagree with does not apply.
The third problem is that the HR vendor typically publishes a compliance page. SOC 2. ISO 27001. GDPR. The compliance page is a promise that the controls work. A session recorder on the login page is a control that does not work.
What to check on your own platform
If you run an HR platform, or any platform that serves a login page, three checks will tell you whether you have this problem.
One. Open the network tab on your login page. Load the page with DevTools open and a clean cookie jar. Look for requests to any of the following: hotjar.com, clarity.ms, posthog.com, fullstory.com, mouseflow.com, smartlook.com, logrocket.com. If you see those requests firing before the form is submitted, your login is being recorded.
Two. Open the source of your login page. Search for the initialisation call for any analytics tool. If it is present, check whether it is wrapped in a conditional that excludes the login route. If it is not, it is running.
Three. Look at the configuration in the tool itself. Check the URL exclusion list. Check whether input masking is enabled beyond the default password-field mask. Check whether the recording is tied to a consent category in your consent management platform, and whether that category is correctly configured.
How to fix it
Do not record authentication pages. Add the login route, the sign-up route, and any authenticated path to the URL exclusion list in your analytics tool. For tools that support it, disable the recording when the user is on a page that contains a password input.
Mask everything by default, allow specific fields explicitly. The default of "mask passwords only" is the wrong posture. The safe default is "mask all inputs" with specific allowances for fields you have audited.
Gate the recorder behind consent. In Google Tag Manager, this is consent mode v2. In Cookiebot, OneTrust, or TrustArc, it is tying the recorder tag to the analytics or functional consent category and setting that category to off by default. All of these tools have supported this for years. None of it is technically difficult.
Verify after every deploy. A single misconfiguration, a new marketing-team GTM trigger, a new subdomain added without the exclusion list, and the recorder is back on the login page.
What we are not saying
We are not naming the five platforms. Publishing a list would be easy and it would be wrong. The problem is a pattern across the category, not a smear on five specific vendors, and every HR platform should check their own login page tonight before assuming they are not on the list.
We are also not saying that session recording is illegitimate. Used correctly, on the right pages, with the right masking and the right consent gating, it is a reasonable product tool. Used on a login page with default masking and no consent, it is a compliance finding, a privacy harm, and a liability waiting to be tested in court.
If you run an HR platform, or buy one, the useful question is not whether your vendor claims compliance. Their compliance page will say the right things. The useful question is what loads in the network tab of their login page.
Open it and see.