Tech Lab Trusted Server – An Updated Explainer

Updated 13th October 2026: we first published this explainer in March 2025, when Trusted Server was still a Proof of Concept. We’ve refreshed it to reflect where the project stands today, and why Apple’s iOS 27 update has made it urgent for publishers to consider this approach.

The iOS 27 Wake-Up Call

In September, Apple released iOS 27 and Safari quietly started refusing requests to a short list of ad tech domains, most of them belonging to identity and data companies. The list also caught adsrvr.org, the domain The Trade Desk uses to request and deliver ads, leaving the largest independent DSP unable to serve ads in Safari on updated iPhones and iPads (we cover the details further down).

Apple has since fixed that in a beta of iOS 27.2, but a fix for one company doesn’t change the bigger lesson for our industry to learn from. The block works on domains, not on what a company uses them for, which is how a DSP’s ad delivery got caught in a net that appears to target identity and data companies. Any set-up that relies on a reader’s browser calling a third party’s domain can be switched off the next time Apple updates its list, and Apple can reportedly do that without releasing a new version of iOS.

Historically some of the earliest targeting and identity systems were built into publishers’ own web servers rather than run from the browser. A one-line JavaScript tag could work more effectively because it was quicker and cheaper for vendors to roll out, and browsers have been chipping away at that model ever since.

What’s different now is that the infrastructure is so easy to rent. As a result, edge platforms run code close to readers all over the world, so publishers can handle these calls under their own domain without running their own servers. That’s the idea behind IAB Tech Lab’s Trusted Server, and it’s why Tech Lab CEO Anthony Katsur’s advice since the blocks became public has been simple: Go server side.

A quick test (courtesy of Daniel Jaye – click here) for your own stack is worth borrowing. For every call your pages make, ask who owns the domain, whose customer relationship it relies on, and whose systems end up holding the data. If the answer isn’t ‘ours’, then that call is a risk the anytime that Apple decides to update its list.

Trusted Server is an open-source initiative from IAB Tech Lab that moves critical advertising functions out of the browser and into infrastructure that publishers control. It launched as a Proof of Concept in March 2025. Today IAB Tech Lab lists the Proof of Concept as completed and the MVP (minimum viable product) as in progress and ready for more publishers to test. Its 2026 roadmap said Tech Lab is now doubling down on the initiative because browser signal loss isn’t going away, and that Version 1.0 was delivered early this year, with the first publisher pilots to follow.

Below we cover what Apple changed, what Trusted Server is and how it works, what’s new since the Proof of Concept, what it can’t do yet, and how Australian publishers can start testing it. We fully support the project here in Australia, and we’re keen to help local publishers with it as much as we can. Also we have Tony Katsur visiting Sydney in November 2026 and will be running a dedicated publisher session in which this project will be a headline topic.

As a reminder, IAB Tech Lab is a global nonprofit consortium that develops, oversees and updates critical global technical standards and solutions, designed to support a healthy and sustainable digital media and advertising industry. Its core areas of focus are transparency, fraud, identity, data, consumer privacy, ad experiences & measurement, and programmatic effectiveness.

To read a genuinely excellent recent article from Rowena Lam, IAB Tech Lab’s Senior Director of Privacy and Data, see Apple’s WebKit Updates Mean Advertising’s Future Is Server-Side, and for a wider round-up of IAB Tech Lab’s more work, see our summary of six key recent updates

---

What Apple Changed in iOS 27

iOS 27 began rolling out on 14th September 2026. With it, WebKit (the browser engine behind Safari) started blocking requests to a private list of ad tech and data domains outright. This isn’t a cookie restriction. When a domain is on the list, the browser never makes the request, so bids don’t happen, identity signals don’t resolve and creatives don’t render. Apple didn’t announce it. The blocking code had been in WebKit’s public code since February, but the list itself only came to light when The Trade Desk filed a bug report.

