A guide for actual compliance in consent management
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR
Most cookie consent tools were never designed to enforce the ePrivacy Directive (Article 5(3)) or modern privacy laws beyond the EU. They often load tracking technology before consent, misclassify “technical necessity” purposes, geo‑gate banners with pre-consent IP lookups in ways that ignore laws outside Europe and rely on non‑compliant third‑party infrastructure (like GTM/Consent Mode).
Below are the five most common failure patterns we see - and how to fix them with a first‑party, consent‑before‑tracking approach.
</div>
<h2>Reason 1: It treats privacy as “just cookies” (ignoring device access)</h2>
Most CMPs focus on dropping/reading cookies after the page has already executed third‑party scripts.&nbsp;
But ePrivacy Directive <a href="https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf" target="_blank" rel="noopener">Article 5(3)</a> covers any storage or access to information on the user’s device - that includes beacons, pixels, SDKs, localStorage, fingerprinting and telemetry.&nbsp;
If your tool doesn’t strictly gate all non‑essential device access until the user says yes, it’s not compliant.
<h3>Symptoms</h3>
<ul>
<li aria-level="1">Banners look right, but tags fire in the background.</li>
<li aria-level="1">“Cookie categories” exist, yet scripts for pixels/SDKs run before choices are saved.</li>
<li aria-level="1">A tag manager is considered “essential,” so nothing is actually blocked.</li>
</ul>
<h3>What good looks like</h3>
<ul>
<li aria-level="1">Block all non‑essential scripts, pixels, and telemetry by default (not just cookies).</li>
<li aria-level="1">Ask for informed, explicit consent before any device access.</li>
<li aria-level="1">Load the consent layer from first‑party infrastructure.</li>
</ul>
<h2>Reason 2: It loads tracking or telemetry before consent (including CMP pixels)</h2>
Some consent tools embed their own pixels, SDKs, or call home for usage‑based billing and dashboards.&nbsp;
If those calls include IP address, identifiers, or other device signals before a user agrees, that’s pre‑consent tracking - no matter what the UI says.
<h3>Symptoms</h3>
<ul>
<li aria-level="1">Network logs show requests to CMP or analytics domains on first paint.</li>
<li aria-level="1">“Metering”/“usage”/“pageview” requests fire even when users reject.</li>
<li aria-level="1">The CMP’s dashboard shows traffic counts without consent.</li>
</ul>
<h3>What good looks like</h3>
<ul>
<li aria-level="1">Make no third-party calls before consent (including invoicing/telemetry).</li>
<li aria-level="1">Limit logging to strictly necessary first-party data for service delivery.</li>
<li aria-level="1">Store consent choices locally/first-party until a lawful basis exists to transmit.</li>
</ul>
<h2>Reason 3: It geo-gates consent with Geo-IP lookups (and ignores non-EU laws)</h2>
Geo-IP gating - “show the banner only in Europe” - assumes only EU rules matter and quietly processes IP addresses to decide who sees controls. That IP lookup itself is pre-consent data processing, non-compliant and often inaccurate or blocked. With 140+ jurisdictions having privacy laws that require consent, notice, or opt-out, hiding your banner outside the EU risks unlawful tracking and erodes trust.
<h3>Symptoms</h3>
<ul>
<li aria-level="1">Banner appears in the EU, disappears elsewhere.</li>
<li aria-level="1">U.S./UK/ROW traffic gets tracked without any notice or control.</li>
<li aria-level="1">IP-based location checks run pre-consent and may be logged or shared with third parties.</li>
</ul>
<h3>What good looks like</h3>
<ul>
<li aria-level="1">Adopt one consent model that respects regional rules globally.</li>
<li aria-level="1">Avoid pre-consent IP lookups for gating access.</li>
<li aria-level="1">Do not rely on imprecise IP detection to decide whether users deserve consent.</li>
</ul>
IP addresses are personal data under GDPR - see Art. 4(1); <a href="https://curia.europa.eu/juris/document/document.jsf;jsessionid=8B8D0D233286A4B49CC65C8D06166ABD?text=&amp;docid=184668&amp;pageIndex=0&amp;doclang=EN&amp;mode=lst&amp;dir=&amp;occ=first&amp;part=1&amp;cid=4351590" target="_blank" rel="noopener">CJEU Breyer C-582/14</a> confirms even dynamic IPs can identify a person in context.
<h2>Reason 4: It relies on remote GTM and/or Consent Mode 2.0</h2>
Loading a tag manager from a third‑party domain (e.g., googletagmanager.com) or deferring to “Consent Mode 2.0” does not prevent pre‑consent access.&nbsp;
The moment GTM is fetched, your user’s device and referrer/IP are already exposed; many sites still initialize tags and transmit signals in “denied” states. That violates consent-before-access.
<h3>Symptoms</h3>
<ul>
<li aria-level="1">GTM is injected in the and executes before the banner.</li>
<li aria-level="1">Third‑party domains initialize regardless of the user’s choice.</li>
<li aria-level="1">“Assume consent” defaults or data pings occur in denied/unknown states.</li>
</ul>
<h3>What good looks like</h3>
<ul>
<li aria-level="1">Do not load remote GTM or any third‑party tag frameworks before consent.</li>
<li aria-level="1">Gate all marketing/analytics until the user opts in.</li>
<li aria-level="1">Use a first‑party consent shield that blocks at the system level.</li>
</ul>
<h2>Reason 5: It outsources lawfulness to ad frameworks instead of enforcing blocking</h2>
Pointing to industry frameworks like IAB TCF consent strings or GPP vendor signals isn’t compliance if scripts still execute and device access occurs before a choice. Consent must be prior, informed, freely given, and technically enforced - consent strings are metadata, not a gate; UI without real blocking is theater.
<h3>Symptoms</h3>
<ul>
<li aria-level="1">A valid-looking IAB TCF consent string or GPP signal exists, yet trackers initialize pre-choice</li>
<li aria-level="1">“Essential” is overused to whitelist ad/measurement tags that aren’t truly necessary</li>
<li aria-level="1">Banner toggles flip, but a CDN/tag manager still lets rogue pixels fire</li>
</ul>
<h3>What good looks like</h3>
<ul>
<li aria-level="1">Enforce hard blocklists/allowlists from first paint so nothing non-essential runs pre-consent.</li>
<li aria-level="1">Activate purposes granularly only after a recorded, valid consent signal.</li>
<li aria-level="1">Maintain audit-ready logs proving when consent was obtained and exactly which vendors/tags activated.</li>
</ul>
“If your banner says ‘no,’ but your network tab still shows third-party requests, that’s pre-consent access. Full stop.”
<img src="https/api.aesirx.io/images/images/Consent-first_load_order.png" alt="Consent first load order" width="1280" height="728" />
Consent-first load order (no device access pre-choice).
<h2>So - what does compliant look like in practice?</h2>
→ Pre-consent handling: Obtain consent before any non-essential device access (scripts, pixels, telemetry, storage, SDKs).
→ First-party by design: Load the consent UI and enforcement from your own domain or dedicated first-party infrastructure.
→ System-level blocking: Enforce hard blocks until opt-in; do not assume or simulate consent.
→ Granular purposes &amp; transparency: Provide clear descriptions, offer specific switches, and enable friction-free revocation.
→ Global readiness: Honor regional rules (EU GDPR/ePrivacy, UK PECR, US state laws - e.g., CCPA/CPRA, Vietnam/India PDPL, Norway Ekom Act) and signals like Global Privacy Control (GPC).
→ Proof: Maintain audit-ready logs of choices, purposes, versions, and activations.
Notice: If you want to check if you have a problem on your website or e-commerce solution you can test your site in our <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">free privacy scanner</a>.
<h2>Action checklist</h2>
<ol>
<li aria-level="1">✅ Scan your site for pre‑consent access (scripts, pixels, telemetry, SDKs).</li>
<li aria-level="1">✅ Eliminate remote GTM/Consent Mode pre-consent; gate all tags post‑opt‑in.</li>
<li aria-level="1">✅ Remove CMP telemetry (usage‑based calls) until after consent - or move to first‑party.</li>
<li aria-level="1">✅ Stop geo‑gating: implement a global policy that respects regional rules and GPC.</li>
<li aria-level="1">✅ Adopt a first‑party CMP; enable system-level blocking; keep audit logs.</li>
<li aria-level="1">✅ Document purposes &amp; third parties in plain language; enable granular toggles and instant revocation.</li>
<li aria-level="1">✅ Schedule ongoing monitoring (daily/weekly) to catch regressions and rogue tags.</li>
</ol>
“Don’t bankroll fake consent. If ‘no’ doesn’t stop access, you’re paying for non-compliance.”
Ronni K. Gothard Christiansen, Technical Privacy Engineer &amp; CEO @ <a href="http://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>
<h3>About AesirX</h3>
AesirX builds first‑party consent and analytics solutions that enforce privacy at the system level - so you can stay compliant, earn user trust, and still get the insights you need.

