The Omnibus & Consent: What Actually Changes - and What Still Doesn’t

For agency leads, product teams, and DPOs who must make this work in the real web stack.

What Brussels is aiming for - and where it lands on consent

The headline is “simplification.” In consent terms, it translates into three concrete shifts:

1) Device access moves under GDPR (new Art. 88a), not ePrivacy.

Reads/writes on the user’s device (cookies, SDKs, local storage, identifiers) are re-anchored in GDPR with a closed consent-free lane: (i) transmission, (ii) a service explicitly requested by the user, (iii) the controller’s own aggregated audience measurement, and (iv) security/maintenance. Anything outside that lane - e.g., third-party analytics, advertising, social pixels - still requires prior consent.

ePrivacy Directive 5(3) survives - but is displaced where GDPR 88a applies.
The final proposal does not repeal ePrivacy Directive 5(3). Instead, it routes device access/reading into GDPR whenever the operation involves personal data and falls within Article 88a. In practice, most real-world web/device access that touches personal data will be governed by 88a, not 5(3). The “pre-access shield” hasn’t vanished; it’s been re-anchored inside GDPR with a narrow, purpose-bound lane.

“5(3) survives, but 88a drives.”

A narrow consent-free lane under 88a.
Article 88a authorises processing of personal data “on or from terminal equipment” solely for four purposes: (1) transmission of a communication; (2) providing a service explicitly requested by the user; (3) the controller’s own aggregated audience measurement; (4) maintaining/restoring the security of the service or the user’s device. Repurposing is forbidden unless another Union/Member-State law says otherwise. Anything outside these four purposes still needs a lawful basis - and for non-essential tracking, that means prior consent.

2) Machine-readable choices (browser/OS signals).

Users can set a device-level, machine-readable refusal (and object to direct marketing). Controllers must honour it - except media services, which may ignore the signal and seek consent on-site. Standards will be drafted; obligations start after a short grace period.

3) A six-month cool-down on prompts.

If a user refuses for a given purpose, you cannot re-ask for at least six months. If they consent, you cannot keep prompting while that consent remains valid.

This does not erase the need for a consent interface. It resets the ground rules: easier refusal, fewer dark patterns, and fewer pop-ups - but only if you truly operate inside the consent-free lane. The moment your stack touches marketing tech, cross-site analytics, or profiling, a banner remains unavoidable.

Timelines

• Art. 88a (device access lane): applies 6 months after entry into force.
• Art. 88b (machine-readable signals): controller obligations start 24 months after entry into force (after standards are adopted).
• Browser/OS support for the signal: mandated 48 months after entry into force.

“The six-month do-not-reask isn’t a UX flourish; it’s a legal throttle on consent pressure.”

Why signals can’t replace consent

A lawful EU consent must be freely given, specific, informed, and unambiguous - and in practice, granular to the controller’s purposes and, often, vendors. A browser/OS signal is, by design, generic. It can say “refuse marketing” or “don’t track,” but it cannot present the contextual information a site must disclose to obtain a valid “yes,” nor can it capture a user’s informed selection across multiple concrete purposes and processors.

The upshot: signals are perfect to stop processing at the point of origin. They are not enough to start non-essential processing. For that, you still need a first-party consent flow that explains who/what/why and records an auditable choice.

Legally, 88b permits machine-readable consent if all GDPR consent conditions (specific, informed, unambiguous) are met; practically, generic category toggles won’t satisfy that for multi-vendor, multi-purpose stacks in practice.

“Browser/OS signals are fantastic for a universal no - they’re not a shortcut to a valid EU yes.”

The six-month rule in the real world

“No re-asking for six months” sounds simple; implementing it isn’t. If the refusal is to mean anything, the site has to remember it on that device. Practically, that means a first-party consent state stored on the user’s device (often a first-party cookie), scoped by purpose. There isn’t a realistic alternative if you want the suppression to work before anything loads and without fingerprinting gymnastics.

Two consequences follow:

• The suppression state is device-specific. If someone rejects on their phone, you can’t treat that as a rejection on their laptop unless you re-establish the preference there.
• A banner that already presents a clear “Reject all” or “Refuse” at the same level as “Accept all” will meet the one-click refusal expectation - provided you actually suppress re-prompts for six months for the refused purposes and block the processing in the meantime.

