What to do when a third-party SDK ignores your consent state
Some SDKs initialize on load and track regardless of what your banner says. When the SDK has no consent-aware mode, contain it yourself: lazy initialization behind a consent gate, a wrapper that holds calls until consent is granted, and network-level blocking as the last line of defense.
Confirm it is actually the SDK
Before reworking code, verify with a declined-consent test: open a private window, reject everything, and watch the network tab for the vendor's domains. If requests fire anyway, the SDK is initializing itself on load rather than respecting your consent state. Document which version behaves this way, because the next SDK update can change it silently. This test takes five minutes and separates an actual SDK problem from a misconfigured gate.
Lazy initialization behind the consent gate
The cleanest fix is to never load the SDK until consent is granted. Hold the script tag out of the initial page load and inject it only when the consent state includes the relevant category. If the visitor has already consented on a previous visit, your consent platform should expose that state early enough to initialize without a flash of the banner. When consent is withdrawn, you should also stop making calls, and ideally unload what you can, though most SDKs make teardown impossible, which is why gating the load matters more than gating the calls.
Wrap it when you cannot gate the load
Some SDKs must initialize early for the app to function, like crash reporting or feature flags with analytics attached. In that case, wrap the SDK: initialize it in its most limited mode, queue every analytics call you would have made, and flush the queue only when consent arrives. If consent never arrives, drop the queue. The wrapper pattern keeps application code unchanged while giving consent one choke point to control. It also gives you a single place to test, which matters when the SDK updates.
Block at the network level as a backstop
When the SDK offers no limited mode and no API for consent, treat its traffic like any other blocked tag. A consent-aware tag manager or a service worker can hold the SDK's requests until consent is granted. This is blunt, and it can break SDK functionality that depends on those calls, so test the refusal path thoroughly: some SDKs throw errors that surface in the console or, worse, in the user interface. But a broken analytics dashboard is cheaper than a consent violation the banner cannot prevent.
Escalate with evidence
File the issue with the vendor and include the network log. Vendors add consent modes when customers ask with evidence, and a report that says "your SDK fires 14 requests after the visitor declined" is hard to ignore. In the meantime, your containment keeps you compliant. Document the workaround and the vendor ticket together, so the next engineer knows the wrapper exists for a reason and the test suite keeps covering it.