As first reported by AdExchanger, that bug report (WebKit Bug 324771, filed by The Trade Desk on 21 September) listed the nine entries it could see on the blocklist: eight vendor domains, namely adsrvr.org (The Trade Desk’s core ad request and delivery domain), uidapi.com (Unified ID 2.0), id5-sync.com and eu-1-id5-sync.com (ID5), rlcdn.com and pippio.com (LiveRamp), permutive.com (Permutive) and ad.gt (Audigent, now part of Experian), and tainted.example, which appears to be a test entry.

Three things made this update distinctly different to previous Safari changes we’ve seen:

• It’s highly opaque: Apple hasn’t published the list, its criteria for inclusion or an appeal process. Only Apple knows the full contents, and only Apple can remove an entry.
• It’s very broad: the block works on the registrable domain and overrides Safari’s usual exemptions, so a single entry covers every subdomain beneath it, including the hosts that carry bid requests and creatives (see this technical analysis of the WebKit code, which was merged back in February 2026).
• It’s not just Safari: in Australia, every browser on iPhone and iPad must use WebKit, so the block also applies to Chrome and other iOS browsers, as well as in-app browsers built on WebKit.

Apple’s iOS 27.2 beta has since removed adsrvr.org from the list, which is good news for The Trade Desk once that update reaches users (Digiday reports that’s not expected before the end of October at the earliest). The identity and data vendors on the list haven’t had the same reprieve, and the underlying capability remains. AdExchanger has also reported that Apple is preparing a far larger potential blocklist covering hundreds of CDPs, ad tech and martech companies, data sellers and ID graph operators, which can reportedly be updated remotely without a new iOS release. Apple hasn’t confirmed this.

The early revenue impact has been modest. Aditude reported to Digiday that Safari on iPhone and iPad accounts for 11.7% of the ads its customers serve. Among readers who’d updated to iOS 27, eCPMs fell 10.5%, but with only around 8% of users updated, the overall hit was about 1%. That will grow with adoption, and Australian publishers are more exposed than most: iOS accounted for around 63% of mobile web page views in Australia in September 2026 (StatCounter), and every one of those page views runs through WebKit.

Not the First Time: How Other Browsers Have Broken Ads Before

iOS 27 feels rather abrupt and came as a surprise, but publishers need to be aware that it’s the latest chapter in a decade of browser-led breaks. Publishers have been adapting since 2017, and each wave has relentlessly pushed more logic away from the browser:

• Safari ITP (2017-2023): Apple led the charge. Intelligent Tracking Prevention arrived in 2017, using machine learning to restrict cookies from domains it classified as trackers. In 2019, ITP 2.1 capped first-party cookies set by JavaScript at seven days (cut to 24 hours in some cases by ITP 2.2), and in 2020 Safari blocked all third-party cookies by default. Later in 2020 it began capping cookies set through CNAME cloaking at seven days, then added Private Click Measurement and, from 2023, stripping of some tracking parameters from links. Every change shortened the window publishers had to recognise a returning reader. Apple’s Tracking Prevention Policy says it treats attempts to get around these protections as seriously as security exploits, and may add restrictions without notice.
• Firefox ETP & Total Cookie Protection (2019-2022): Mozilla turned on Enhanced Tracking Protection by default in 2019, blocking known third-party tracking cookies and cryptominers. Total Cookie Protection, which gives every site its own cookie jar so cookies can’t be read across sites, arrived in 2021 and became the default for all Firefox users in 2022. The same year, Firefox began stripping known tracking parameters such as fbclid from links in Strict mode and private browsing. Like Safari, Firefox was trying to stop cross-site tracking, but the side effect was that ID syncs and audience pixels that relied on third-party contexts stopped working.
• Brave & Edge (2020+): Brave has blocked third-party ads and trackers by default since launch, and runs its own opt-in ad system. Edge shipped Tracking Prevention in 2020, with Balanced mode on by default and Strict mode blocking most third-party trackers. Brave’s share in Australia is small, but both helped make tracking protection a default rather than an opt-in.
• Chrome Privacy Sandbox (2019-2025): Chrome took the opposite approach and tried to rebuild advertising inside the browser. The industry spent years testing Topics (interest-based), Protected Audience, formerly FLEDGE (on-device remarketing auctions), and Attribution Reporting, through repeated delays to Chrome’s third-party cookie phase-out (we covered the 1% rollout here). Google then dropped the phase-out in July 2024, kept third-party cookies, and in October 2025 retired most remaining Privacy Sandbox APIs citing low adoption. Publishers who invested in integrating Topics or Protected Audience had to unwind that work.

