Cookie banners have been a routine part of users’ experience online and a frequent source of frustration. Users are asked to make the same choices repeatedly, often with limited context, leading to what regulators increasingly refer to as “consent fatigue.”
The EU’s Digital Omnibus proposal, published on 19 November 2025, wants to simplify this experience. At the center of the discussion are machine-readable consent signals: a model where users could define their privacy preferences once, at browser or device level, and have them automatically applied across websites.
This marks a potential shift in how consent is expressed and managed. One that could reduce friction, but that also introduces new considerations around interoperability, control, and implementation in practice.
Here’s what digital professionals need to know about how it works, what the proposal says, and what it means for your stack.
In short: A shift in mechanism, not in requirement
With Digital Omnibus, consent isn’t going away. What’s changing is how it’s expressed, remembered, and enforced across systems.
With browser- or device-level preference signals on the horizon, users could set their privacy choices once, rather than responding to the same banner on every visit. This doesn’t change whether consent is required. It changes the mechanism.
For this to work in practice, machine-readable consent signals need to be interoperable with existing standards, trigger real technical behavior across websites and services, and avoid concentrating control in a few platforms.
Over time, users may see fewer repetitive prompts. But behind the scenes, the job doesn’t get smaller:
– different signal sources (banners, browsers, apps),
– multiple downstream systems (analytics, advertising, data platforms),
– ongoing requirements for proof and enforcement.
This shift adds a new layer of complexity. Browser signals will become another input that your Consent Management Platform (CMP) will have to work with. They don’t replace your CMP. Instead, they extend the range of signals CMPs must handle to ensure preferences are correctly applied across systems.
What are browser consent signals?
A browser consent signal is a standardized, automated way for a browser or operating system to communicate a user’s privacy preferences to a website.
Think of it as a technical instruction rather than a visual prompt: instead of relying only on banners and clicks, a site could read a previously-expressed preference and act on it automatically.
This concept isn’t entirely new.
Would consent signals under the Digital Omnibus be similar to the Global Privacy Control (GPC)?
Browser signals like Global Privacy Control (GPC) already exist and are recognized under legislations such as the US’s California Consumer Privacy Act (CCPA), where users can express certain privacy choices at the browser level.
However, GPC operates within a different legal framework (primarily opt-out systems) and is typically limited to specific types of processing, such as the sale or sharing of personal data.
Applying a similar approach in the EU raises additional complexity. Under the GDPR, consent must be specific, informed, and tied to particular purposes and controllers. Translating these requirements into a standardized, machine-readable signal that works consistently across websites, vendors, and use cases is significantly more complex than existing opt-out signals.
Currently, some browsers like Firefox already support GPC natively. Others don’t, but allow it through third-party extensions.
That’s about to change. California’s Opt Me Out Act (AB 566), signed in October 2025, requires all major browsers, including Chrome, Safari, and Edge, to offer a built-in opt-out preference signal by January 1, 2027.
Article 88b: what the Digital Omnibus proposes
The Digital Omnibus proposal introduces the idea of browser consent signals into the EU regulatory framework through a new Article 88b:
- Article 88b would require data controllers to support automated mechanisms that allow users to give or refuse consent, as well as exercise their right to object. Websites would need to respect these signals once expressed, rather than repeatedly prompting users through individual banner interfaces.
“Data subjects shall be able to provide consent / exercise the right to object through automated and machine-readable means. Standards are foreseen to be drafted by one or more European standardisation organisations.” – Digital Omnibus legal text
- The proposal also places obligations on browser providers (other than SMEs) to enable the technical infrastructure needed for these automated signals.
- The European Commission would mandate standardization bodies to develop the necessary technical standards, and controllers who follow those standards would benefit from a presumption of compliance.
- Users could also express preferences through tools like the EU Digital Identity Wallet.
One notable exemption: media service providers are explicitly excluded from the obligation to respect browser signals. The Commission argues that media organizations depend on advertising revenue for financial sustainability. This exemption does not extend to other types of websites, apps, or online services. More on this here.
How would browser signals work on a technical level?
If adopted, browser consent signals would introduce a new layer in how user preferences are communicated and enforced across the digital ecosystem.
While the exact specifications are still to be defined, the overall architecture would likely involve several components working together:
| On the user side | At the signal level | On the enforcement side |
|---|---|---|
| Users could set their privacy preferences through different interfaces, such as browser settings, operating systems, or dedicated tools. These preferences may range from broad choices (e.g. accept or reject tracking) to more granular configurations, depending on how standards evolve. | Those preferences would be translated into a machine-readable format and transmitted automatically when a user interacts with a website or service. The final structure of these signals, including how purposes, vendors, and legal requirements are represented, will depend on the standardisation work currently under discussion at EU level. | Websites and services would need to interpret and act on these signals. In practice, this is where Consent Management Platforms (CMPs) play a central role: receiving signals from different sources, reconciling them with site-specific configurations, and ensuring that scripts, tags, and data flows are activated or blocked in line with user preferences and legal requirements. |
As this framework develops, interoperability between browsers, websites, vendors, and consent systems is critical.
Industry stakeholders, including CMP providers like iubenda, are actively contributing to discussions around standardisation to help make sure any future solution is technically feasible, meets legal requirements, and works across the ecosystem.
What’s not changing
Consent isn’t going away. The Digital Omnibus doesn’t remove the consent requirement. It changes how preferences get expressed and transmitted.
Here’s what stays the same:
- Consent is still required for advertising, profiling, cross-site tracking, and most third-party analytics.
- The core opt-in model remains intact.
- Users who haven’t configured browser-level preferences will still see and interact with banners as usual.
- CMPs are still needed to trigger banners when no signal is detected, let users manage granular preferences for a particular site, store proof of consent, and enforce scripts based on preferences.
What’s the timeline for Digital Omnibus requirements?
The Digital Omnibus was published by the European Commission on 19 November 2025. It is a proposal, not law, and the text may change substantially during negotiations between the European Parliament and the Council.
Your current obligations under the GDPR and ePrivacy Directive remain fully in force, and no action is required until the text is finalized and adopted.
If adopted as proposed, the phased rollout would look like this:
| Phase | Timing |
|---|---|
| Entry into force | 20 days after publication in the Official Journal |
| Cookie/terminal equipment rules (Art. 88a) | 6 months after entry into force |
| Machine-readable signals (Art. 88b) apply to controllers | 24 months after entry into force |
| Browser/OS must provide built-in signal support | ~48 months after entry into force (SMEs exempt) |
What this means for iubenda users
At iubenda, we support the direction of simplifying consent experiences and reducing consent fatigue, without compromising user control. These are principles we’ve been building toward from the start.
At the same time, the shift toward browser signals introduces new layers of complexity. For this model to work in practice, user preferences from different sources need to be interpreted, reconciled, and enforced consistently.
This is where consent infrastructure matters. Our products are designed to handle multiple types of consent signals, enforce preferences across vendors and technologies, and adapt as standards evolve.
At iubenda, we’re on it
- Our legal team is tracking every development closely at a global level: the progress of the Digital Omnibus through EU negotiations, the evolution of GPC as a recognized opt-out signal, and any technical standards that emerge from the EU standardization process.
- When requirements become final, we’ll translate them into clear, practical guidance and product updates so your setup stays aligned without you having to decode the legislation yourself.
- Our Privacy Controls & Cookie Solution already reads GPC signals and is built to adapt as new signal sources emerge. We’ll make sure it keeps pace.
Disclaimer: This post discusses a legislative proposal, not final law. The content reflects iubenda’s interpretation as of March 2026 and should not be relied upon as legal advice. Consult your own legal counsel for guidance specific to your business.