Learn the top 5 compliance failures in cookie consent tools and how to meet GDPR requirements with true consent-before-tracking & safer data practices.

5 Reasons Your Cookie Consent Tool Fails Compliance

Blog Consent Management Platform

Learn the 5 key compliance failures in cookie consent tools and how to meet GDPR / ePD 5(3) requirements with true consent-before-tracking.

5 Reasons Your Cookie Consent Solution Isn’t Compliant

Many global sites hide consent banners outside Europe, adding tracking and legal risk. Learn why true compliance means global opt-in consent, not EU-only privacy theatre.

Ignorance or Arrogance? Why Hide Consent Outside Europe

Blog Aesirx

Many websites only show consent in Europe, creating hidden tracking risks abroad. See why real compliance requires global consent controls, not EU-only settings.

Ignorance or Arrogance: Hiding Consent Outside EU

<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
TL;DR
<ul>
<li>Goal: Respect over retargeting. Default to data minimization - collect only what’s needed to serve the visitor.</li>
<li>What’s new:&nbsp;<a href="https://aesirx.io/blog/press-release/aesirx-cmp-for-wordpress-v2-0-2-stop-the-phone-home-permanently" target="_blank" rel="noopener">“Permanent Block” in AesirX CMP v2.0.2</a> lets you stop non-essential third-party collection forever.</li>
<li>Why it matters: Fewer silent “phone-home” calls, less profiling, simpler audits, lower vendor risk.</li>
<li>How to use: In Privacy Shield, set non-essential plugins or domains/paths (e.g., telemetry, old pixels) to Block permanently, then verify with privacyscanner.aesirx.io.</li>
</ul>
Promise: If it isn’t essential to serve your visitor, it never loads.
</div>
There’s a quiet moment that happens on most websites long before a person clicks “Accept.”
A script phones home.
A pixel wakes up.
A background request ships a tiny slice of your visitor - where they came from, what device they’re on, often enough to stitch a profile together somewhere far away.
That’s not respect. It’s not necessary. And starting today, it’s not inevitable.
With AesirX CMP for WordPress v2.0.2, we’re introducing “<a href="https://aesirx.io/blog/press-release/aesirx-cmp-for-wordpress-v2-0-2-stop-the-phone-home-permanently" target="_blank" rel="noopener">Permanent Block</a>” - a simple control with a clear ethic: if a third party isn’t essential to serving your visitor, it never loads. Not “until consent.” Not “once they click the big green button.” Never.
<h2>The problem isn’t just consent. It’s excess.</h2>
Consent banners were meant to restore agency. But banners alone can’t fix a culture of collect first, justify later. Too many extensions still export data by default: telemetry “for product improvement,” convenience SDKs that quietly create identifiers, embeds that pull in trackers the moment the page renders.
The ethic we believe in is simpler - and older than any framework: collect less. Gather only what’s needed to provide the thing a person asked for. Keep it close. Make “no unnecessary third parties” your default, not your exception.
“Permanent Block” operationalizes that ethic in your stack. It’s a switch that says, “This integration is not essential, and it does not get to take anything from my users.”
<h2>What “Permanent Block” actually does</h2>
Inside Privacy Shield, every listed plugin and every Domain/Path rule now has two behaviors:
<ul>
<li aria-level="1">Block until consent (default): Don’t load until the user opts into that category.</li>
<li aria-level="1">Block permanently (new): Never load - regardless of consent choices elsewhere.</li>
</ul>
<a href="https://github.com/aesirxio/wordpress-consent-plugin/releases/tag/2.0.2" target="_blank" rel="noopener">Choose Permanent and AesirX CMP</a> prevents that target from running at all. We intercept script tags, iframes, pixels, beacons, and network requests aimed at the domains/paths you specify. The result is straightforward: if you mark it permanent, <a href="https://aesirx.io/blog/press-release/aesirx-cmp-for-wordpress-v2-0-2-stop-the-phone-home-permanently" target="_blank" rel="noopener">no data leaves the browser for that destination</a>.
This isn’t about breaking your site; it’s about drawing a line around what’s truly required. Your store should run; your content should load; your security and accessibility should work. But exporters that aren’t essential? They’re out.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/choose-permanent-block-per-domain-path-new.png" alt="choose permanent block per domain path new" width="1884" height="902" />
Choose “Permanent Block” per&nbsp; domain/path
<h2>When should you block permanently?</h2>
Use “Permanent Block” when a third party:
<ul>
<li aria-level="1">Exports data that isn’t required to deliver what the user requested (e.g., telemetry collectors or “improve our service” beacons).</li>
<li aria-level="1">Duplicates a capability you already provide on your own systems (so there’s no reason to send data away for it).</li>
<li aria-level="1">Introduces disproportionate risk through cross-site tracking, profiling, or opaque processing chains.</li>
<li aria-level="1">Arrives as a side effect of a convenience feature (for example, certain embeds that set identifiers by default).</li>
</ul>
A few common candidates:
<ul>
<li aria-level="1">Telemetry baked into utilities that don’t need to measure your audience to do their job.</li>
<li aria-level="1">Old pixels and helper libraries left behind after a tooling change.</li>
<li aria-level="1">Media or social embeds that load trackers immediately when a page renders.</li>
</ul>
None of these are required to show a page, run a checkout, protect a login, or fulfill an order. If they don’t serve your visitor’s immediate purpose, mark them permanent and move on.
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
<h3>Example: Jetpack “phone-home” and how to stop it</h3>
Jetpack (by Automattic) is bundled by default on WordPress.com-hosted sites, and it’s also widely deployed on self-hosted WordPress (the plugin directory lists 5M+ active installs; including WordPress.com sites, the overall footprint is commonly estimated well into the tens of millions, often cited as 15M+). It provides a lot of features - but several modules also call back to Automattic servers for stats and telemetry.
<h3>What typically leaves the browser</h3>
When Jetpack’s statistics/telemetry features are active, your visitor’s browser can contact endpoints like:
<ul>
<li aria-level="1">stats.wp.com - site stats beacons</li>
<li aria-level="1">pixel.wp.com - tracking pixel requests</li>
<li aria-level="1">public-api.wordpress.com - service/telemetry API calls</li>
<li aria-level="1">(Occasionally) s0.wp.com / i*.wp.com - asset/CDN pulls, depending on modules</li>
</ul>
These requests can occur early in the page lifecycle and may set or transmit identifiers that aren’t strictly necessary to serve the page your visitor asked for.
<h3>How to stop it with “Permanent Block” (1 minute)</h3>
<ol>
<li aria-level="1">WP Admin → AesirX CMP → Consent Shield → Domain/Path Blocking</li>
<li aria-level="1">Add rules for the Jetpack endpoints you don’t need (start with the stats/telemetry pair):
<ul>
<li aria-level="2">stats.wp.com → Block permanently</li>
<li aria-level="2">pixel.wp.com → Block permanently</li>
<li aria-level="2">(Optional, module-dependent) public-api.wordpress.com → Block permanently</li>
</ul>
</li>
<li aria-level="1">Save and reload a page - those calls won’t fire, even after any consent action.</li>
</ol>
Tip: If you rely on specific Jetpack modules (e.g., backups, image CDN), leave those endpoints unblocked or disable only the stats/telemetry domains. “Permanent Block” is granular - use it to silence what’s unnecessary while keeping genuinely required functionality.
<h3>Before vs. After</h3>
<ul>
<li aria-level="1">Before: first pageview → background calls to stats.wp.com / pixel.wp.com transmit event data and identifiers.</li>
<li aria-level="1">After (Permanent): those endpoints never load; no stats/telemetry beacons leave the browser. Your core site, checkout, and login continue to work; your visitors aren’t exported by default.</li>
</ul>
This is data minimization in action: keep what’s essential, drop the rest.
<h3>Verify it with the AesirX Privacy Scanner (free)</h3>
Don’t guess - measure. Before and after you enable Permanent Block, run a quick scan to confirm exactly which third-party calls are leaving the browser.
<ol>
<li aria-level="1">Go to <a href="https://privacyscanner.aesirx.io">Privacy Scanner</a>.</li>
<li aria-level="1">Enter your URL and run a baseline scan (before changes).</li>
<li aria-level="1">In WP Admin → AesirX CMP → Consent Shield, set the Jetpack endpoints (e.g., stats.wp.com, pixel.wp.com) to Block permanently and Save.</li>
<li aria-level="1">Run a post-change scan and compare.</li>
</ol>
What to look for
<ul>
<li aria-level="1">Jetpack telemetry endpoints (e.g., stats.wp.com, pixel.wp.com) should no longer appear in the network findings.</li>
<li aria-level="1">No third-party trackers should fire before consent.</li>
<li aria-level="1">Cookie/Storage findings should show only what’s essential.</li>
</ul>
Tip: Export the scan report and attach it to your internal privacy records. It’s a simple, date-stamped proof of data minimization and enforcement.
</div>
<h2>What this means for your visitors (and for you)</h2>
<h4>For your visitors and customers</h4>
<ul>
<li aria-level="1">Fewer silent connections to companies they don’t know.</li>
<li aria-level="1">Less background profiling and cross-site stitching.</li>
<li aria-level="1">A clearer promise: we only run what helps you right now.</li>
</ul>
<h4>For your organization</h4>
<ul>
<li aria-level="1">Less vendor risk and fewer “unknown unknowns.”</li>
<li aria-level="1">A tighter, easier-to-explain privacy posture.</li>
<li aria-level="1">Cleaner audits: you can show not just what runs, but what doesn’t.</li>
</ul>
The hidden win is cultural. When a team chooses “Permanent Block” for non-essential exports, it nudges every future decision toward respect by default. It’s easier to ask “Is this necessary?” when your tooling makes “No” both possible and normal.
<h2>Turn it on (takes less than a minute)</h2>
<ol>
<li aria-level="1">WordPress Admin → AesirX CMP → <a href="https://aesirx.io/documentation/cmp/how-to/how-to-use-aesirx-consent-management-platform-main-features-guide#title-1" target="_blank" rel="noopener">Consent Shield</a>.</li>
<li aria-level="1">Add a Domain/Path rule (e.g., a telemetry or pixel endpoint).</li>
<li aria-level="1">Check the box “Permanent&nbsp;Block”.</li>
<li aria-level="1">Save. That target won’t run - before or after any consent choice.</li>
</ol>
Tip: Start with the obvious exporters. If you’re unsure whether an integration is essential, treat it like a guest in your users’ house - if it can’t clearly justify why it’s there, it doesn’t come in.
<h2>Why we built it this way</h2>
We could have made yet another toggle in a sea of toggles. Instead, we built a principled stop - a mode that can’t be overruled by a broad “Accept All.” That matters because many sites still initialize stacks too early or in too many places. A permanent rule is simple to reason about and easy to verify: if it’s on the list, it stays off.
And because “Permanent Block” sits in the same Privacy Shield you already use, you get granular control: per plugin, per domain, per path. You decide what’s essential. You decide what never runs.
<h2>A note on responsibility (and restraint)</h2>
“Permanent Block” is powerful. With a couple of clicks, you can silence whole categories of third-party collection. Use that power thoughtfully:
<ul>
<li aria-level="1">Keep what is technically required for security, core functionality, and user-requested features.</li>
<li aria-level="1">Remove what is comfortable but unnecessary - especially anything that ships people’s data off your site without a clear, immediate benefit to them.</li>
<li aria-level="1">Review periodically. As your stack evolves, so should your block list.</li>
</ul>
Respect is not just a feeling; it’s a set of decisions, repeated consistently, visible in the code your site actually runs.
<h2>The web we want</h2>
People shouldn’t have to trade their dignity for a pageview or a purchase. They shouldn’t have to navigate dark patterns to keep their information from becoming someone else’s product roadmap. They shouldn’t be followed simply because a developer forgot to uncheck a box.
“Permanent Block” is our contribution to a saner web: one where websites serve their visitors first, and where “no unnecessary third parties” is a default, not a dream.
If that’s the web you want too, update to AesirX CMP for WordPress v2.0.2, open Privacy Shield, and start marking the noisy stuff Permanent. Your visitors will feel the difference - even if they never know why. And that’s the point.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
<h2>FAQ</h2>
1. Will this break my checkout/login? No. “Permanent Block” is for non-essential third parties (telemetry, pixels, noncritical SDKs). Core, user-requested features (checkout, login, security, accessibility) should remain enabled. Best practice:
<ul>
<li aria-level="1">Test on a staging site first.</li>
<li aria-level="1">Block only the specific domains/paths you don’t need.</li>
<li aria-level="1">Run a quick flow check (login → cart → checkout) after changes.</li>
</ul>
2. What’s the difference vs “Block until consent”?
<ul>
<li aria-level="1">Block until consent: The script/endpoint is paused until the user opts in; if they consent, it can load.</li>
<li aria-level="1">Block permanently: The script/endpoint never loads - even if a user clicks “Accept All.” Use this for exporters that aren’t essential to the service the user asked for.</li>
</ul>
3. How do I review what to block? Use a simple three-step review loop:
<ol>
<li aria-level="1">Inventory: List active third-party scripts and endpoints (plugins, embeds, pixels).</li>
<li aria-level="1">Necessity test: If it doesn’t directly deliver what the user requested, mark it Permanent.</li>
<li aria-level="1">Verify: Scan before/after enabling “Permanent Block” with <a href="https://privacyscanner.aesirx.io" target="_blank" rel="noopener" style="background-color: inherit; font-family: inherit; font-size: 1rem;">AesirX Privacy Scanner</a>. Export reports for records.</li>
</ol>
Tip: Start with obvious exporters (e.g., stats/telemetry endpoints from bundled plugins). Keep technically required services and first-party functionality unblocked.
</div>

