Category: CMP Implementation
Consent SDK
Also known as: consent management SDK, in-app consent SDK, mobile consent SDK
Simply put
A Consent SDK is a bundle of code that developers embed within a mobile app or software to collect, apply, and pass along a user's choices about tracking and data use. It lets other parts of the app, and third-party components, know whether the user has agreed to specific data processing before that processing takes place. It is a technical building block that supports compliance efforts but does not, by itself, guarantee that an app meets any particular legal requirement.
Formal definition
A Consent SDK (software development kit) is a set of libraries and APIs embedded within an application to provide consent-management functionality, typically exposing methods to capture, store, retrieve, and apply a user's consent status and to gate the behaviour of other SDKs or code that access or process user and device data. In practice, such SDKs are designed so that components accessing or processing user or device information do so only after the relevant consent signal has been set; for example, some implementations do not store or transmit collected data until consent has been granted, and others provide an API to set the user's consent status. Consent SDKs are relevant to both the ePrivacy Directive and the GDPR in the EU: the storing of or gaining access to information on a user's device (including via app storage, identifiers, and similar technologies) generally requires prior consent under Article 5(3) of the ePrivacy Directive as implemented across Member States (subject to strictly-necessary exemptions), while any subsequent processing of personal data still requires a separate lawful basis under the GDPR even where the device-storage step is exempt. Some Consent SDKs interoperate with wider frameworks or vendor consent modes (for example Google consent mode functionality for AdMob and Ad Manager, or CMP in-app SDKs), but the scope, signals supported, and framework alignment vary by vendor. This definition does not cover the specific configuration, record-keeping, or transparency obligations that determine whether any given deployment satisfies applicable law, and requirements differ across jurisdictions such as the EU, the UK, and individual US states.
Why it matters
Mobile apps rarely process user data through a single, self-contained codebase. They typically embed numerous third-party SDKs for analytics, advertising, attribution, and other functions, and each of those components may access device identifiers or store and transmit user data. A Consent SDK provides a central mechanism to capture a user's choices and signal them to those other components, so that data processing is gated on the user's consent status rather than happening indiscriminately when the app launches. Without such a mechanism, an app risks allowing embedded SDKs to store information on or access information from a device, and to process personal data, before any valid consent has been obtained.
Who it's relevant to
Mobile and software developers
Developers embed Consent SDKs to gate the behaviour of other embedded components, ensuring that SDKs accessing or processing user or device data do so only after a consent signal has been set. Correct integration, wiring the consent status through to every component that relies on it, is a technical prerequisite for the SDK to function as intended, though it does not by itself resolve the underlying legal obligations.
Privacy officers and data protection professionals
These readers rely on Consent SDKs as one building block within a broader compliance programme. They need to understand that such a tool supports, but does not guarantee, compliance: in the EU, prior consent is generally required to store or access information on a device under the ePrivacy Directive, and any subsequent personal-data processing still needs its own lawful basis under the GDPR. Configuration, transparency, and record-keeping remain their responsibility.
Legal and compliance counsel
Counsel assessing an app's compliance posture should treat the presence of a Consent SDK as a technical capability rather than proof of lawful practice. They need to evaluate how consent is obtained, whether it meets applicable standards, and whether obligations differ across the EU, the UK, and individual US states, since the SDK's mere deployment does not settle those questions.
Marketing and advertising teams
Teams deploying advertising, attribution, or analytics SDKs are directly affected because a Consent SDK can determine whether those components run and what data they may process. Understanding how consent signals feed into vendor consent modes, such as Google consent mode for AdMob and Ad Manager, helps these teams avoid triggering data collection before valid consent exists.
Inside Consent SDK
Consent SDK (software development kit)
A set of libraries, APIs, and components that developers integrate into mobile apps or other software to collect, store, and communicate a user's consent choices to tracking technologies, advertising SDKs, and analytics tools. Unlike browser-based cookie banners, a consent SDK typically operates within native app environments where cookies are less relevant and technologies such as device identifiers, local storage, and other SDKs are the primary means of accessing or storing information on a device.
Consent capture and user interface
The layer responsible for presenting consent notices and choices to the user and recording an affirmative action. In most EU jurisdictions, where the ePrivacy Directive as implemented requires prior consent (opt-in) for non-essential storage or access on a device, this interface must enable a clear affirmative choice rather than relying on pre-selected options or implied consent.
Consent signal propagation
The mechanism by which the SDK passes a user's consent state to downstream SDKs, tags, and third-party services so that non-essential processing is only triggered where consent exists. This may include integration with industry frameworks such as the IAB Transparency and Consent Framework (TCF), which supports standardized signaling but does not by itself guarantee legal compliance.
Consent storage and record-keeping
Functionality that persists the user's choices on the device or a backend, and that may support the record-keeping practitioners often rely on to demonstrate consent. The precise records needed to demonstrate valid consent depend on applicable law and regulatory expectations, which vary by jurisdiction.
Categorization of technologies
Configuration that classifies the technologies an app uses (for example strictly necessary or essential functions versus analytics, advertising, and functional purposes). Strictly necessary functions are generally exempt from consent under EU rules, while analytics and advertising SDKs typically require prior consent. Pixels, local storage, device identifiers, and fingerprinting generally fall within the same rules as cookies even though they are not literally cookies.
Opt-out and preference signals
Support for opt-out mechanisms and signals such as Global Privacy Control, which are more relevant under certain US state privacy frameworks (for example the CCPA and CPRA in California) that often rely on an opt-out rather than opt-in model. These differ in structure from the prior-consent requirement that applies in the EU.
Common questions
Answers to the questions practitioners most commonly ask about Consent SDK.
Does a consent SDK let me use an opt-out model for non-essential cookies in the EU if the user is in a Member State that allows it?
No. This is a common misconception. Under Article 5(3) of the ePrivacy Directive, as implemented across EU Member States, prior consent (opt-in) is generally required before placing or accessing non-essential storage on a user's device, subject only to the strictly-necessary and communication-transmission exemptions. No Member State permits a general opt-out approach for non-essential cookies, pixels, SDKs, or similar technologies. A consent SDK can be configured to collect prior opt-in consent, but the underlying legal standard does not vary between Member States in the way an opt-out model would require. Opt-out models are more commonly associated with certain US state privacy frameworks, not the EU.
If my consent SDK is configured so that a technology is exempt from consent, does that mean I have no further compliance obligations for that technology?
Not necessarily. This is a frequently misunderstood point. Even where storage on or access to the device is exempt from consent under Article 5(3) of the ePrivacy Directive (for example, for strictly-necessary purposes), any subsequent processing of personal data must still have a valid lawful basis under the GDPR, such as legitimate interest, and must meet the GDPR's other requirements including transparency and data subject rights. A consent SDK managing the device-access layer does not, by itself, resolve the separate GDPR question of how the resulting personal data is processed. These are two distinct legal regimes, and satisfying one does not automatically satisfy the other.
How should a consent SDK handle blocking of tags and scripts before consent is given?
In most EU jurisdictions, non-essential cookies, pixels, SDKs, and similar technologies should not be placed or executed until valid prior consent has been obtained. A consent SDK is typically configured to block or defer the loading of such tags and scripts until the user provides a clear affirmative action, and to release them only for the specific purposes consented to. Implementation details vary by platform, and blocking should be verified in practice, since server-side or third-party scripts may fire outside the SDK's control. The SDK supports this control but does not by itself guarantee compliance; testing and legal review remain necessary.
What consent records should a consent SDK capture and retain?
To support record-keeping expectations, a consent SDK is commonly configured to log details such as what the user was shown, the choices made per purpose or category, the timestamp, and the version of the notice or configuration in effect. The aim is to be able to demonstrate that consent was freely given, specific, informed, and unambiguous where the GDPR applies. The exact records that are appropriate depend on the applicable regime and your accountability obligations, and retention periods should be determined with reference to data minimisation principles. What constitutes sufficient evidence can be a contested and fact-specific question.
How does a consent SDK integrate with frameworks like the IAB TCF or signals like Global Privacy Control?
Many consent SDKs offer optional integration with the IAB Transparency and Consent Framework, generating and passing standardized consent signals to downstream vendors, and some can detect and respond to Global Privacy Control or similar browser-based opt-out signals. Whether and how these should be enabled depends on your jurisdiction and use case; for example, opt-out signal handling is particularly relevant to certain US state frameworks, while TCF is used in some advertising ecosystems. Enabling a framework does not in itself establish compliance, and adopting a particular framework may carry its own contested interpretations and obligations that should be assessed separately.
How should a consent SDK handle consent across different jurisdictions and regions?
Because obligations differ between the EU, the UK, individual US states such as California, and other regimes, a consent SDK is often configured with geographic detection to present the appropriate experience, such as opt-in flows where prior consent is generally required and opt-out mechanisms where those apply. Geolocation is imperfect and should be tested, and the mapping of regions to configurations reflects legal decisions that sit outside the tool itself. The SDK can operationalize a jurisdictional strategy, but determining the correct rules for each region and each technology involves legal judgment that the tool cannot replace.
Common misconceptions
Integrating a consent SDK makes an app compliant with cookie and tracking laws.
A consent SDK is a technical and organizational tool that supports compliance but does not replace legal judgment or guarantee compliance. Whether an implementation is lawful depends on how it is configured, the technologies it governs, the applicable legal regime, and evolving guidance from data protection authorities. Tools do not by themselves ensure that consent is freely given, specific, informed, and unambiguous where that standard applies.
In the EU, an app can rely on an opt-out model for non-essential SDKs as long as users can later withdraw consent.
Under Article 5(3) of the ePrivacy Directive, as implemented across EU Member States, prior consent (opt-in) is generally required before non-essential information is stored on or accessed from a user's device, subject only to the strictly-necessary exemptions. No EU Member State permits a general opt-out model for non-essential storage or access. Opt-out approaches are more associated with certain US state privacy laws, not the EU.
If storing something on the device is exempt from consent, no further compliance steps are needed.
Even where storage on or access to the device is exempt from consent under Article 5(3) of the ePrivacy Directive, any subsequent processing of personal data still requires a separate lawful basis under the GDPR (for example legitimate interest, subject to a balancing assessment). The device-access rules and the data-processing rules are distinct regimes, and satisfying one does not automatically satisfy the other.
Best practices
Map every technology the app uses (SDKs, device identifiers, local storage, pixels, fingerprinting) and categorize each by purpose, since analytics and advertising components typically require prior consent in the EU while strictly necessary functions are generally exempt.
In EU-facing apps, configure the SDK to obtain prior opt-in consent through a clear affirmative action before non-essential SDKs are initialized, and avoid pre-selected options or implied consent, which are widely considered non-compliant under EU rules.
Separately assess and document a lawful basis under the GDPR for any personal-data processing that follows device access, including for functions that may be exempt from consent under the ePrivacy Directive, rather than treating a consent exemption as the end of the analysis.
Ensure the SDK actually suppresses or blocks downstream tracking SDKs and tags until the relevant consent state is present, and verify propagation of consent signals rather than assuming integration alone enforces choices.
Configure jurisdiction-specific behavior so the tool applies opt-in logic where the EU or UK regimes apply and opt-out or signal-based logic (such as Global Privacy Control) where certain US state laws apply, rather than applying one jurisdiction's rules universally.
Maintain consent records that support demonstrating the user's choices, and treat framework integrations such as the IAB TCF as support for compliance that still requires independent legal review, since enforcement positions and DPA guidance continue to evolve.
