Chrome third party cookies deprecation: migration guide for 2026 planning

Google Chrome’s third-party cookie plans remain in motion, but teams should now treat cross-site cookies as a brittle dependency and migrate embeds and SSO.

TL;DR

In short: Upgrade if you run iframe embeds that rely on a third-party session cookie, or if your “silent SSO” depends on third-party cookies. Use CHIPS for partitioned embed sessions, Storage Access API for user-granted access to first-party cookies, and FedCM for federated sign-in, according to the Chrome and standards documentation.

Key changes

• Embedded sessions break first: When Chrome blocks third-party cookies in iframes, embedded apps commonly show logged-out views, hit 401s, and loop on login.
• Silent SSO gets unreliable: Flows that check an IdP session in a third-party iframe or hidden popup can stop carrying session state across sites.
• CHIPS changes the storage model: Partitioned cookies keep iframe state, but only per top-level site. They do not create a cross-site login.
• Storage Access API adds UX: The embedded app can request access to its first-party cookies, but the user typically must click something.
• FedCM shifts identity into browser UI: Federated sign-in can move away from third-party-cookie session hacks, but you still need server-side OAuth or OIDC verification.
• QA needs real cross-site setup: You need two distinct sites on different registrable domains plus HTTPS, or you will miss failures until production.

Details

What breaks when third-party cookies stop flowing

Engineers usually spot this as “random logouts.” Support teams describe it as “the embed never stays signed in.”

The mechanism stays boring. The browser stops sending a cookie that the embedded origin expects, so authenticated requests arrive without session state.

• Embedded SaaS app or widget: A host page on customer.example iframes app.vendor.example. The vendor’s session cookie does not get sent in the iframe context. The user sees a logged-out widget, repeated prompts, or a 401 loop.
• SSO inside embeds: The relying party or IdP expects to read or refresh a session in a third-party context. Silent sign-in fails. Users re-authenticate more often than before.
• Cross-site analytics attribution: A third-party analytics script expects to read its identifier cookie cross-site. Attribution drops or user stitching degrades.
• Ads and retargeting: Third-party-cookie targeting and measurement weaken in Chrome. Match rates and reporting drift, depending on vendor setup.
• CSRF and redirected flows: Backends that assume a cookie arrives on a cross-site request can start returning 401 or 403 on embedded or redirected paths.

Pick a replacement: CHIPS vs Storage Access API vs FedCM

Teams get this wrong when they ask “can I keep my cookie.” The better question is “what scope of state do I need.”

That scope drives the API choice. You either accept per-site partitions, ask the user for access, or switch to a browser-run identity handshake.

• Choose CHIPS when you need a session inside an iframe per customer site: Set a cookie with the Partitioned attribute, and keep it scoped to the embed. Expect separate sessions for the same person across customer domains.
• Choose Storage Access API when you must reuse a first-party login inside an embed: Gate the experience behind a click that triggers a storage-access request, then retry your authenticated calls after access is granted.
• Choose FedCM when you run federated sign-in: Use the browser’s identity mediation for the front-end step, then send the resulting assertion to your backend to verify and mint your own first-party session.

Implementation patterns (React, Node, TypeScript) without the code dump

This part bites teams on week two. Your auth works in top-level navigation, then the embed fails because the browser never stores or never sends the cookie.

So start by proving the storage model in a small spike. Then wire it into your real session store and IdP config.

• Pattern A, CHIPS partitioned session cookie: On your vendor domain, return a Set-Cookie header that includes Secure, HttpOnly, SameSite=None, and Partitioned. In the iframe, send fetch requests with credentials included. Validate in DevTools that the cookie stores and that subsequent iframe requests include it.
• Pattern B, Storage Access API gate: In the iframe UI, check for document.hasStorageAccess, then show a “Continue” button that calls document.requestStorageAccess on click. After it resolves, retry your “who am I” request. If the API is missing or the request fails, fall back to a top-level redirect to your domain for login.
• Pattern C, FedCM sign-in: Feature-detect navigator.credentials, call credentials.get with your provider config URL and client ID, then POST the returned token to your backend. Your backend verifies the token with the IdP and sets a first-party session cookie.

Operational note: CHIPS gives you per-top-level-site isolation by design. If a user signs in on Customer A and expects that to carry to Customer B, CHIPS will not do it.

QA and testing checklist

Do not test this on localhost and call it done. I’ve seen teams “pass QA” and then face a Monday morning spike in 401s because their test setup never exercised true site boundaries.

Build a small harness page on the customer domain that iframes the vendor app, logs events, and makes failures obvious.

• Environment setup: Use two real HTTPS sites on different eTLD+1, for example customer.test and vendor.test. Use realistic iframe embedding headers and CORS settings.
• Force the no-third-party-cookie world: In Chrome settings, block third-party cookies for your test profile. If you use enterprise-managed Chrome, also test under relevant enterprise policies.
• Functional checks to ticket: Verify an embed stays signed in after refresh for Customer A. Verify Customer A and Customer B do not share a CHIPS session. Verify Storage Access prompts only occur after a click. Verify FedCM returns a token and the backend exchange sets a session cookie.
• Production signals to watch: Track 401 and 403 rates on embedded endpoints by user agent and top-level site. Track repeated “not authenticated” loops in the client. Track FedCM token exchange error rates.

Background

Chrome’s third-party cookie work has shifted over time, according to Google’s public updates, and different browsers already enforce different levels of tracking protection.

That means teams should plan for variance. Treat the timeline as something you monitor in release notes and status updates, not a single date you hardcode into a gantt chart.

• What to monitor: Chrome release notes affecting cookies, CHIPS, Storage Access API, and FedCM. Also monitor enterprise policy changes if you sell into managed environments.
• Suggested cadence: Run a weekly smoke test on your supported Chrome stable and beta. Re-run the embed and sign-in QA cases on each Chrome release cycle.

Other stuff in this release: browser UI changes, policy toggles, and the usual.