Respect Over Retargeting: How “Permanent Block” Ends Unnecessary Third-Party Collection

AesirX CMP v2.0.2 adds Permanent Block - stop non-essential third-party collection for good. Data minimization, respect by default, one-minute setup.

Permanent Data Block Stops Third-Party Tracking and Collection

1. Will this break my checkout/login?

2. What’s the difference vs “Block until consent”?

3. How do I review what to block?

Does this apply to sites outside the EU?

Block Until Consent? Good.
Block Forever? Sometimes Better.
Extensions shouldn’t phone home by default. v2.0.2 lets you say “no” - for good.
Most of us install plugins to solve problems. Fewer of us expect them to quietly call back to third-party servers - counting every page view, fingerprinting devices, or dropping pixels that don’t serve our users. That’s the “phone-home” problem.
The law is clear about the before part: no access to a user’s device without prior, informed consent (ePrivacy Directive 5(3)). But the spirit goes further: collect less. Favor the first-party path. Keep only what you need.
That’s why today we’re releasing Permanent Block. It’s a tiny control with a big message: if a third-party isn’t essential - and if sending data off-site isn’t in your users’ interests - you can stop it completely. Not “until consent.” Not “maybe later.” Completely.
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Missed our last update?
Read: <a href="https://aesirx.io/blog/press-release/aesirx-cmp-for-wordpress-v2-0-1-new-cryptox-wallet" target="_blank" rel="noopener">AesirX CMP for WordPress v2.0.1: New CryptoX Wallet on iOS and Android for Age and Country Verification</a>
</div>
<h2>What’s New in CMP v2.0.2?</h2>
<h3>Permanent Block in Privacy Shield</h3>
Until now, Consent Shield let you block third-party scripts “until consent.” That remains the default. But sometimes, “never” is the right answer. Permanent Block allows you to mark specific plugins, domains, or path rules so they will never load – even if a user clicks “Accept All.”
<h3>How it works:</h3>
<ul>
<li aria-level="1">In Consent Shield, select a plugin or add a domain/path rule.</li>
<li aria-level="1">Choose Block permanently.</li>
<li aria-level="1">Save your setting. From that moment, the target never loads.</li>
<li aria-level="1">Optional: Run a post-consent scan to confirm no data leaks remain.</li>
</ul>
It’s simpe, deliberate, and logged with clear UI badges, confirmation dialogs, and admin audit entries so policy changes are visible.
<h3>Why It Matters:</h3>
<ul>
<li aria-level="1">Data minimization by design If a third-party isn’t essential, you can keep your users’ data where it belongs: with you. This aligns directly with GDPR principles and ePrivacy Directive 5(3).</li>
<li aria-level="1">First-party strategy Rely less on external vendors, reduce cross-border transfer risks, and strengthen your data independence.</li>
<li aria-level="1">Real enforcement, not theatre Too many sites still initialize third-party stacks before consent. Permanent Block, combined with pre- and post-scans, prevents these silent leaks and keeps you audit-ready.</li>
</ul>
<h3>Use it For:</h3>
<ul>
<li aria-level="1">Telemetry scripts bundled into otherwise useful plugins.</li>
<li aria-level="1">Analytics beacons you’ve replaced with first-party analytics.</li>
<li aria-level="1">Embeds that set identifiers by default.</li>
</ul>
Pair it with our Privacy AI Advisor configuration with pre/post scanning and <a href="https://aesirx.io/solutions/analytics" target="_blank" rel="noopener">first-party Analytics</a> to run a site that respects people, reduces risk, and still learns what matters. That’s the web we’re building: privacy-first, first-party by default.
<h2>How to Get AesirX CMP for WordPress</h2>
<a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">Get AesirX CMP for WordPress</a> (14-day trial) and start marking the noisy stuff Permanent. Your users - and your future audits - will thank you.
➡ Download here: <a href="https://github.com/aesirxio/wordpress-consent-plugin/releases/tag/2.0.2" target="_blank" rel="noopener">AesirX CMP for WordPress – GitHub Releases</a>
Explore our ecosystem at: <a href="https://www.aesirx.io" target="_blank" rel="noopener">https://www.aesirx.io</a>

AesirX CMP for WordPress v2.0.2: Stop the Phone-Home. Permanently.

Blog Press Release Aesirx

Stop plugins from phoning home. AesirX CMP v2.0.2 for WordPress adds Permanent Block to keep data first-party, minimize risk, and enforce GDPR.

AesirX CMP for WordPress v2.0.2

If it’s not okay offline, it’s not okay online. Most sites track before consent, breaking trust. Learn why first-party control is the ethical default.

If It’s Not Okay Offline, It’s Not Okay Online

Scans show most sites track before consent, risking compliance and trust. See why true consent and first-party control are the only sustainable path.

If It’s Not Right Offline, It’s Not Right Online

<h2>Abstract</h2>
Zero-knowledge proofs (ZKPs) and consent are often portrayed as antagonists: one promises unlinkability, the other demands non-repudiation. In practice, they are complementary. Consent is about binding a decision to a specific event in a specific context, not about doxxing a person forever. ZKPs are about proving the right fact without exposing the rest. When we combine context-bound consent, local verification, and hash-only evidence, we get a system that is private by default yet accountable on demand - with precise auditability and no surveillance creep.
Author’s note: This article reflects work with AesirX and Concordium on privacy-preserving technologies (PETs) for practical regulatory compliance - from consent to ID verification. ‘Consent receipt’ maps conceptually to <a href="https://www.iso.org/standard/80392.html" target="_blank" rel="noopener">ISO/IEC 27560 (Consent Record)</a>: evidence that a data subject (via a holder key) agreed to a specific policy under a specific context and timestamp - without publishing identity attributes. Predicate proofs are commonly conveyed as W3C Verifiable Credentials or SD-JWT; the model is compatible with either while insisting on local verification and context binding. References to EUDI and mDL are illustrative; the design is wallet-agnostic and vendor-neutral.
TL;DR: Consent proofs should be event-scoped and verified locally. Keep only hash-anchored receipts; open one named event under due process - nothing ambient.
<h2>Consent Is an Event, Not an Identity</h2>
Most systems confuse the notion of consent with perpetual identification. A privacy-preserving stack treats consent as a decision attached to one concrete interaction, captured as: who controlled the key, what policy was accepted, where the interaction occurred, and when. The “who” is cryptographic control of a holder key. The “what/where/when” are folded into a context that names the relying party, the requested action, the policy in force, and a bounded time window.
This reframing matters. Once consent is event-scoped, the requirement becomes non-repudiation of that event, not lifelong tracking of that person. The subtlety is that non-repudiation attaches to the event and the key, while privacy applies to the person beyond the event.
<h2>Proving the Right Thing, Locally</h2>
ZKPs shine when the verifier only needs a predicate (e.g., “over 18,” “EU resident,” “same holder as before within this site”). Instead of calling an issuer on every request - or copying raw attributes - the verifier checks a proof locally. There is no routine “phone-home” to the issuer, which eliminates an otherwise constant, correlating exhaust trail.
Local verification moves consent from full disclosure to minimal proof. That is the essence of data minimization and makes the subsequent evidence we keep about consent much smaller and much safer.
<h2>Evidence Without Exposure: The Consent Receipt</h2>
Non-repudiation doesn’t require identity sprawl; it requires evidence tied to context. The right evidence is a consent (and/or verification) receipt that binds:
<ul>
<li aria-level="1">the holder’s key (not their PII),</li>
<li aria-level="1">the context (relying-party origin scope, action, bounded time window, and policy reference),</li>
<li aria-level="1">and a timestamp.</li>
</ul>
The receipt can live off-chain (signed and stored first-party) or be anchored by a hash-only receipt on a ledger. Either way, it proves that this key agreed to this policy under this context at this time - while revealing nothing else. Crucially, receipts are context-scoped, so they don’t create a global identifier or a reusable token.
This aligns with ISO/IEC 27560 Consent Record: evidence of agreement to a specific policy in a specific context, without identity attributes in the record.
“Receipts are context-scoped and hash-only: they prove that a consented, valid event occurred without publishing proofs or personal data.”
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/evidence-without-exposure-the-consent-receipt.png" alt="evidence without exposure the consent receipt" width="1999" height="857" />
Figure 1. AesirX Event-Scoped Consent Pattern (2025) Event-scoped consent with zero-knowledge - Event-scoped consent with zero-knowledge: verify locally, log a first-party receipt, anchor a hash-only, and - under due process - open a single named event via Native or Escrow. No issuer phone-home. No ambient tracing (© AesirX 2025 · aesirx.io).
<h2>Operational Unlinkability as a Control Surface</h2>
Unlinkability is not a declaration; it’s a discipline. The discipline here is to ensure that each interaction uses fresh, context-derived key material. A private, on-device base is established once; for each event, the device derives a contextual key that depends on:
<ul>
<li aria-level="1">the verifier’s normalized origin scope (so “who” you’re interacting with is unambiguous but not over-broad),</li>
<li aria-level="1">the action (what is being asked),</li>
<li aria-level="1">and the time window (when it’s valid).</li>
</ul>
Because the event key is unique to that origin/action/window, the verifier cannot use it to follow the holder elsewhere, and holders cannot be silently correlated across relying parties. At the same time, the verifier gets a stable, short-lived handle (per-event key) to complete the current task and record a verdict + timestamp - nothing more.
<h2>Hash-Only Anchors, Never Raw Data</h2>
Many systems put too much on a chain - attributes, identifiers, even entire proofs. That is unnecessary and risky. A privacy-preserving design writes only hash-level anchors for auditability:
<ul>
<li aria-level="1">a context anchor for the event (a commitment to origin/action/time window and policy),</li>
<li aria-level="1">and, optionally, a verification receipt that says “a valid check happened here,” again as a small, hash-only record.</li>
</ul>
These anchors give auditors and courts immutability and ordering without revealing personally identifying information or proofs. They also make it possible to prove existence (“this event happened”) and bind follow-up artifacts (like governed disclosures) to the exact event that was originally agreed.
<h2>Due-Process Accountability, Event by Event</h2>
The hard question is: what happens if the law later requires us to identify the actor for a specific incident? We answer by making accountability event-scoped and governed, never ambient.
<h4>There are two clean lanes:</h4>
<ul>
<li aria-level="1">Native lane (when the identity provider already has a lawful, auditable map from credential to subject): if a court names a specific event by its context anchor, the provider can open that event only, issue a signed decision receipt, and nothing else leaks.</li>
<li aria-level="1">Escrow lane (when the provider does not hold a native map): at verification time, a sealed, per-event escrow is created off-chain with just enough origin information to contact the authoritative issuer or reconstruct identity under warrant. The ledger records only a hash of that escrow, bound to the event’s context anchor. Later, a court-named event triggers a threshold, governed decryption of the matching escrow. The hash on the ledger prevents substitution; the quorum prevents unilateral disclosure.&nbsp;</li>
</ul>
Either lane yields targeted accountability without constructing a shadow identity graph. Routine operation remains silent and unlinkable; only the named event is opened, and only with a formally valid order.
For the Escrow lane, the sealed, per-event escrow contains only what is necessary to contact the authoritative issuer or to reconstruct identity for that event - nothing more - and is retention-bounded by default (e.g., 90 days) unless a legal hold applies. The ledger stores only a hash commitment to prevent substitution.
“Per-event escrow (when used) is minimal and retention-bounded; the ledger holds only a hash commitment that prevents substitution.”
<h2>Scenario - Age-gating a social feature</h2>
A social platform gates access to 18+ spaces. The page declares the policy; the user’s wallet proves ‘over 18’ locally. The site records a YES decision and anchors a hash-only receipt bound to the context (origin, action, window, policy). Months later, moderation investigates a specific post time: a court names that context anchor, and custodians open that event only under due process. Routine use remained unlinkable; the exception was governed and auditable.
<h2>Crossing Domains Without Crossing Privacy Boundaries</h2>
Digital life is multi-platform. Relying parties in other systems may want assurance that a particular context was satisfied - without importing identity data. The answer is a short-lived attestation that says “the predicate for this exact context anchor evaluated to yes,” signed by a key whose lifecycle and rotation are visible on a public registry.
Recipients verify the signature, the audience, the expiry, and the binding to the referenced context anchor or receipt. They never receive identity attributes, and they never gain a token that can be replayed across contexts. In short: outcome portability without data portability.
<h2>Governance: The Human Layer That Makes It Work</h2>
Cryptography enables, but governance legitimizes:
<ul>
<li aria-level="1">Context discipline prevents over-broad scopes and keeps receipts meaningful.</li>
<li aria-level="1">Issuer-silence during routine use removes a primary source of correlation.</li>
<li aria-level="1">Retention and rotation policies ensure that any per-event escrow, when used, remains minimal, time-bounded, and tamper-evident.</li>
<li aria-level="1">Decision receipts make due-process actions auditable, linking the human/legal decision to cryptographic evidence.</li>
</ul>
The model operationalizes necessity and proportionality: routine interactions disclose only the predicate needed to fulfill a purpose, while accountability is reserved for named events. Hash-only anchors provide auditability and ordering without exposing personal data or proofs.
This is where privacy engineering meets <a href="https://aesirx.io/solutions/consent-management-platform" target="_blank" rel="noopener">compliance</a>. The system is designed so that the legally right thing is also the path of least resistance operationally.
“When lawfully required, only the named event is opened under a governed (due-process) lane using a quorum of custodians; there is no ambient re-identification.”
<h2>Threats, Tamed by Design&nbsp;</h2>
<ul>
<li aria-level="1">Replay &amp; Look-alikes: Single-use, time-bounded contexts tied to a normalized origin scope prevent replays and phishing-by-confusion.</li>
<li aria-level="1">Silent Correlation: Local verification and context-derived event keys starve trackers; there’s no routine issuer callback and no long-lived handles.</li>
<li aria-level="1">Evidence Integrity: Hash-only anchors and signed receipts provide tamper-evident trails without exposing payloads.</li>
<li aria-level="1">Governed Disclosure: Event-scoped, threshold-controlled openings ensure that “exception handling” does not morph into surveillance.</li>
</ul>
<h2>What Good Consent Feels Like&nbsp;</h2>
A user visits a relying party that needs an age gate. The page states the policy clearly; the wallet proves the predicate privately on the device; the site logs “yes, at this time, under this policy” - and moves on. No new account, no dossier, no background radiation of issuer pings. Months later, an incident tied to a specific posting time is investigated: the court names the exact context anchor, and the governed lane reveals that event only. The routine remains private; the exception is accountable.
This is the equilibrium the field has sought for a decade: selective disclosure at the moment of use, contextual evidence for consent, and event-scoped accountability when the real world demands it.
<h2>Policy Alignment Without Gymnastics</h2>
By separating predicate proof from identity exposure, it operationalizes necessity and proportionality. By using context-bound, hash-only receipts, you create stronger evidence than the logs most systems keep today - while holding less personal data. And by structuring accountability as named-event disclosure under governance, you meet legitimate investigative needs without building a surveillance platform.
<h2>Conclusion</h2>
ZKPs and consent do not cancel each other out; they snap together. The key is to treat consent as event evidence bound to context and key control, and to treat ZK as a way to prove exactly what is necessary - nothing more. With local verification, contextual keys, and hash-only anchoring, privacy becomes the default state. With governed, event-scoped disclosure, accountability remains available when the law requires it. That balance - privacy by default, accountability on demand - isn’t a compromise. It’s how modern cryptography finally makes good on the original promise of the web.
Ronni K. Gothard Christiansen Technical Privacy Engineer &amp; CEO, <a href="https://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>

