The IAB Tech Lab’s Device Storage Duration & Access Disclosure specification has been updated to close a gap that’s existed since the Transparency and Consent Framework was built for the web: mobile apps could bundle a dozen third-party SDKs, each quietly reading device identifiers and writing to local storage, without any of them showing up in the vendor disclosure files that consent management platforms rely on. The new requirement forces every vendor to declare the actual SDK package identifiers running inside a mobile app, not just a generic company name in a vendor list. For teams that ship both a web property and a mobile app under the same consent regime, that’s a meaningful change in what “compliant” actually means.
The problem this solves is real. A CMP can only be as accurate as the vendor list feeding it, and until now that list was self-reported at the company level — “Analytics Vendor Inc.” — with no way to verify which SDKs, at which versions, were actually bundled into a given app build. A marketing SDK and a crash-reporting SDK from the same vendor might have wildly different data practices, but a consent banner had no way to distinguish them. Teams that don’t start tracking package-level SDK inventory now will find themselves scrambling later, when a CMP vendor or an app store review flags a mismatch between what’s disclosed and what’s actually bundled in the binary.
Data Points to Track
- SDK package identifier and version for every third-party SDK bundled into each app build (iOS bundle ID equivalents, Android package names)
- Declared purpose per SDK (analytics, attribution, advertising, crash reporting) mapped against what the SDK’s own telemetry actually sends
- Consent gate status per SDK at init time — whether the SDK was allowed to initialize before or after consent was captured
- Build-to-build SDK diffs, since a dependency bump can silently add or upgrade a bundled SDK without anyone updating the disclosure file
- CMP vendor list sync timestamp, so you can prove disclosure was current as of a given release
- Data-at-rest location per SDK (on-device only vs. transmitted to a vendor endpoint), since the spec distinguishes storage-only from access-and-transmit behaviour
Setup Steps
- Generate a full SDK manifest per build using your dependency manager’s lockfile (CocoaPods, Gradle) rather than relying on a manually maintained spreadsheet.
- Cross-reference the manifest against your CMP’s vendor list on every release, flagging any SDK present in the build but absent from disclosure.
- Instrument SDK init calls to log the consent state at the moment each third-party SDK actually starts, not just when your own consent prompt fires.
- Automate the diff step in CI so a dependency bump that adds a new SDK fails the build (or opens a ticket) until disclosure is updated.
- Re-export and re-submit your vendor disclosure file to your CMP provider ahead of the compliance deadline, and set a recurring reminder to repeat this every release cycle rather than once.
Actionable Insights
The teams that get burned by this kind of spec change aren’t the ones with bad intentions — they’re the ones whose disclosure process was a one-time setup task instead of a release-gate. Once SDK inventory is tracked per build, the data tells you two things immediately: which SDKs are initializing before consent (a compliance risk you can fix in code today) and which ones nobody remembers adding (a housekeeping problem that’s usually cheaper to remove than to keep disclosing). Treat the manifest diff as part of your release checklist, the same way you’d treat a security dependency scan — because functionally, it is one.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert