HubSpot Marketing and CIPA: Is Your HubSpot Configuration Creating Consent Gaps?

HubSpot is the all-in-one marketing platform agencies deploy on hundreds of client sites. Its tracking code fires on page load by default. Its native consent banner — even after the May 2026 v2 migration — is designed as a notification tool, not a consent gate. And HubSpot is now explicitly named in active CIPA demand letters. Here's exactly where the gaps are, which configurations are vulnerable, and what agencies need to fix for every client running HubSpot.

HubSpot is different from every other tracking tool in this article cluster. It's not just a pixel. It's the CRM, the email platform, the form builder, the landing page tool, the analytics dashboard, the ads manager — all in one platform, all loading a single tracking code that sets cookies and transmits visitor data to HubSpot's servers on every page where it's installed. That breadth is what makes HubSpot's CIPA exposure profile unique: there are more moving parts than a single advertising pixel, and the interconnection between those parts creates gaps that are easy to miss even when agencies think they've addressed consent.

This article maps the specific CIPA exposure points in a typical HubSpot marketing configuration — the ones plaintiff-side demand letters are targeting, the ones the May 2026 v1→v2 banner migration either addressed or left open, and the ones that require external CMP configuration because HubSpot's own tools don't cover them. Not legal advice; consult qualified counsel for specific situations.

What HubSpot tracks by default

When you install the HubSpot tracking code on a client's website, four cookies are placed in every visitor's browser on page load — before any consent interaction:

All four of these cookies are classified as analytics/personalization — not "strictly necessary" for the website to function. Under CIPA's prior-consent standard, all four should be blocked until consent is obtained. Under the default HubSpot tracking code installation, all four fire the moment the page loads.

The core CIPA problem: notification vs. consent gate

Here's the central issue with HubSpot's native consent tooling, confirmed by multiple independent compliance sources including Secure Privacy's March 2026 guide: "HubSpot's native banner is a notification, not a consent gate — it doesn't block non-essential cookies before consent is given."

This distinction matters more than anything else in this article. A cookie notification tells visitors that the site uses cookies. A consent gate blocks those cookies until the visitor has made a choice. CIPA's prior-consent standard requires the latter — not the former.

HubSpot in CIPA demand letters

The v1→v2 banner migration: what changed and what didn't

HubSpot began automatically migrating accounts from its legacy v1 cookie consent banner to v2 on May 11, 2026. The migration is phased — not every account switched at once. If your clients are on HubSpot, some are already on v2, some will migrate in the coming weeks, and some may have custom CSS on their v1 banners that broke during migration.

What v2 adds: Updated design, domain-grouped banner management, Global Privacy Control (GPC) support, opt-out banner type, expanded customization. The GPC support is meaningful — v2's opt-out banner type properly processes the navigator.globalPrivacyControl signal, which v1 didn't.

What v2 doesn't change: The fundamental architecture. HubSpot's tracking code still loads on page load. The "Notification" banner type — the default — still fires cookies before any visitor interaction. The v2 banner migration doesn't retroactively fix a default-fire deployment; it just updates the banner's visual and feature set. If a client was exposed on v1 with the Notification type, they're still exposed on v2 with the Notification type unless you actively change the banner configuration to Opt-in.

The migration risk agencies must watch: Custom CSS targeting v1 banner HTML selectors breaks on v2 migration. If clients have branded banners with custom CSS, the migration may produce an unstyled banner, a hidden banner (CSS conflicts), or a non-rendering banner — all of which mean the visitor sees no consent mechanism at all. Check every client's banner after migration.

The three banner types and which creates CIPA exposure

The third-party script gap HubSpot's banner doesn't address

Even when HubSpot's native banner is correctly configured as Opt-in, there is a critical limitation most agencies don't discover until they test: HubSpot's built-in banner only controls HubSpot's own cookies. Third-party scripts loaded outside HubSpot — Meta Pixel, Google Analytics, LinkedIn Insight Tag, Hotjar, TikTok Pixel — are not blocked by the HubSpot consent banner regardless of configuration.

On a typical HubSpot marketing site, the tracking stack looks like this:

The practical implication: a site running HubSpot's Opt-in banner correctly — so HubSpot's own cookies are blocked until consent — still has every other tracking tool on the site firing before consent if those tools aren't separately gated through an external CMP or GTM consent configuration. The Opt-in banner is necessary but not sufficient for a CIPA-compliant HubSpot deployment with a multi-tool tracking stack.

