Reject all should stay rejected: the vendor resync problem

Published 2026-10-07

A visitor clicks reject all on your banner. Every tracker should go quiet. Then, quietly, some of them come back. Not because the visitor changed their mind, but because your consent tool resynced its vendor list, reloaded its defaults, or re-ran a scan that re-enabled categories the visitor had already refused. The banner still shows the rejection. The network traffic tells a different story.

This is the vendor resync problem: consent state that drifts back toward permissive every time the vendor ecosystem updates. It is one of the most common consent failures we find in audits, and it is invisible to anyone who only looks at the banner instead of the network requests.

How a rejection gets quietly undone

Modern consent tools do not work from a static list of trackers. They pull vendor lists, purpose definitions, and default states from a cloud service that updates regularly. When that update lands, the tool reconciles the new list against the visitor's stored choice. Reconciliation is where rejections die.

The failure modes are variations on one theme. The updated vendor list contains new vendors with no stored choice, and the tool defaults them to on. A purpose gets renamed or split in two, and the mapping drops the old denial. The tool refreshes its configuration and briefly falls back to defaults before reapplying the stored consent. Each of these lasts seconds or persists silently, and each one re-enables tracking the visitor refused.

Why this matters more than it looks

A reject-all that does not hold is worse than no banner at all from an evidence standpoint. It creates a paper trail showing the visitor refused, sitting next to network logs showing tracking continued anyway. Regulators read that combination as a broken promise, not a technical glitch. Fines for dark patterns and deceptive consent interfaces have targeted exactly this gap between what the interface claims and what the page does.

There is also a compounding effect. Every resync that re-enables vendors adds trackers that then set their own cookies and fire their own pixels. Those downstream trackers do not check your consent state at all. One sloppy resync can seed a dozen trackers that keep running long after your tool reapplies the rejection.

The audit that catches it

Run the reject-all test, but run it with a clock. Reject everything, then leave the tab open for ten minutes while watching the network tab. Many resync problems show up as a second wave of tracker requests minutes after the initial page load, when the vendor list refresh fires. A one-shot check right after the banner click misses it entirely.

Then test the reload path. Reject all, reload the page, and confirm the rejection held. Clear the consent cookie manually and watch what the tool does on a fresh visit with no stored choice: does it default to blocked, or does it briefly enable vendors while it fetches its configuration? That loading window is a classic resync hole.

Finally, check after a vendor list update. Most consent tools let you see the list version. Trigger an update, then re-run the reject-all test. If rejections break after updates, you have a reconciliation bug, and it will recur on every future update until the mapping is fixed.

What a correct reconciliation looks like

The rule is simple: a stored denial survives every list change. When a new vendor appears, the correct default is the visitor's existing posture, not the tool's factory default. When a purpose splits, the denial should carry to both children. When configuration reloads, blocking stays on during the load, not after.

This is a configuration question for your consent vendor, not something you code around. Ask them directly: how does your platform reconcile stored denials against vendor list updates? If the answer is vague, assume the worst and test it. Some vendors handle this correctly. Many do not, and their documentation is silent on the point.

The bottom line

Reject all is a promise that has to survive updates, reloads, and list changes. If your consent setup only honors rejections in the calm moment right after the banner click, it is not honoring them. Test the resync path, demand denial-safe reconciliation from your vendor, and watch the network tab on a timer, not just on click. The rejection that stays rejected is the only one that counts.

Common questions

How often do vendor list updates cause resync problems?

It depends on the vendor, but updates are frequent, often weekly, and each one is a reconciliation event. If your platform handles reconciliation badly, the problem recurs on every update cycle, not just once.

Does this affect accept-all choices too?

Yes, in the other direction: updates can drop stored acceptances, causing banners to reappear for returning visitors. That is annoying but not a compliance risk. The risk is asymmetric, and it points at denials.

Can I fix this without changing consent vendors?

Sometimes. Some platforms expose reconciliation settings or webhooks you can configure. But if the platform's default behavior re-enables vendors on update and offers no control, that is a product decision, and switching is the fix.

Frequently asked questions