The pattern is clearly consistent. Safari and Firefox will remove third-party signal unilaterally, Brave blocks it by design, and Chrome tried to replace it with browser-run APIs before reversing course. In each case, set-ups that relied upon the reader’s browser calling a vendor’s domain broke, and publishers were left to re-plumb. iOS 27’s domain block is the most literal version yet: instead of shortening a cookie’s life, WebKit refuses to make the request at all.

The lesson from all of them is the same. If you build your monetisation on a browser vendor’s roadmap, you will inherit its reversals.

That’s the case for publishers taking control, and it’s what Trusted Server is designed for. Instead of the reader’s browser calling dozens of third-party domains, it talks only to the publisher’s own domain, and the calls to SSPs, identity and audience partners happen server-to-server at the edge. Analyses of WebKit’s public code indicate the new block applies to calls a page makes to other sites, not to calls back to the site the reader is on. So for partners connected through Trusted Server, the browser doesn’t contact the vendor’s domain at all. That’s a reading of the code rather than a device test, so test it against live iOS 27 traffic before relying on it.

Publishers are already acting. US publisher Paradium.AI (owner of Parade and Men’s Journal, and an early contributor to Trusted Server) has rerouted its Permutive integration, one of the blocked vendors, through Trusted Server and is testing whether audience data flows again in Safari. Its head of revenue and data, Stephanie Mazzamaro, was candid that viewability, verification and getting buyers to accept the numbers are where most of the remaining work sits. IAB Tech Lab says it has seen a large influx of publisher interest and is preparing to go live with its first publisher.

---

What is the Trusted Server & Why Is It Needed?

The Tech Lab Trusted Server is an open-source framework designed to give publishers greater control over their digital advertising monetisation, in the face of increasing browser restrictions and evolving privacy regulation. IAB Tech Lab now describes it as ‘the new execution layer for the open web.

The core intention is to shift critical advertising functions (ad requests, auction execution and creative delivery) from the client side (the browser) to a publisher-controlled server-side environment. Publishers run it at the edge of their own network, either at their existing CDN layer or as a backend behind it, where it acts as a reverse proxy and orchestration layer for both their content and their ad stack.

It’s fully open-source (under the Apache 2.0 licence) and free to use, and it integrates with Prebid, so existing SSP relationships carry across. Prebid is a very widely used programmatic auction tool, also free and open-source, providing a suite of products that let publishers implement header bidding on their websites. For more on setting up and testing Trusted Server, see further below.

A well-known example of this kind of evolution (client side to server side) came some years ago when publishers began using server-side header bidding for their open-market programmatic activity. That let them offer inventory to multiple demand sources at once, and those set-ups have since moved from latency-laden client-side solutions to sophisticated server-side systems.

image source: Freestar

Here are the main reasons publishers are looking at this type of solution:

Browser Restrictions, Privacy Regulation & Ongoing Signal Loss

• Browser Domain Blocking: as covered above, WebKit on iOS 27 now blocks client-side requests to a private, and potentially growing, list of ad tech and data domains. Calls made server-to-server from the publisher’s own environment don’t pass through the browser, so they aren’t subject to that block.
• Signal Degradation: browser features such as Intelligent Tracking Prevention in Safari and Enhanced Tracking Protection in Firefox block or restrict third-party cookies and scripts, and Safari also caps the lifetime of some first-party cookies. Server-side systems mitigate this by centralising data processing, so more signals can reach demand-side platforms (DSPs) without being stripped away.
• Third-Party Cookies: Safari and Firefox have restricted third-party cookies by default for years. Google ultimately kept them in Chrome, but they’re far from a reliable foundation. Server-side ad serving preserves first-party signals (e.g. contextual data or publisher-provided IDs) by handling them on the server, where they’re less exposed to browser restrictions.
• Stricter Privacy Laws: on 31 August 2026 the Australian Government released an exposure draft of the Privacy Amendment (Personal Data Protection) Bill 2026, the long-awaited second tranche of Privacy Act reform, with legislation expected to be introduced before the end of 2026. Among around 40 proposals, it would treat people as reasonably identifiable where they can be singled out (even if their name isn’t known), introduce a ‘fair and reasonable’ test for handling personal information and strengthen consent requirements. Server-side solutions let publishers process data in a first-party context, minimise what’s shared with third parties, and apply their own consent and governance rules before anything leaves their environment.