Discover how consent and zero-knowledge proofs work together to give users privacy, verifiable trust, and compliance without exposing identity.

The Correlation and Value of Consent and Zero-Knowledge Proofs

Explore how zero-knowledge proofs and consent combine to protect privacy, deliver verifiable receipts, and meet compliance with minimal data.

Consent & Zero-Knowledge Proofs: Key Insights

Agencies already using AesirX now have something they’ve never had before – a single page that shows every client, every license, and every commission.
The new <a href="https://aesirx.io/dashboard">Customer Overview</a> centralizes license control, client accounts, and product usage across the <a href="https://aesirx.io/partner/alliance-for-compliance-partner" target="_blank" rel="noopener">AesirX ecosystem</a>, designed specifically for agency and partner workflows.
By separating active licenses from pending requests, it provides both a compliance-ready record and a clear sales pipeline view, with built-in commission tracking to highlight the financial value of managing customers through AesirX.
Explore the Customer Overview in the portal and see how it transforms client management into a scalable, privacy-first workflow.
<h2>Navigation in the AesirX Customer Portal</h2>
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
How to Log In
1. Go to <a href="https://aesirx.io/dashboard" target="_blank" rel="noopener">https://aesirx.io/dashboard</a>.
2. Click Log In on the lefthand menu.
3. Select your login method: Email and Password, Social Media, or Web3 Wallets. and follow the prompts until you are logged in.
4. You’ll land on the Dashboard page where you can see a snapshot of your account.
</div>
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/navigation-in-the-aesirx-customer-portal.png" alt="navigation in the aesirx customer portal" width="942" height="550" />
The Customer Overview is part of a much larger system: the <a href="https://aesirx.io/dashboard" target="_blank" rel="noopener">AesirX Customer Portal</a>, designed as the central hub for agencies and partners. From here, every function that matters to client management, compliance, and community engagement is accessible in one environment – it’s the place where agencies control licenses, monitor privacy, and track their revenue streams.
At the heart of the portal is the left-hand navigation sidebar, which organizes the ecosystem into clear sections. Privacy Scanner includes tools like the Real-Time Scanner, Privacy Monitoring, and Bulk Scanner, giving users immediate access to compliance checks.&nbsp;
Community Programs such as Share2Earn, <a href="https://aesirx.io/affiliate2earn" target="_blank" rel="noopener">Affiliate2Earn</a>, and Contribute2Earn are also integrated, reflecting how AesirX connects you with customers and wider business opportunities.
Within the Service Management structure, the Customer Overview is the dedicated management page for agencies. While Licenses and Subscriptions are designed for individual users managing their own accounts, Customer Overview gives agencies a consolidated view across all of their clients. It’s where account control, license visibility, and commission tracking come together, allowing agencies to manage relationships and revenue in one place.
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Read More:
<a href="https://aesirx.io/blog/aesirx/cookiebot-alternative-for-wordpress-first-party-aesirx-cmp" target="_blank" rel="noopener">Why WordPress Sites Are Leaving Cookiebot In 2025 And Choosing AesirX CMP</a>
</div>
<h2>How to Issue New Licenses</h2>
Agencies can assign licenses directly to existing AesirX clients. Once payment is confirmed, the license is automatically linked to the user’s account, keeping records consistent for compliance, renewals, and commission tracking. This eliminates the need for manual updates or third-party systems and ensures every license is tied back to the right customer.
The process is handled through a simple modal with the following fields:&nbsp;
<ul>
<li aria-level="1">Username – enter the existing AesirX client’s username.</li>
<li aria-level="1">Solution – select which AesirX product (CMP, Analytics, First-Party Server, etc.).</li>
<li aria-level="1">Plan – choose the subscription tier (Starter, Team, Growth, Enterprise).</li>
<li aria-level="1">Billing Cycle – set monthly or annual billing.</li>
<li aria-level="1">Email – confirm the client’s registered email address.</li>
<li aria-level="1">Domain – add the primary domain linked to the license.</li>
<li aria-level="1">Issue New License – click the button to complete the process.</li>
</ul>
Once issued, the license becomes part of the agency’s centralized view in Customer Overview.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/license-added-to-agencys-customer-overview.png" alt="license added to agencys customer overview" width="942" height="550" />
<h2>How to Create New Customers</h2>
For new business, agencies can onboard clients by creating an account and issuing a license in one step. This feature is particularly useful for agencies expanding their portfolio or working with clients who don’t yet have an AesirX profile.
The modal mirrors the license process, with the following fields:
<ul>
<li aria-level="1">Username – create a new client account by entering their username.</li>
<li aria-level="1">Solution – select the product they need.</li>
<li aria-level="1">Plan – assign the correct subscription tier.</li>
<li aria-level="1">Billing Cycle – choose monthly or annual billing.</li>
<li aria-level="1">Email – enter the client’s contact email.</li>
<li aria-level="1">Domain – add the domain the license will be tied to.</li>
<li aria-level="1">Create New Customer – click the button to complete the process.</li>
</ul>
By combining account creation with license assignment, onboarding becomes faster and more accurate, removing bottlenecks that often slow down client activation.
Together, these features turn Customer Overview into a full management hub—not only showing agencies what they have today, but giving them the tools to grow their client base directly within the AesirX ecosystem.
<h2>The Overview Tab: Active Clients and Licenses</h2>
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/the-overview-tab-active-clients-and-licenses.png" alt="the overview tab active clients and licenses" width="942" height="350" />
The Overview Tab is where agencies see every active customer and the licenses tied to them. It is designed to provide transparency, making it easy to monitor usage, renewals, and revenue in one place.
The table lists:
<ul>
<li aria-level="1">User ID – the unique identifier for each client.</li>
<li aria-level="1">Domain – the primary domain linked to the license.</li>
<li aria-level="1">Remaining Domain(s) – any unused domains still available under the license.</li>
<li aria-level="1">Solution – the AesirX product in use (CMP, Analytics, First-Party Server, etc.).</li>
<li aria-level="1">License – the key associated with the product.</li>
<li aria-level="1">Plan – the subscription tier the client is on.</li>
<li aria-level="1">Days Left – the remaining time on the license, including expired entries.</li>
<li aria-level="1">Commission – agency earnings tied to that license, shown in USD.</li>
</ul>
This structure gives agencies a real-time compliance record while also tracking revenue. By seeing license usage and expiry dates alongside commissions, agencies can forecast renewals, spot inactive accounts, and prioritize where to focus attention.
<h2>The Requested Licenses Tab: Pipeline and Pending Revenue</h2>
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/the-requested-licenses-tab-pipeline-and-pending-revenue.png" alt="the requested licenses tab pipeline and pending revenue" width="942" height="550" />
The Requested Licenses tab captures every license request that is awaiting payment. Once payment is received, the request automatically moves into the Overview tab, keeping live accounts and pending deals clearly separated.
The table lists:
<ul>
<li aria-level="1">User ID – the client making the request.</li>
<li aria-level="1">Domain – the primary domain for the license.</li>
<li aria-level="1">Solution – the AesirX product requested.</li>
<li aria-level="1">Billed Cycle – how the plan is billed (monthly, annually, etc.).</li>
<li aria-level="1">Plan – the subscription tier.</li>
<li aria-level="1">Commission – the agency’s expected earnings in USD.</li>
<li aria-level="1">Status – the current stage of the request (awaiting, accepted).</li>
<li aria-level="1">Action – quick access to edit license details when needed.</li>
</ul>
This tab gives agencies a structured sales pipeline view, showing which clients are close to activation, what revenue is coming, and where intervention may be needed if a request stalls. It reduces confusion between unpaid and active clients, ensuring agencies keep visibility of both current and future business.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/agency-benefits.png" alt="agency benefits" width="942" height="550" />
<ul>
<li aria-level="1">Centralized control – manage all clients and products from one screen.</li>
<li aria-level="1">Flexible filtering – zero in on the accounts or solutions you need.</li>
<li aria-level="1">Scalability – add customers, issue licenses, and manage growth at scale.</li>
<li aria-level="1">Transparency – see license usage, expiration dates, and commissions in real time.</li>
<li aria-level="1">Faster onboarding – activate clients without delays or manual tracking.</li>
<li aria-level="1">Revenue tracking – clear view of agency commissions built into the dashboard.</li>
<li aria-level="1">Compliance readiness – link to Privacy Scanner tools for an integrated workflow.</li>
</ul>
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Grow Your Business with Privacy-First Solutions
Add a recurring revenue stream to your agency by offering high-demand, privacy-first solutions
<ul>
<li aria-level="1">Earn 30% commission on sales of product licenses.</li>
<li aria-level="1">Receive priority access to support and resources.</li>
</ul>
<a href="https://aesirx.io/partner" target="_blank" rel="noreferrer noopener" class="fw-semibold py-13px px-4 lh-sm text-white btn btn-success" tabindex="0" role="button">Become a Partner</a></div>

