Device limits are the most common mechanism for account sharing enforcement on subscription platforms. A subscription is valid for one device, or two, or three. When a device count threshold is crossed, the enforcement kicks in. In principle, this is a simple and direct approach. In practice, it has two problems that undermine it in most deployments.
The first is technical: cookie-based device tracking is trivially defeated by clearing cookies, using private browsing, or accessing the platform from a different browser. A credential sharer who clears their cookies is invisible to cookie-based device tracking. The device limit resets to zero.
The second is legal: cookie-based device tracking requires consent under GDPR for European subscribers. A consent-based device tracking mechanism creates a logical contradiction: the subscriber who is sharing their credential is also the subscriber who would be most likely to withhold consent for device tracking, leaving the sharing arrangement undetected.
The Merchant Risk Council's 2026 Global eCommerce Payments and Fraud Report found that 64% of merchants report a meaningful increase in first-party misuse. Platforms operating in European markets need an account sharing prevention approach that does not depend on cookies and does not require consent. Browser-layer device fingerprinting that collects no personal data provides this.
Why cookie-based device limits fail
Quick answer: Cookie-based device tracking assigns a persistent identifier to each device through a browser cookie. This identifier is erased when the user clears their cookies, changes browsers, or uses private browsing. A credential sharer who is aware of this can defeat the device limit by clearing cookies before each session. Private browsing modes, which are now the default session type for many users on shared or mobile devices, discard cookies automatically. Cookie-based device limits are reliable only against users who are unaware of cookie management, which excludes the most deliberate sharers.
Cookie-based device tracking works as a persistent identifier for first-party analytics and personalisation because most users do not clear their cookies and most platforms do not need to enforce strict device counts. In those contexts, the occasional loss of the cookie identifier is an acceptable data quality issue.
For account sharing enforcement, the failure mode is fundamental. A sharer who is motivated to maintain access to a product they are not paying for has a strong incentive to defeat the device limit. Clearing cookies is a one-click operation in every major browser. Private browsing mode, which clears all cookie-based identifiers at session end, is available on every platform. The population of users most likely to be sharing credentials is the same population most likely to manage their cookies deliberately.
The GDPR constraint compounds the technical limitation. Under GDPR Article 6, storing a persistent identifier on a user's device through a cookie requires a valid legal basis. For non-essential cookies, that basis is consent. Consent for account sharing tracking is logically problematic: a subscriber who is sharing their credential has an incentive to withhold consent, which means the population you most need to track is also the population most likely to opt out. A GDPR-compliant cookie-based device limit system that requires consent cannot reliably catch deliberate sharers.
What GDPR says about browser-layer device fingerprinting
Quick answer: Browser-layer device fingerprinting that derives a device identifier from hardware and software configuration signals, without storing any data on the user's device, falls outside the ePrivacy Directive's cookie consent requirement because no data is stored client-side. Under GDPR, the device configuration data processed is not personal data under Recital 26 if the individual is not identifiable from the data alone. Fraud prevention, including first-party misuse prevention, is recognised as a legitimate interest under GDPR Recital 47 and Article 6(1)(f).
The ePrivacy Directive's consent requirement applies to storing or accessing data on a user's device. A cookie is stored on the device. A browser-layer fingerprint is derived from reading the device's configuration in-browser, without writing any persistent data to the device. The ePrivacy Directive does not apply to reading device configuration data that is necessarily transmitted as part of the browsing session.
GDPR Recital 26 establishes that information is not personal data where the individual is not identifiable, taking into account all means reasonably likely to be used. The device configuration signals used for browser fingerprinting, which include GPU renderer output, audio context response, canvas rendering characteristics, and font availability, identify a browser and hardware configuration. They do not, on their own, identify an individual. Combined with an account login, they identify that a specific device configuration is associated with a specific account. This combination is within the account relationship context, not a broader individual identity context.
GDPR Article 6(1)(f) permits processing based on legitimate interests. GDPR Recital 47 explicitly identifies fraud prevention as a legitimate interest basis: "The processing of personal data strictly necessary for the purposes of preventing fraud also constitutes a legitimate interest." Account sharing prevention is first-party misuse prevention, which sits within the fraud prevention legitimate interest category.
The combination of these provisions means that browser-layer fingerprinting for account sharing prevention, implemented without client-side storage and without combining fingerprint data with broader personal data beyond the account relationship, can be operated on a legitimate interest basis under GDPR without requiring cookie consent.
How cookieless fingerprinting enforces device limits
Quick answer: cside's browser-layer fingerprinting derives a stable device identifier from hardware and software configuration signals that are inherent to the device: GPU renderer, audio context, canvas rendering, font set, and related attributes. This identifier is stable across private browsing sessions, cookie clearances, and browser restarts because it is derived from the device's hardware and software configuration, not from stored data. A device that clears its cookies generates the same fingerprint as before. A device limit enforced on this fingerprint cannot be defeated by cookie management.
The stability of browser-layer fingerprinting relative to cookie-based tracking is the property that makes it suitable for device limit enforcement. The device identifier is stable because it is derived from hardware and software attributes that do not change when cookies are cleared:
- GPU renderer: the device's graphics processing unit produces a characteristic rendering output that is stable across sessions and is not affected by browser settings or cookie state.
- Audio context: the device's audio processing hardware produces a characteristic response to a synthetic audio processing test that varies between hardware configurations and is not stored as a cookie.
- Canvas rendering: the device's combination of GPU, operating system, and font rendering produces a characteristic canvas output that is stable across sessions.
- Font availability and rendering: the set of fonts installed on the device and how they are rendered varies between configurations and contributes to a stable fingerprint.
These attributes combine to produce a stable identifier for each unique hardware and software configuration. A device that clears its cookies, switches to private browsing, or uses a different browser produces the same fingerprint from its underlying hardware and software configuration.
The practical implication for device limit enforcement is that the limit is enforced on a signal the sharer cannot easily manipulate without physically changing devices, not on a signal that can be reset with a menu click.
The consent-free architecture
Quick answer: cside's account sharing detection architecture collects device configuration data server-side from signals transmitted as part of the browsing session, without storing any persistent identifier on the user's device. This places the processing outside the ePrivacy Directive's consent requirement. Processing is conducted under GDPR Article 6(1)(f) legitimate interest (fraud prevention). No cookie consent banner is required for the account sharing detection component. The processing is documented in the platform's privacy notice under the legitimate interest basis.
The architecture that enables consent-free operation has three characteristics:
No client-side storage. The fingerprint is derived server-side from signals that are inherently transmitted during a browsing session. No cookie, local storage entry, IndexedDB record, or other client-side persistent storage is created. The device signals are read in-browser and transmitted to cside's server-side analysis pipeline. Nothing is left on the user's device.
Legitimate interest documentation. The processing of device configuration data for fraud prevention purposes is documented in the platform's privacy notice under Article 6(1)(f). A legitimate interest assessment (LIA) documents the balance between the platform's interest in preventing first-party misuse and the user's interest in privacy. For account sharing prevention, the LIA is straightforward: the platform has a legitimate commercial interest in enforcing its terms of service; the processing uses device configuration data that the user necessarily transmits as part of their browsing session; and no broader personal data profile is built from the signals.
Minimum necessary processing. The device configuration signals collected are the minimum necessary to produce a stable device identifier for the account sharing detection purpose. The signals do not reveal the user's browsing history, location, or identity beyond the browser session context. This proportionality supports the legitimate interest basis.
Under this architecture, account sharing detection can operate across European subscriber bases without a cookie consent requirement, without a consent banner, and without the logical contradiction of requiring consent from the users whose behaviour you need to detect.
What this means for compliance and product teams
Quick answer: Compliance teams evaluating account sharing prevention tools need to ask two questions: does the tool store client-side persistent identifiers (requiring cookie consent), and does the tool collect personally identifiable information beyond the account session context (triggering broader GDPR obligations)? cside's browser-layer fingerprinting answers no to both. The processing architecture is designed to operate under legitimate interest without requiring consent, and the device configuration signals collected do not constitute personal data under GDPR Recital 26 in isolation.
For compliance teams, the documentation requirements for cookieless browser-layer fingerprinting under GDPR are:
- Privacy notice update: add a section describing the legitimate interest basis for device configuration processing, the categories of signals collected, and the purpose (account sharing prevention/fraud prevention).
- Legitimate Interest Assessment: document the three-part test: purpose (prevent first-party misuse), necessity (device configuration data is the minimum necessary for a stable device identifier), and balance (user's interest in not being tracked is outweighed by the platform's interest in enforcing its subscription terms and the user's expectation that their subscription covers their own use).
- Data Processing Agreement: execute a DPA with cside as a data processor for the device configuration data that cside processes on behalf of the platform.
For product teams, the practical implication is that the account sharing detection system can be implemented and operated without a cookie consent flow and without any user-facing privacy UI specific to the sharing detection component. The privacy notice update and LIA are internal documents; the user-facing experience is unchanged.
cside is SOC 2 certified. The full privacy architecture documentation, including the data processing agreement template and legitimate interest assessment framework, is available at trust.cside.com.
