Safari's Identity-Vendor Blocklist in iOS 27: What Happens to Your Prebid User ID Modules?

Apple's latest WebKit restrictions could change how publishers use third-party identity solutions in programmatic advertising. With iOS 27, iPadOS 27, macOS 27 and visionOS 27, WebKit has introduced network-level restrictions on certain identity-resolution services. For publishers running Prebid.js, this affects how User ID modules retrieve, refresh and pass identifiers to demand partners.

The change is particularly relevant to publishers using solutions such as LiveRamp, ID5 and Unified ID 2.0, which rely on identity signals to support audience recognition across websites. It does not disable Prebid User ID modules altogether, but it introduces another dependency that publishers need to consider when managing their identity integrations.

What Apple's Identity-Vendor Blocklist Actually Does

On October 19, 2026, WebKit published Blocking Identity Resolution Infrastructure, explaining its approach to restricting third-party identity-resolution services.

The restrictions target services that collect personal information, such as email addresses submitted during registration or newsletter sign-ups, and convert it into identifiers that can recognise users across multiple websites.

Rather than relying solely on cookie restrictions, WebKit blocks network access to specified domains associated with this type of identity resolution. If a browser cannot reach an affected endpoint, the corresponding service may no longer be able to retrieve or refresh identifiers as expected.

The restrictions apply to iOS 27, iPadOS 27, macOS 27 and visionOS 27. They also have implications beyond Safari itself. Browsers running on iOS and iPadOS generally use WebKit, so publishers should not assume that switching to Chrome or another browser on the same device avoids the restrictions.

The Identity Vendors Affected So Far

Industry reports have identified several companies whose services were included in the initial restrictions, including LiveRamp, ID5, The Trade Desk, Permutive and Audigent.

These companies offer different identity, audience and advertising services, and not every product or endpoint they operate is blocked.

There is also a distinction between identity resolution and advertising delivery. During the initial rollout, The Trade Desk's adsrvr.org domain was reportedly swept into the restrictions even though it supports ad delivery, not identity resolution. The issue was fixed in WebKit Bug 324771.

That fix applies only to adsrvr.org. Unified ID 2.0's own domain, uidapi.com, was included in the same restrictions and has reportedly remained blocked, since the two domains serve different functions and were addressed separately. Publishers should examine individual endpoints rather than assume every service from an affected vendor shares the same status.

Apple has not published a complete list of affected vendors or detailed criteria for adding and removing domains. Reports from AdExchanger suggest the list may be updated dynamically, potentially extending beyond the initial group of identity providers.

How This Could Affect Prebid User ID Modules

Prebid.js supports multiple User ID submodules, allowing publishers to integrate identity providers through a common configuration framework.

These modules generally retrieve identifiers from external providers, process the returned values and make them available to supported bidder adapters. Depending on the integration, identifiers may also be stored locally so they can be reused in subsequent sessions. WebKit's restrictions could interrupt this process when a module depends on a blocked third-party endpoint.

However, a failed request does not necessarily mean that every previously established identifier immediately disappears. The effect depends on how the particular module retrieves, stores and refreshes its IDs.

New IDs vs Stored IDs

Prebid's User ID framework supports different methods for obtaining and maintaining identifiers. A module can use getId to obtain an identifier and may use extendId to refresh or extend an existing one.

If an identity provider's endpoint becomes inaccessible, new ID requests or refresh operations that depend on that endpoint may fail. Previously stored identifiers could remain available if they are still valid and can be retrieved without contacting the blocked service.

Acquiring a new ID, retrieving an existing one and refreshing an expired one are three different operations, and WebKit's restrictions can affect them differently. For example, a publisher might continue seeing an identifier in bid requests even after the identity provider can no longer refresh it. Once the stored value expires, however, the identifier may no longer be available. The outcome also depends on storage settings, consent requirements and the specific implementation of each User ID module.

Prebid's User ID Module documentation provides further details on the framework, including ID retrieval, storage and refresh behaviour.

Effects on EIDs and Bid Requests

Prebid can make user identifiers available through its Extended IDs (EIDs) structure, which allows supported bidder adapters to pass identity information in OpenRTB-compatible formats.

If an identifier becomes unavailable, the relevant bidder may receive a request without that particular identity signal. This does not automatically prevent the bidder from responding or participating in the auction. Demand partners can still evaluate inventory using other available information, including page content, placement details, device signals and contextual data. The actual effect depends on which identifiers individual bidders support and how much they rely on those signals when evaluating inventory.

Publishers should therefore avoid assuming that a missing User ID will automatically result in an unfilled impression. The more relevant question is whether reduced identity availability changes bidder participation, bid prices or the value of available inventory.

What Publishers Should Check in Their Prebid Configuration

Publishers running multiple User ID integrations should review their existing configurations and identify which services depend on third-party endpoints.

Review the User ID submodules included in the Prebid.js build. Check whether integrations such as LiveRamp, ID5 and Unified ID 2.0 are enabled, and identify the domains they contact when obtaining or refreshing identifiers. Separate the different requests each integration makes: initial ID acquisition, synchronisation and refresh operations may use different endpoints, so a restriction affecting one domain does not necessarily mean the entire identity solution has stopped working.

Storage settings also deserve attention. Check whether identifiers are stored in cookies or HTML5 Local Storage, how long they remain valid and when the module attempts to refresh them. An existing ID may continue to be available even when a new request to the identity provider fails.

The expected identifiers should also be checked through pbjs.getUserIds() and pbjs.getUserIdsAsEids(). Compare the results with the outgoing bid requests to see whether the relevant EIDs are reaching the intended bidder adapters.

The bidders configuration is particularly important here. Not every bidder supports every identity format, and a missing identifier in one bidder's request does not necessarily indicate a problem with the entire User ID integration.

Browser testing can help reveal differences in behaviour across operating systems. Test Safari on iOS 27 and macOS 27, as well as Chrome on iOS 27. Browsers on iOS generally use the WebKit engine, so switching browsers on the same device does not necessarily avoid these restrictions.

Browser developer tools, along with the Header Bidding Inspector Chrome extension, can help identify failed network requests, storage behaviour and missing identifiers. These tests are more useful than relying on a single JavaScript error or assuming that a vendor's entire service has been blocked.

BiddingStack helps publishers manage Prebid configurations, bidders and ad placements across multiple websites. It makes it easier to adjust and test header bidding setups as browser privacy restrictions affect identity signal availability. Start at BiddingStack.com or reach us at [email protected].