TL;DR: Article 5(3) of the ePrivacy Directive is the EU’s only safeguard that requires consent before tracking begins. The answer isn’t handing control to big third-party consent hubs, which only create new cross-site tracking risks. Instead, the way forward is simple: keep consent first-party, respect signals like GPC, and build toward wallet and zero-knowledge proof solutions that give people real privacy without extra hassle.
On 16 September 2025, the Commission launched a call for evidence for its Digital Omnibus, aiming to streamline digital legislation while maintaining high standards of fairness and safety; the consultation runs to 14 October 2025.
This article outlines what the Digital Omnibus should do about cookies - preserve 5(3), ban centralized consent telemetry, and standardize enforcement tests.
The rule that works where GDPR can’t
The ePrivacy Directive Article 5(3) governs the moment of access - before any data is captured or classified. That scope is wider than “cookies”: it includes scripts, SDKs, pixels, localStorage, and fingerprinting techniques that fire on first paint. By contrast, the GDPR engages after data becomes personal, at which point telemetry may already have been emitted. That timing gap is why 5(3) matters today more than ever.
In modern stacks, tag managers and telemetry frameworks still bootstrap early, then ask for consent later. Where cookie-consent-as-a-service, invoicing telemetry, pixel trackers, or Google Tag Manager cause any access to or storage of information on a user’s device prior to valid consent, they are non-compliant under ePrivacy Directive Article 5(3). The tools themselves aren’t unlawful per se; but any design that causes pre-consent device access is. That isn’t a technical constraint - it’s a business choice. Keeping 5(3) strong ensures the default becomes “defer by design,” not “collect now, rationalize later.”
The map of Europe: alignment is not the problem
With Estonia as the only outlier that hasn’t expressly transposed 5(3), every EU Member State has implemented the device-access consent rule in national law. The UK and Norway run equivalent regimes. Enforcement is split (communications regulators vs. DPAs, sometimes both), but the legal baseline is surprisingly aligned. See below enforcement matrix for ePrivacy Directive Article 5(3) - Transposition & enforcers (EU-27 + UK + NO), status as of 16 Sep 2025.
The gap is enforcement, not law
Alignment on paper hasn’t translated to behavior online. Europe’s legal baseline is remarkably aligned; behavior is not. Our July scan of 36,500 Danish sites found that a majority still load Google Tag Manager before consent. Across hundreds of thousands of scans in EU countries, the UK and Norway, nearly three-quarters of sites remain non-compliant. Even public-sector sites underperform: 82% in Denmark and 91% in Sweden fired beacons pre-consent. Agencies and vendors know the rules; they’re gambling on the odds. Until early-load frameworks are treated as clear 5(3) violations - with repeatable tests and predictable penalties - non-compliance will remain the growth strategy.
Method: AesirX Privacy Scanner (based on EDPS Inspection Tool) + HAR Network analysis; country scans July–Sept 2025; details on request.
“Consent fatigue isn’t caused by 5(3). It’s caused by solutions that don’t implement 5(3) properly.”
The wrong fix: centralized consent hubs
Centralized “cookie management” sounds efficient but re-creates surveillance patterns. Any solution that calls a third-party hub on page load reveals when and where a person is browsing. At scale, those “consent pings” become a cross-site dossier - even if labeled anonymous. It also clashes with wallet and trust-framework principles, which rely on issuer-silent, unlinkable proofs.
Why “Central cookie management” can easily become surveillance by design:
- Phone-home consent pings reveal when and where a person visits.
- Cross-site linkability grows as one operator handles consent for millions of properties.
We must not fix banner fatigue by centralizing the consent layer.
The right fix: decentralized, first-party consent
This is proven and deployable. In our first-party CMP work and ongoing development, the pattern that preserves rights while simplifying UX is:
First-party by default
- Evaluate and store consent on the site’s own origin.
- No third-party calls before consent. No GTM bootstrap. No remote CMP telemetry.
User-controlled automation
- Respect GPC and similar signals as a valid default refusal unless the user actively overrides.
- Let people pre-set granular preferences using a digital wallet (by purpose/vendor/category). On opt-in, sign a local proof-of-consent.
Zero-knowledge compliance
- Prove “user consented to Purpose X at Time T” without revealing identity, browsing history, or wallet metadata.
- Keep flows issuer-silent so no external party learns where a proof is presented.
Audit without tracking
- Issue unlinkable consent receipts bound to domain, purpose, and a time window.
- Support revocation and expiry locally; allow verifiers to check validity without global IDs.
First-party consent and analytics help reduce legal risk and mitigate signal loss without surveillance. The net effect: fewer banners, faster pages, and valid proofs for auditors - without any “phone home”.
The Omnibus can close this gap without centralizing consent by codifying the practices that already work.
What the Digital Omnibus should adopt for cookies
- No device access before consent - full stop
Tag managers and telemetry frameworks count as device access. Default to defer by design. - Ban centralized consent telemetry
Prohibit remote CMP calls and identifier issuance before valid consent. Require consent checks to run first-party or on the user’s device. - Make signals work for people
Recognize GPC and equivalent as a refusal baseline unless the user affirmatively overrides. Allow wallet pre-sets to auto-apply user-chosen consents. - Embrace privacy-enhancing tech
Accept zero-knowledge proof-of-consent and issuer-silent flows as compliant evidence. Publish a reference profile for unlinkable receipts. - Align enforcement
Create a joint playbook for communications regulators and DPAs: repeatable script audits, network-trace tests, transparent remediation paths, and minimum penalties for systematic pre-consent loading. - Lead by example
Mandate strict compliance for public-sector websites first, then cascade to critical private services.
Early learnings and what we’re measuring
Our approach doesn’t change the legal baseline: first-party analytics, google tag manager, telemetry from cookie banners and any non-essential tags still require consent under 5(3), except in narrow, country-specific measurement exemptions. The value comes from how consent is handled - not from sidestepping it.
- Defer-by-default: All non-essential scripts and frameworks are held until a valid signal exists. This eliminates early-load violations and reduces network noise before a decision.
- Respect signals, reduce repetition: When a user has a pre-set refusal (e.g., via Global Privacy Control) the site can avoid re-prompting or show a single, lightweight prompt with everything off by default. That doesn’t remove the need for consent; it reduces repetitive nagging when the user already said “no.”
- Wallet pre-sets for opt-in, never for override: If a user proactively configures granular opt-ins in a digital wallet, those choices can be presented and signed on the site. Wallet pre-sets never override a user’s refusal signal by default; they express the user’s intent when the user chooses to proceed; users must actively opt in on-site.
- Operational gains: Deferring third-party bootstraps improves initial render performance; keeping proofs/receipts local streamlines audits and shortens incident investigations - without creating centralized telemetry.
This is work in progress and will be documented openly; proposals here are intended to guide the Omnibus, not to pre-judge its outcome.
Turning Rules into Results
- Policymakers and regulators: lock in first-party, decentralized consent; ban centralized consent telemetry; publish a common testing and enforcement playbook.
- Industry: stop loading anything pre-consent. Move consent, analytics, and tags first-party. Respect GPC.
- Wallets and civic-tech: ship user-friendly pre-sets and ZK consent proofs normal people can actually use.
- Readers: check the attached matrix to see who enforces 5(3) in your market - then check your own site’s first paint.
Simplification should mean fewer prompts and clearer choices - not a new surveillance layer. Keep ePrivacy Directive 5(3) strong, keep consent local, and give people tools that automate privacy without giving up their privacy.
The consultation runs to 14 October 2025 so if you care about privacy and your right to decide who can collect and use your behavioral data, now is the time to make your opinion known.
Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO, AesirX.io
Answering the Commission’s guiding questions
The Commission has published a one-page set of guiding questions for the Digital Omnibus consultation. I’m answering those questions directly below. That said, several prompts appear narrowly framed around “cookies” and seem to presuppose outcomes that lean toward centralization. My responses reflect a different premise: we can reduce consent fatigue without creating new surveillance layers.
Crucially, Article 5(3) covers all device access on terminal equipment - not only “cookies,” but scripts, SDKs, pixels, beacons, localStorage, fingerprinting, tag managers, and telemetry frameworks. Where the 1-pager speaks in cookie terms, I address the full scope of tracking technologies to avoid loopholes and ensure any changes protect users before collection begins.
1. How do you currently comply with Article 5(3) and GDPR, and where are the challenges?
We run defer-by-design: no non-essential device access (including tag managers and telemetry) until a valid signal exists; then we record consent with unlinkable, first-party receipts. GDPR obligations (lawful basis, transparency, rights handling) apply downstream to any personal data; 5(3) governs the upfront device access. The main challenge is inconsistent enforcement that rewards early-load designs over compliant ones.
2. What proportion of websites use cookies for advertising? Which could be acceptable without consent (e.g., statistics)?
Advertising and audience-building commonly rely on device access; under 5(3) they require prior consent, irrespective of whether data is personal at capture time. “Statistics” can be exempt only where narrowly defined in national law (limited, aggregate, privacy-preserving measurement). Broad “low-impact” carve-outs risk becoming a de facto tracking loophole. The safer route is to recognize refusal signals and streamline consent when users genuinely opt in.
3. What’s the right balance between transparency/choice and avoiding consent fatigue?
Stop re-asking when the user already refused. Treat Global Privacy Control as a standing “no” unless the user overrides on-site; when a user wants to opt in, let them pre-set granular choices in a local wallet and sign on-site. This reduces prompts without central telemetry or cross-site linkability.
4. Are there use cases where only non-personal data is processed?
Yes - but 5(3) applies to device access, not just personal data. If a script, SDK, or local storage is touched, consent is required unless strictly necessary for the service. Treating “non-personal” as a blanket exemption would re-open the door to covert profiling pipelines; enforcement should check device access first, classification of data second.
5. When is a legal person a “user,” and how is consent given?
In B2B contexts (corporate devices/browsers), the organisation can define defaults and governance, but the terminal equipment is still “user” under 5(3). Consent should be recorded on the first-party origin with non-linkable receipts; enterprise wallets or device-level signals can express the organisation’s preference - again, without central call-outs.
6. Could simplifying consent encourage privacy-enhancing tech?
Yes - if simplification bans centralized consent telemetry and validates privacy-preserving proofs. Recognizing zero-knowledge proof-of-consent and issuer-silent wallet flows would let sites prove compliance without creating cross-site dossiers. That’s simplification without surveillance.
7. Non-personal on-device use cases (compute, agents, transfers)?
Encourage on-device analytics and PETs that don’t export raw events; where device access is strictly necessary and no identifiers leave the device, Member States can define narrow, testable exemptions. But the default remains: no access before consent.