HubSpot Ads pixels: a separate exposure layer

If a client uses HubSpot's Ads tool (Marketing Hub Professional or Enterprise) to manage Meta Pixel, Google Ads, or LinkedIn Insight Tag, those pixels are deployed through HubSpot's platform — not through the client's own tag manager. This creates a specific configuration challenge: the pixel fires as part of the HubSpot platform, and the consent configuration must be set inside HubSpot's Ads settings rather than in GTM.

HubSpot's documentation confirms: "if you're using the HubSpot ads tool to add a pixel to pages with the HubSpot tracking code, your consent banner will automatically display when the pixel fires on your pages. If you require visitors to opt into cookie tracking, the pixel will not be able to place any cookies until the visitor confirms their consent." This only works correctly when: (a) the banner is configured as Opt-in type, and (b) the specific ads pixel option in the banner settings is enabled. Both conditions must be met — having Opt-in type but not enabling the ads pixel setting, or vice versa, leaves a gap.

HubSpot forms and real-time data transmission

HubSpot forms create a specific CIPA exposure pathway that's separate from cookie tracking: form field inputs are transmitted to HubSpot's servers in real time as visitors type. When a visitor starts typing their name into a HubSpot form — even before submitting — that keystroke data can flow to HubSpot's infrastructure via the form's JavaScript. This is the exact "real-time transmission of communication contents to a third party before consent" pattern that CIPA § 631 wiretapping claims are built on.

The demand letter pattern documented in the Vivek Shah analysis (Jeffer Mangels, April 2026) specifically targets this: the plaintiff types into a form or search bar on the defendant's site, watches the network tab, observes real-time transmissions to HubSpot (or Google, or Meta), and attaches the screenshot as evidence of interception "in transit" without prior consent. HubSpot forms embedded on pages where the HubSpot tracking code fires before consent are in this exposure pattern.

How to fix it: the three-path approach

There are three viable approaches to achieving CIPA-defensible consent on a HubSpot site, each with different effort levels and coverage scope:

Path 1: HubSpot native Opt-in banner (limited coverage)

What it covers: HubSpot's own cookies (__hstc, hubspotutk, __hssc, __hssrc). If Ads pixel setting is also enabled, the HubSpot-deployed pixel. Nothing else.

How to configure: Settings → Privacy & Consent → Cookies → Banner Type: Opt-in. Enable "Prevent HubSpot cookies from loading without visitor consent." Enable the Ads pixel option if using the HubSpot Ads tool.

When it's enough: Only if the site's entire tracking stack consists of HubSpot's own tools with no external analytics, advertising pixels, or third-party scripts. Rare for any marketing-active client.

Critical limitation: Does not block Meta Pixel, Google Analytics, LinkedIn Insight Tag, or any other tracking tool not managed through HubSpot's native platform.

Path 2: HubSpot Consent API + external CMP (recommended for multi-tool stacks)

What it covers: Everything — HubSpot's own cookies controlled through the Consent API, all third-party scripts controlled through the external CMP's consent gating.

How to configure: Disable HubSpot's native banner (window.disableHubSpotCookieBanner = true in the page head). Implement your external CMP (ConsentPixel or similar) to block all scripts before consent. Wire the CMP's consent events to HubSpot's Consent API using window._hsp.push(["setHubSpotConsent", {...}]) so HubSpot respects the CMP's consent choices. External CMP also gates all non-HubSpot scripts through GTM consent mode.

Why it's recommended: Single consent mechanism controls everything — HubSpot cookies and all third-party tools — creating one consistent prior-consent gate with unified records. The CMP's consent logs cover the entire stack, not just HubSpot's portion.

Path 3: GTM-only approach (for sites using GTM over HubSpot native)

What it covers: All scripts managed through GTM, including the HubSpot tracking code if loaded via GTM rather than natively. Does not cover HubSpot cookies placed by HubSpot-native page builder or CMS features.

Limitation: HubSpot websites built with HubSpot CMS often load HubSpot tracking code at the platform level, not through GTM. GTM consent mode won't block platform-level HubSpot cookies even if configured correctly. Must confirm whether the client's HubSpot tracking code loads through GTM or natively.

Per-client HubSpot compliance checklist

Frequently asked questions