This is also why claims that “half of EU sites will drop banners” are fantasy. The six-month window reduces how often you can ask, not whether you must ask when your stack needs consent.

First-party analytics as an illustration - vs GA4-style stacks

The new consent-free lane for the controller’s own aggregated audience measurement is deliberately narrow. If your analytics are truly first-party, aggregated, kept for your own use, and not repurposed or shared, you can likely run them without consent under Article 88a.

That is not how a typical GA4 setup works. GA4 (and Ads/remarketing) involve third-party processing and wider advertising ecosystems. Loading those tags means device access plus transmission to a third party, which sits outside the 88a lane and still requires valid, prior consent. “We anonymize later” doesn’t retrofit lawfulness where device access and third-party transmission already happened.

Put simply: 88a’s audience-measurement lane is controller-only and strictly purpose-bound. GA4/Ads/remarketing are, by design, outside that lane and remain consent-bound before the first hop.

“Anonymize later’ doesn’t fix ‘process first.’ Lawfulness lives - or dies - at the first hop”

Google Tag Manager, Consent Mode & “consent signals”

There’s a lot of wishful thinking around GTM and Google Consent Mode. The Omnibus doesn’t change the fundamentals:

1) GTM itself is a third-party load.

The bootstrap request to googletagmanager(.)com is a third-party network call (Some teams self-host the bootstrap; if any tag still calls Google/other third parties pre-consent, you’re outside 88a.). That’s processing (at least IP/UA, headers, TLS metadata) and typically outside any consent-free lane. If your page needs non-essential tags (ads, third-party analytics, social), you cannot justify loading GTM prior to a valid “yes.” Consent Mode doesn’t rewrite that.

2) Consent Mode isn’t consent.

Consent Mode communicates a state (“granted/denied”) to Google tags; it doesn’t create a lawful basis. If the user hasn’t given an explicit, informed, granular “yes,” you don’t get to process just because a consent state exists in the page.

3) “Advanced” Consent Mode sends pings when consent is denied.

That’s the whole point of Advanced: cookieless pings for modeling. But cookieless ≠ lawless. Those pings are still processing and transmission to a third party, which falls outside the consent-free purposes. In EU terms, that requires valid consent before the first ping. If you use Advanced pre-consent, you’ve already crossed the line the Omnibus is trying to draw.

4) “Basic” Consent Mode is closer to compliant - but only if nothing phones home.

If Basic is configured so no GA4/Ads beacons fire until consent, fine. But the moment anything hits a Google endpoint before a “yes,” you’re back in consent territory. The test is brutally simple: no network calls to analytics/ads domains until consent is logged.

5) “Sending consent signals” ≠ “green light to track.”

Google accepts TCF strings and Consent Mode states. Good - send them after you’ve actually obtained consent, not as a workaround to get consent. A “denied” signal is useful to stop Google tags; it’s not a license to send “denied-mode” data for modeling.

6) Server-side GTM doesn’t magically become first-party analytics.

A server container can reduce client-side noise, but if data still flows to Google services (GA4/Ads/Google BigQuery) or other third parties, you are not in the “own aggregated audience measurement” lane. You’re still doing third-party analytics/marketing and you still need consent upfront.

7) The Omnibus favors true first-party measurement - not adtech workarounds.

The consent-free lane is intentionally narrow. It rewards controller-only, aggregated measurement that doesn’t leak into ads or cross-service profiling. GA4/Ads/Remarketing are, by design, outside that lane.

“Consent Mode’ can reflect a user’s decision; it cannot replace one.”

Why Most Cookie SaaS Still Isn’t Compliant

A stubborn constant since 2002: most “cookie consent as a service” (CCaaS) products still track before consent. This isn’t about banner copy - it’s the plumbing. Typical CCaaS flows make third-party calls before a user can decide to do IP-based geolocation (show/hide or localize the banner), send telemetry for invoicing/usage, run A/B tests, or fire the vendor’s own pixels/CDN assets. That already engages ePrivacy Directive 5(3) (no storing/reading on the user’s device without prior consent) and often processes personal data (IP, headers, IDs).

The Omnibus doesn’t bless that pattern. It re-anchors the pre-access shield inside the GDPR via Article 88a. That article only allows device-level storage/access without consent in a tight, purpose-bound lane: (1) pure transmission, (2) a service explicitly requested by the user, (3) the controller’s own aggregated audience measurement, and (4) security/maintenance. Anything else - especially third-party calls to a CCaaS cloud for geo, billing, or vendor analytics - falls outside 88a and remains consent-bound before the first request.

Why the common CCaaS model is still unlawful in practice

• Pre-consent geolocation. Using IP to decide whether/which banner to show is not “pure transmission” or “security,” and it’s not the user-requested service - it’s your compliance UI. ePD 5(3) + 88a means don’t call out (or read/write on the device) until you have a lawful basis.
• Telemetry for billing/metrics. CCaaS “impressions” and plan-tracking beacons aren’t the controller’s own audience measurement. They’re third-party vendor analytics - outside 88a - so they must be blocked until consent.
• Vendor pixels / third-party assets. Pulling fonts, scripts, and UX trackers from the vendor’s domains exposes IP/referrer and often writes client storage. If that’s not squarely within 88a’s four purposes, it requires prior consent.

“ePrivacy Directive 5(3) set the rule; Omnibus 88a restates it with a narrow lane.
Most CCaaS still breaks the chain by tracking before consent.”

The media-services carve-out

Under the final text, machine-readable browser/OS signals are introduced (Article 88b) with controller obligations starting six months after the relevant standard(s) are adopted. However, controllers that are media service providers are exempt from the obligation to honour those signals when providing a media service. In plain terms: the universal device-level “NO” exists - yet media services may lawfully ignore it and present their own on-site consent flow instead. That’s not user-choice interoperability; it’s an industry-scale exception to it.

This isn’t a technical footnote; it’s a policy signal that undermines everything the browser/OS signal is meant to achieve: interoperable, enforceable refusal at the point of origin. If the biggest trackers can ignore that signal, the outcome is predictable:

• Interoperability breaks. California/Colorado make the signal binding; the EU would bake in a major exception. Same browsers, opposite rules.
• Dark patterns return by the front door. The signal says “no,” but the site can still herd the user into a bespoke flow - nudges, paywalls, “accept to read,” or 900-partner dialogs dressed as “choice.”
• Enforcement becomes incoherent. Controllers outside media must honor the signal; media players don’t. The same user action yields different legal effects depending on content category, not on user choice.
• Competition is distorted. Small/independent publishers who try to respect the signal will be at a disadvantage against large media networks that can ignore it and capture more data.
• Trust erodes. Users are told to set a device-level preference - and then learn that some industries can discard it. That’s how you teach people that privacy controls are theater.

The carve-out also conflicts with the spirit of ePrivacy Directive 5(3), which puts the user in charge at the device boundary: no storing/reading without prior consent. Moving consent into the GDPR while carving out media services flips the sequence: store/read first, argue consent later. That’s not simplification; it’s permission to route around refusal where tracking is most entrenched.

“If a universal browser signal can be ignored by the biggest trackers, it stops being a right and becomes a UX suggestion.”

And no, “journalistic freedom” is not a magic key that unlocks behavioral advertising. Freedom of the press protects content and speech, not an industry’s entitlement to share behavioral data with adtech and data brokers in defiance of an explicit user signal. If lawmakers want to subsidize media, say so honestly - don’t do it by taxing citizens’ privacy.

“Call it what you like - ‘media sustainability,’ ‘flexibility,’ ‘special context.’ In practice,it’s a built-in exception to user refusal, exactly where refusal matters most.”

If the EU is serious about harmonisation and user agency, the fix is obvious: make the signal binding for everyone, including media. Anything less is a loophole with a press badge.

National law reality check

The ePrivacy Directive’s 5(3) rule (“no storing/reading without prior consent”) remains in national laws across the EU. The Omnibus doesn’t repeal those provisions overnight; it re-anchors device access inside the GDPR when the operation involves personal data and fits Article 88a. Practically, that creates a two-gate landscape during the transition:

• Inside 88a: GDPR governs (within the four purpose-bound, consent-free lanes), and national 5(3) gives way to the new GDPR route.
• Outside 88a: classic national 5(3) continues to apply (e.g., certain non-personal reads or contexts not captured by 88a).