Improved Performance & Consumer Experience

• Reduced Latency: client-side ad serving typically needs many network requests (fetching scripts, calling SSPs, running auctions), all from the browser, which slows page loads. Server-side solutions consolidate these steps into server-to-server calls. IAB Tech Lab cites the potential to double page load speed, improving viewability and other key metrics.
• Fewer Browser Requests: moving auctions and ad rendering to the server cuts the number of HTTP requests from the browser significantly. That reduces page bloat and improves Core Web Vitals, which can also support SEO.
• Improved Mobile Experience: on mobile devices, where bandwidth and processing power are often limited, server-side ad serving offloads work from the device, giving faster, smoother experiences that keep readers on the page.

Ad Blocking and Fraud Mitigation

• Ad Blocker Resilience: most ad blockers target third-party scripts and trackers. When ads are requested and stitched into the page from the publisher’s own infrastructure, there are far fewer third-party calls for blockers to act on.
• Fraud Reduction: client-side ad serving can be more susceptible to bot-driven fraud such as spoofed impressions or fake clicks (see our Ad Fraud Handbook) because it exposes auction logic to the browser. Server-side systems centralise control, so publishers can apply stronger traffic validation before bids are processed. Trusted Server also provides cryptographic functions such as bid parameter signing, with ad fraud signals and plug-ins for fraud prevention vendors on its roadmap.

Control and Flexibility

• Data Ownership: with client-side set-ups, third-party vendors often control data flows, leaving publishers with limited visibility. Server-side solutions keep data within the publisher’s domain, so they can use their first-party data for targeting, measurement and monetisation without intermediaries skimming value. IAB Tech Lab highlights reduced data leakage as a way for publishers to charge a premium for their audiences.
• Customisation: server-side frameworks such as Trusted Server (and Prebid Server) let publishers tailor auction logic, prioritise demand partners, or integrate their own tools, rather than living with whatever each vendor’s client-side tag does.
• Reduced Dependency: as browsers and ‘big tech’ vendors tighten control over the client side (often with little notice, as iOS 27 has shown), server-side solutions help publishers future-proof their stacks and reduce their reliance on large tech vendors.

Programmatic Efficiency & Effectiveness

• Header Bidding Evolution: client-side header bidding still works, but it adds latency and complexity with multiple SSP calls. Server-side header bidding (e.g. via Prebid Server) consolidates these into one server-side auction, which can lift fill rates by exposing inventory to more demand partners at once.
• Scalability: servers handle high traffic volumes and complex auctions far better than browsers struggling under dozens of scripts and trackers.
• Gradual Migration: publishers don’t need to move everything at once. Trusted Server can run existing Prebid.js auctions alongside tagless, server-side auctions in the same page context, and the MVP is designed for publishers to start with a percentage of their inventory.

---

How Does the Trusted Server Actually Work?

Trusted Server sits in the publisher’s request path, either at the CDN perimeter or behind the publisher’s existing CDN as a backend in front of the origin server. Every page and ad request passes through it, so it sees the content and the ad stack at the same time and can act on both. According to IAB Tech Lab, it needs little or no change to a publisher’s CMS or monetisation stack.

When we first wrote this explainer, the Proof of Concept ran only on Fastly‘s edge cloud platform. Trusted Server is now far more portable, and its core building blocks are:

1. Trusted Server Framework: the server-side ad management logic, covering ad requests, server-side auctions via Prebid Server, ad stitching, signals collection, consent handling and a publisher-owned first-party identifier (the Edge Cookie).
2. Edge Infrastructure (No Longer Fastly-Only): through a portability layer called EdgeZero, one codebase now runs on Fastly Compute, Cloudflare Workers and Spin (the open-source runtime from Fermyon, which Akamai has since acquired), or as a native server (via its Axum adapter) inside any Docker or Kubernetes environment. Akamai’s own EdgeWorkers platform isn’t supported yet, and Fastly is still the best-documented option.
3. Rust & WebAssembly: Trusted Server is written in Rust and compiled to WebAssembly (WASM), giving fast, memory-safe and verifiable binaries with no cold-start delay, which suits performance-critical code running at the edge.

Workflow Example

• User visits ‘publisher.com’.
• The request passes through Trusted Server, running at the publisher’s edge under the publisher’s own domain.
• Trusted Server captures first-party signals (page context, consent signals and its first-party Edge Cookie) and starts a server-side auction via Prebid Server, calling any configured identity or audience partners server-to-server where consent allows.
• The SSPs return bids (e.g. $2 from SSP A, $1.50 from SSP B, $3 from SSP C).
• Trusted Server selects the winning ad, stitches in the creative and returns the page to the browser. (How this works with the publisher’s ad server and direct-sold campaigns depends on that ad server. Google Ad Manager isn’t one of its ready-made integrations yet.)
• The browser renders the ad as part of publisher.com, without calling third-party ad tech domains directly.

image source: IAB Tech Lab

How Trusted Server & Prebid Server Fit Together

A common question is whether Trusted Server replaces Prebid Server. It doesn’t. The two are complementary. Prebid Server is the auction engine: it sends bid requests to demand partners, scores the bids and picks a winner, working mainly with impression-level information. Trusted Server sits around it. On the way in, it collects and packages the signals (page context, consent strings and identifiers) and passes them to Prebid Server. On the way out, it takes the auction result, hands off to the publisher’s ad server where an integration exists, and stitches the creative into the page. IAB Tech Lab has published a dedicated explainer on how the two work together, linked from its Trusted Server page.

image source: IAB Tech Lab

This move also puts publishers in a better position for a few wider industry trends:

• Contextual Advertising Revival: as targeting shifts from user tracking towards contextual signals, server-side solutions can analyse page content and context in real time, delivering relevant ads without client-side profiling.
• Browser Independence: the retirement of Google’s Privacy Sandbox and Apple’s iOS 27 domain blocks both show that browser-led approaches can change direction, or disappear, with little notice. Publishers with server-side control of their stack are better placed to adapt, whatever the browsers do next.

---

What’s New Since the Proof of Concept?

The Proof of Concept demonstrated the basics: sending an ad request to an exchange, processing the response, stitching the ad into the page, and serving the page and ad. Since then the project has moved on to its MVP, the set of features the Trusted Server Task Force considers necessary for publishers to start running a percentage of their inventory through it, along with other new capabilities:

• Edge Cookie (EC): a first-party identifier minted by the publisher at the edge (using HMAC with a publisher-held secret). Because it’s set by the publisher’s own domain, it gives a more durable first-party identifier and stronger signal in restrictive browsers such as Safari, and what it’s shared with downstream is decided by the publisher’s own configuration. Where publishers sync Edge Cookie IDs with partners, that sharing is consent-gated and publisher-controlled, but it’s still the kind of cross-site data sharing Apple’s policy targets, and it could well be treated as personal information under the proposed Privacy Act changes.
• Consent Handling: Trusted Server extracts and decodes consent signals (TCF v2, GPP and GPC) and applies them to ad serving decisions, with the publisher configuring jurisdictions and how signals are interpreted.
• Creative Types & Partners: display, native and video creative types, ID and audience provider integrations, and server-side tagging.
• Request Signing: outgoing requests can be cryptographically signed, with the public keys published (via JWKS) and rotated, so partners can verify a request genuinely came from the publisher’s deployment. IAB Tech Lab describes this as helping to ensure trust across the programmatic ecosystem.
• Tooling: a command-line tool (ts) that can audit one of your public pages and generate a draft configuration to start from, so engineering teams don’t have to inventory every script by hand.