AesirX Customer Overview: The Agency Dashboard for Privacy-First Client Management

How to Customer-Portal

Learn how to issue licenses, onboard new clients, and track revenue with AesirX Customer Overview, the agency hub for privacy-first management.

AesirX Customer Overview: The Agency Dashboard

Vietnam’s draft PDPL Decree brings stricter consent, tracking, and cross-border data rules from 2026. Learn key changes vs GDPR/ ePrivacy in plain terms.

Vietnam’s PDPL - Key Changes in the Draft Implementing Decree

Vietnam’s PDPL - Key Changes in the Draft Implementing Decree (Consultation, Sept 2025)

 Vietnam’s draft PDPL Decree (2026) changes how websites, apps, and vendors handle consent, sensitive data, and cross-border transfers vs GDPR rules.

<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
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.
</div>
On 16 September 2025, the Commission launched a <a href="https://digital-strategy.ec.europa.eu/en/news/commission-collects-feedback-simplify-rules-data-cybersecurity-and-artificial-intelligence-upcoming" target="_blank" rel="noopener">call for evidence</a> 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.
<h2>The rule that works where GDPR can’t</h2>
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.&nbsp;
In modern stacks, tag managers and telemetry frameworks still bootstrap early, then ask for consent later.&nbsp; 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.”
<div class="px-md-40px py-20px border rounded-4 shadow mb-5">
Read more:
<a href="https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en" target="_blank" rel="noopener">EDPB Guidelines 2/2023 on ePrivacy Directive 5(3)</a>
</div>
<h2>The map of Europe: alignment is not the problem</h2>
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 &amp; enforcers (EU-27 + UK + NO), status as of 16 Sep 2025.
<img src="https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/https/api.aesirx.io/images/The_map_of_Europe_alignment_is_not_the_problem.png" alt="The map of Europe alignment is not the problem" width="1969" height="1230" />
<h2>The gap is enforcement, not law</h2>
Alignment on paper hasn’t translated to behavior online. Europe’s legal baseline is remarkably aligned; behavior is not. Our July scan of <a href="https://www.linkedin.com/pulse/what-36000-danish-business-websites-just-revealed-why-christiansen-e1bec/" target="_blank" rel="noopener">36,500 Danish sites</a> 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: <a href="https://www.linkedin.com/pulse/public-sector-privacy-hypocrisy-sovereignty-vs-christiansen-biecc/" target="_blank" rel="noopener">82% in Denmark and 91% in Sweden fired beacons pre-consent</a>. 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: <a href="https://aesirx.io/services/privacy-scanner" target="_blank" rel="noopener">AesirX Privacy Scanner</a> (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.”
<h2>The wrong fix: centralized consent hubs</h2>
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.&nbsp;
Why “Central cookie management” can easily become surveillance by design:
<ul>
<li aria-level="1">Phone-home consent pings reveal when and where a person visits.</li>
<li aria-level="1">Cross-site linkability grows as one operator handles consent for millions of properties.</li>
</ul>
We must not fix banner fatigue by centralizing the consent layer.
<h2>The right fix: decentralized, first-party consent</h2>
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
<ul>
<li aria-level="1">Evaluate and store consent on the site’s own origin.</li>
<li aria-level="1">No third-party calls before consent. No GTM bootstrap. No remote CMP telemetry.</li>
</ul>
User-controlled automation
<ul>
<li aria-level="1">Respect GPC and similar signals as a valid default refusal unless the user actively overrides.</li>
<li aria-level="1">Let people pre-set granular preferences using a digital wallet (by purpose/vendor/category). On opt-in, sign a local proof-of-consent.</li>
</ul>
Zero-knowledge compliance
<ul>
<li aria-level="1">Prove “user consented to Purpose X at Time T” without revealing identity, browsing history, or wallet metadata.</li>
<li aria-level="1">Keep flows issuer-silent so no external party learns where a proof is presented.</li>
</ul>
Audit without tracking
<ul>
<li aria-level="1">Issue unlinkable consent receipts bound to domain, purpose, and a time window.</li>
<li aria-level="1">Support revocation and expiry locally; allow verifiers to check validity without global IDs.</li>
</ul>
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.
<h2>What the Digital Omnibus should adopt for cookies</h2>
<ul>
<li aria-level="1">No device access before consent - full stop Tag managers and telemetry frameworks count as device access. Default to defer by design.</li>
<li aria-level="1">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.</li>
<li aria-level="1">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.</li>
<li aria-level="1">Embrace privacy-enhancing tech Accept zero-knowledge proof-of-consent and issuer-silent flows as compliant evidence. Publish a reference profile for unlinkable receipts.</li>
<li aria-level="1">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.</li>
<li aria-level="1">Lead by example Mandate strict compliance for public-sector websites first, then cascade to critical private services.</li>
</ul>
<h2>Early learnings and what we’re measuring</h2>
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.
<ul>
<li aria-level="1">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.</li>
<li aria-level="1">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.”</li>
<li aria-level="1">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.</li>
<li aria-level="1">Operational gains: Deferring third-party bootstraps improves initial render performance; keeping proofs/receipts local streamlines audits and shortens incident investigations - without creating centralized telemetry.</li>
</ul>
This is work in progress and will be documented openly; proposals here are intended to guide the Omnibus, not to pre-judge its outcome.
<h2>Turning Rules into Results</h2>
<ul>
<li aria-level="1">Policymakers and regulators: lock in first-party, decentralized consent; ban centralized consent telemetry; publish a common testing and enforcement playbook.</li>
<li aria-level="1">Industry: stop loading anything pre-consent. Move consent, analytics, and tags first-party. Respect GPC.</li>
<li aria-level="1">Wallets and civic-tech: ship user-friendly pre-sets and ZK consent proofs normal people can actually use.</li>
<li aria-level="1">Readers: check the attached matrix to see who enforces 5(3) in your market - then check your own site’s first paint.</li>
</ul>
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 &amp; CEO, <a href="http://aesirx.io" target="_blank" rel="noopener">AesirX.io</a>
<h2>Answering the Commission’s guiding questions</h2>
The Commission has published a <a href="https://www.linkedin.com/posts/luisalbertomontezuma_cookies-activity-7373879796461723649-pD2I" target="_blank" rel="noopener">one-page set of guiding questions</a> 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.
<h3>1. How do you currently comply with Article 5(3) and GDPR, and where are the challenges?&nbsp;</h3>
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.
<h3>2. What proportion of websites use cookies for advertising? Which could be acceptable without consent (e.g., statistics)?</h3>
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.
<h3>3. What’s the right balance between transparency/choice and avoiding consent fatigue?</h3>
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.
<h3>4. Are there use cases where only non-personal data is processed?</h3>
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.
<h3>5. When is a legal person a “user,” and how is consent given?</h3>
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.
<h3>6. Could simplifying consent encourage privacy-enhancing tech?</h3>
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.
<h3>7. Non-personal on-device use cases (compute, agents, transfers)?</h3>
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.

The EU’s Digital Omnibus should uphold Article 5(3): stop pre-consent tracking, block central consent hubs, and enforce rules consistently.

Simplify Without Surveillance: What the EU Must Do About Cookies

Simplify Without Surveillance: What the EU’s Digital Omnibus Must Do About “Cookies”

The EU’s Digital Omnibus must keep Article 5(3) strong: no tracking before consent, ban central consent telemetry, and set clear enforcement tests.

Press and Blogs

POPULAR TOPICS

Top 5 Reasons Your Cookie Consent Solution Isn’t Compliant

Ignorance or Arrogance? Why Hide Consent Outside Europe

Respect Over Retargeting: How “Permanent Block” Ends Unnecessary Third-Party Collection

AesirX CMP for WordPress v2.0.2: Stop the Phone-Home. Permanently.

If It’s Not Okay Offline, It’s Not Okay Online

The Correlation and Value of Consent and Zero-Knowledge Proofs

AesirX Customer Overview: The Agency Dashboard for Privacy-First Client Management

Vietnam’s PDPL - Key Changes in the Draft Implementing Decree (Consultation, Sept 2025)

Simplify Without Surveillance: What the EU’s Digital Omnibus Must Do About “Cookies”

Join the AesirX Partner Program

Solutions

Resources

Support

Partnership Opportunities