Because 5(3) remains on the books until (26 out of 27) Member States amend their national ePrivacy transpositions, expect a period of overlap and fragmentation while regulators and courts sort which gate applies in specific scenarios. Parliamentary updates will be needed in each country to align national texts with the new EU-level structure; until then, guidance and decisions will do most of the bridging.

Commission cost-saving assumptions - banner reductions and ‘statistics’ exemptions - vs. observed MarTech stacks.

The numbers problem: fabricated assumptions, real-world stacks

A striking part of the Omnibus narrative is the promise of enormous cost savings from “fewer banners” (Staff Working Document accompanying the Proposal, page 52) relying on tables that assume half of European websites will no longer need a banner and that public-sector cookies for statistics will mostly fall into consent-free use. On paper, that makes for handsome totals (billions in productivity, hundreds of millions in admin savings). In practice:

• We ran a country-level scan in Denmark (July 2025) across 36,500 websites using our Privacy Scanner based on the EDPS Inspection Tool. The picture this scan reveals is the one practitioners know: the majority of live sites load Google Tag Manager, GA4, Google Ads, Meta/Facebook Pixel, TikTok, and other third-party tags by default - 73% of all sites were non-compliant under the ePrivacy Directive 5(3), 55% loaded GTM prior to consent.
• None of those popular marketing/measurement tools fall into the “own aggregated audience measurement” lane. They require consent before access and transmission.
• We ran a country-level scan in Denmark and Sweden (August/September 2025) across all municipalities' websites and found 82% in DK and 91% in SE to be non-compliant under ePrivacy Directive 5(3).
• A higher percentage would fall into the “own aggregated audience measurement” lane compared to the private sector; the findings in general were on average found to involve far less third parties.
• The claim that “half of EU sites” will simply shed banners ignores how modern sites are actually built and monetized.

In other words, the assumption base of the savings table is detached from today’s MarTech reality. It counts hypothetical “no-banner” sites that, when you look at the network trace, still need banners because they rely on third-party stacks.

A qualified estimate. Based on our July 2025 country-level scan in Denmark (36,500 sites) and comparable client audits across the EU, only ~12–18% of live sites today would plausibly qualify for a banner-free operation under the Omnibus’s narrow lane (essential operations + the controller’s own, aggregated audience measurement, with no third-party beacons or repurposing). In the public sector, despite some Matomo/self-hosted moves, the effective banner-free share is likely below 20% once you factor in widespread GTM use, embedded players (YouTube/Vimeo), maps, A/B tools and telemetry. Even with disciplined remediation, we don’t see the overall EU figure rising much above ~25% without dropping common third-party embeds; for media and e-commerce, the practical share is near zero unless their business model changes. In short: “half of EU sites” losing banners is not an evidence-based prediction - it’s an assumption that ignores how the modern MarTech stack actually ships.

“The savings table counts websites that don’t exist - at least not in real European traffic logs.”

A reality check

This is a Commission proposal, not law. Parliament and Council can still amend it and, even after adoption, there’ll be lead time for standards (Art. 88b) and Member-State updates to ePrivacy transpositions. In the near term, don’t expect pop-ups to vanish - expect them to get stricter: one-click refusal, a six-month do-not-reask window, and genuine block-before-consent. Browser/OS signals will matter mainly as a universal no that stops processing at the first hop; they still can’t deliver a valid EU yes (granular, specific, informed, explicit). The consent-free lane for own aggregated audience measurement will reward truly first-party setups; most third-party stacks will still require consent before they load. And unless the media carve-out changes, that sector remains the flashpoint where user signals meet industry workarounds.

Add to that the shaky impact tables: they assume “fewer banners” in a web that still runs GTM/GA/ads/pixels by default. The savings look good on paper, but they don’t match real traffic logs or deployment patterns.

If you take one thing forward, make it this: design for clean refusal, remove the nag loops, and be able to prove that nothing runs before a valid yes. Those foundations won’t age badly whatever tweaks the text undergoes. Ship now what’s future-proof: block-before-consent, purpose-level suppression for six months, and a first-party audit trail of what happened and when.

“The text will move; the principle won’t: no non-essential processing until the user actually says yes.”

Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO @ AesirX.io