When regulators or privacy advocates scan a website for compliance, one of the most common violations they find occurs in the first 200 milliseconds. Before any user clicks “Accept” or “Reject,” their device is already contacted by trackers, analytics scripts, or telemetry services.
These violations risk user trust and expose businesses to regulatory action and reputational damage.
The ironic twist? Many of these violations are introduced by the very tools purchased to enforce compliance: Consent Management Platforms (CMPs).
The core issue is how these platforms misuse the legal exception for “technical necessity” under Article 5(3) of the ePrivacy Directive. This article breaks down why that clause is being misunderstood, how CMPs and Google Tag Manager (GTM) are abusing it, and what an actual compliant setup looks like.
What “Strictly Necessary” Actually Means
Article 5(3) of the ePrivacy Directive allows certain scripts to run without consent, but only if they are essential for delivering a service the user has explicitly requested.
In practice, this means functionality like login sessions, shopping carts, or security tokens. It does not include telemetry, user behavior tracking, performance monitoring, or invoicing logic.
The European Data Protection Board clarified in Guidelines 02/2023 that “strict necessity” must be evaluated solely from the perspective of the data subject. Not from the business. Not from the vendor.
This means that even if a CMP needs to count visitors for billing purposes, or track how users interact with the banner for product analytics, these actions still require prior consent.
Why Most CMPs Are Non-Compliant by Design
A CMP’s exempt purpose is to show a consent prompt and register a choice. Yet in most implementations, CMPs do more than this before consent is even collected.
Common violations include:
- Tracking visitor sessions for usage-based invoicing
- Loading performance beacons for UI monitoring
- Embedding telemetry to analyze user interaction with the banner
- Hosting via third-party CDNs that initiate cookie placement
- Loading through GTM, which itself launches multiple domains
These elements do not meet the legal threshold of necessity for the user. They serve the business or the vendor. That makes them unlawful without consent.
In our privacy scans of 36,500 websites in Denmark, we found that all of the most widely used CMPs loaded third-party beacons, telemetry scripts, or analytics trackers before any user interaction - whether deployed directly or via Google Tag Manager. These scripts typically captured user agent details, screen resolution, IP-based geolocation, and session timestamps. The stated purposes included vendor-side invoicing, product telemetry, and UI optimization - none of which are technically necessary to display a consent prompt. Under Article 5(3) of the ePrivacy Directive, these functions require prior consent, which in these cases had not yet been obtained.
Why GTM Fails Even Before CMPs Load
Google Tag Manager (GTM) is frequently used to deploy CMPs, but GTM itself begins executing scripts immediately on page load - before any user has made a consent choice. This includes loading third-party resources and initializing tracking-related behavior.
Even with Consent Mode 2.0 enabled, GTM still connects to Google servers and can activate tags in a default “denied” or “pending” state. However, this fallback does not reliably prevent access to the user's device. Scripts may still fire, set cookies, or store unique identifiers based on the assumption that consent will be granted later.
This assumption is fundamentally incompatible with Article 5(3) of the ePrivacy Directive, which requires prior consent before any access to or storage of information on the user’s terminal equipment - regardless of whether consent is expected afterward.
Worse still, scripts injected into the page via GTM often do not appear in the browser's developer tools. They are dynamically inserted into the DOM, making them invisible to basic inspection. For example, LinkedIn conversion tracking - when deployed via GTM - does not expose its cookies, beacons, or script behavior in the browser console. These elements are only revealed through full HAR (HTTP Archive) network analysis.
This hidden execution layer makes it difficult for site owners, auditors, and even regulators to detect what data is being accessed or shared - compounding both the technical risk and the legal exposure.
When CMPs are loaded through GTM, the problem multiplies: you have a non-compliant delivery mechanism executing scripts without consent, which then attempts to enforce compliance. That paradox undermines trust, transparency, and legal defensibility.
Regulators are already enforcing this. A recent ruling from the Administrative Court of Hanover (VG Hannover, 10 A 5385/22, March 2025) explicitly ruled that the use of GTM requires prior, informed, and voluntary consent under both §25(1) TTDSG (now § 25 TDDDG / ePrivacy Directive 5(3) as imposed in German law) and Art. 6(1)(a) GDPR.
Misclassifying Tracking as Necessary
One of the most pervasive problems is the vendor-led practice of self-classifying telemetry and analytics as “strictly necessary.”
This misclassification includes:
- Visitor counters for CMP billing models
- Heatmap data collection for UX optimization
- Cookie syncing or tag loading that runs “passively”
No vendor has the legal authority to redefine what is necessary. That judgment is made in law, and it centers exclusively on the data subject’s interest. Not operational convenience. Not internal dashboards. Not investor KPIs.
Our privacy scans across 36,500 Danish business websites revealed that more than 73 percent deployed tracking technologies before any valid consent was obtained. In the majority of these cases, the tracking included third-party CMPs configured to operate through GTM or external CDNs.
The Compliance Architecture That Works
Achieving true compliance with the ePrivacy Directive isn’t a technical challenge - it’s a matter of architectural discipline. A properly designed CMP setup follows a simple rule: no data processing before consent.
A compliant implementation follows these principles:
- Self-hosted deployment: The CMP must be served from the same first-party domain, not a third-party CDN. This ensures no external resources are touched before consent.
- Deferred execution: The consent modal is displayed only after the page has fully loaded, with no pre-consent scripts, beacons, or trackers in the critical rendering path.
- Zero third-party execution before consent: No Google Tag Manager, ad tech, telemetry, or analytics logic is loaded or initialized before the user has made a clear and informed choice.
- Verified by design: Pre-consent network traffic is validated using HTTP analysis, HAR files, and automated privacy scans to ensure that no unauthorized processing occurs.
This model is already powering real websites.
AesirX CMP is an operational example of this privacy-first architecture. It is fully self-hosted, executes no third-party requests, includes optional load of GTM until after consent, and includes tooling to verify compliance before deployment. This design respects the user’s rights - and it satisfies both the letter and the spirit of the law.
For businesses serious about compliance, this is the benchmark.
What Businesses Must Start Asking
If a CMP is collecting data about your users before consent, then it is not a consent tool. It is a data collection tool dressed in compliance branding.
That leads to a more fundamental question: why pay for a compliance solution that does not make you compliant?
If your CMP violates the very laws it claims to help you follow, then it is not reducing your risk. It is increasing it.
Real compliance cannot be outsourced blindly. It must be engineered with transparency, restraint, and respect for user rights. Anything less is just a legal fiction.
The businesses that win will be those that treat consent not as a checkbox, but as an unshakable foundation for trust.
Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO, AesirX.io
