When Does Consent Expire?

Once a visitor has consented on your website, MineOS CMP remembers their choice and doesn't show the banner again — until something changes. This article lists every condition that causes a stored consent to be considered expired or invalid, prompting the banner to reappear and a new consent to be captured.

📘

Why this matters

Each expiration trigger generates a fresh consent — with a new Consent ID — in your audit log. If you're investigating why a visitor saw the banner unexpectedly, or why your audit log contains more events than you anticipated, this is the list to check.

Expiration triggers

1. The consent duration has elapsed

Each banner has a configurable consent duration (set under Consent Options → Consent expiration, typically 12 months). When this period passes, the stored consent expires automatically and the banner reappears on the visitor's next page load.

This is the most common trigger and the one regulators expect — most privacy frameworks recommend re-consent at least once every 12–24 months.

2. A new provider has been added

When a new provider has been added, the configuration version increments. The next time a visitor lands on your site, MineOS compares their stored consent's configuration version to the live one. A major version mismatch invalidates the stored consent and triggers re-consent.

This can happen in two cases:

• New providers detected by a scan and added to your configuration. Version is updated automatically with no need to publish.
• New providers added manually and you published the new configuration.

3. A different banner now applies to the visitor

Consent is stored per banner, not per visitor. If your rules cause a different banner to be shown to a visitor than the one they previously consented to, the previous consent doesn't apply — the new banner appears and a new consent is captured.

Common causes:

• The visitor traveled to a different region (e.g. consented in the EU on the GDPR banner, then visited from the US where the CCPA opt-out banner applies)
• You modified your rules so a different banner now matches their location or the page they're on
• The visitor is hitting a different URL that falls under a different rule (e.g. an EU banner site-wide but a stricter banner on /checkout)

When the visitor goes back to a region/URL where their original banner applies, their original consent for that banner is still valid (assuming it hasn't expired for other reasons).

4. The visitor cleared their browser storage

Consent is stored in the visitor's browser localStorage. Anything that removes that storage will cause the banner to reappear on the next visit:

• The visitor explicitly cleared cookies/site data in their browser settings
• The visitor uses a privacy-cleaning extension that wipes site storage
• The visitor's browser auto-evicted the storage (modern browsers like Safari, with ITP, may evict site storage from sites the visitor hasn't returned to in ~7 days)
• The visitor is using a new browser, device, or profile

5. The visitor is in private/incognito mode

In private browsing modes, storage is scoped to the browsing session. As soon as the visitor closes the private window, the consent record is gone. On their next private session, the banner reappears.

If localStorage is blocked entirely (rare — happens in some heavily-restricted browser configurations), MineOS falls back to sessionStorage, then to in-memory storage. In-memory storage means consent persists only for the current page load — the banner will reappear on every navigation.

6. The stored consent record is incomplete or malformed

If something corrupts the stored consent record — for example, the expiry timestamp is missing, or the JSON is malformed — MineOS treats the consent as invalid and shows the banner.

In practice this is rare and usually only happens when developers or extensions manually manipulate the storage entry.

What happens when consent expires

When MineOS detects an expired or invalid consent on page load:

1. Rules are evaluated again and a banner reappears if needed, with the visitor's previous choices not pre-selected (the stored consent is treated as gone).
2. When the visitor consents, a fresh consent record is written — with a new Consent ID — and a new event is added to your consent audit log.

Frequently asked questions

Does changing my banner's branding (colors, fonts) invalidate consent? No — This is considered a minor change which does not invalidate consent.

If I only update text on a banner, do all my visitors lose their consent? No — This is considered a minor change which does not invalidate consent.

A visitor reports the banner keeps reappearing every page load. What's wrong? The most likely cause is that localStorage isn't persisting on their browser — for example, an aggressive privacy extension is wiping it, or the browser is in a mode that doesn't persist storage. Have them check their browser's privacy settings and try in a regular (non-incognito) window.

Does the consent expire if the visitor doesn't visit for a long time? The stored consent itself doesn't expire from disuse — it expires when the expiry timestamp is reached (set when consent was given, based on your banner's consent duration). However, some browsers (notably Safari with ITP) will evict storage from sites the visitor hasn't returned to recently, which has the same effect.

Can I extend or shorten the consent duration? Yes — open the banner in the portal, go to the Consent options tab, and change the Consent expiration value (in months). The new value applies to consents captured after you publish — it doesn't extend consents that were already stored.