Current Project Status

source: IAB Tech Lab, October 2026

---

What Trusted Server Doesn’t Do (Yet)

Trusted Server isn’t a magic switch, and it’s worth being clear about its limits:

• It doesn’t revive cross-site third-party cookies: it gives publishers a first-party identifier they control, plus server-side pathways to the ID and audience partners they choose to work with.
• It isn’t a way around consent: serving from your own domain doesn’t change what a reader has agreed to. Consent still decides what leaves the edge, and the publisher is accountable for those choices.
• First-party has to be genuine: WebKit’s Tracking Prevention Policy says Apple treats attempts to get around its protections as seriously as security exploits, and may add restrictions without notice, including against specific companies. Trusted Server’s strength is that the publisher really does own the relationship and the infrastructure. Routing a vendor’s own tracking through a publisher subdomain, the old CNAME cloaking approach, doesn’t count, and Safari already limits it.
• Partners need to be ready: commercial agreements with SSPs and ID partners still apply, and partners need to support server-side integrations. Trusted Server changes the transport, not the relationships.
• It needs to be deployed and run: publishers (or their technology partners) need to deploy it on an edge platform or in their own containers, then configure and manage it. The software is free, but edge hosting is a separate cost, and every page and ad request passing through it is billable traffic.
• It’s still maturing: IAB Tech Lab says Version 1.0 was delivered early in 2026, and CEO Anthony Katsur declared it production-ready on 8 October. At the time of writing, though, the public repository hadn’t published tagged releases and the documentation is built from the main branch. Engineering teams should lock to a specific version of the code and test thoroughly before scaling up. It’s also worth knowing that when publishers moved auctions server-side in the past, some earned less because buyers could recognise fewer readers, and there are no published results yet showing how server-side impressions in Safari price against today’s client-side ones.
• Some capabilities aren’t there yet: the project’s public roadmap is refreshingly clear about this. Invalid-traffic scoring and automated fraud detection, a direct Google Ad Manager integration, Akamai EdgeWorkers support and a standalone cross-publisher identity service are not current capabilities. Brand safety and measurement plug-ins are future enhancements, to be prioritised by the Trusted Server Task Force.
• It’s for websites, not app ads: ads inside native iOS apps are governed by App Tracking Transparency and Apple’s app rules, which an edge proxy in front of a website doesn’t touch. Web pages opened in an app’s built-in browser are still web pages, though, and the iOS 27 block applies there too.
• It can’t control what browsers do next: but blocking a publisher’s own domain would break the site itself for every reader, which is a much higher bar than adding vendor domains to an unpublished list.

---

How Can Australian Publishers Get Started?

1. Read up: IAB Tech Lab’s Trusted Server page and the project documentation cover the architecture, configuration and partner integrations.
2. Access the code: the GitHub repository includes a quick-start guide and the command-line tool, which can audit one of your public pages and generate a draft configuration to start from.
3. Map your exposure: identify which of your pages and partners rely on domains affected by the iOS 27 blocks, and split your Safari revenue by iOS version to size the impact. Our tracking audit guidance is a useful starting point for building that inventory.
4. Start small: the MVP is designed for publishers to run a percentage of their inventory through Trusted Server. iOS 27 Safari traffic is a useful place to measure the difference in bid density, win rates and revenue against your current set-up, but only send data your readers have consented to, and only to partners contracted to receive it server-side.
5. Get involved: get in touch and we can help you remotely join the Trusted Server Task Force to help shape priorities such as fraud, brand safety and measurement. Submit your interest directly to IAB Tech Lab.

If you’re keen to test Trusted Server or would like to find out more, please get in touch. We’re happy to help connect local publishers with IAB Tech Lab, and we’ll keep members updated as the project progresses.

---

External URLs

• Trusted Server (IAB Tech Lab)
• Trusted Server project documentation
• Trusted Server GitHub repository
• WebKit Bug 324771 (iOS 27 domain blocking)