Blog · Protocol
OpenRTB 3.0 and ads.cert in 2026: still waiting, still worth watching
OpenRTB 3.0 went final in November 2018. Seven and a half years later, the layeredOpenrtb envelope and its built-in request signing, ads.cert, still have no meaningful footprint in production bidstreams. We checked what IAB Tech Lab is actually shipping in 2026 against what 3.0 promised, and the gap has not closed. It has moved.
What 3.0 was supposed to fix
OpenRTB 2.x is one document: the BidRequest object carries auction fields and domain fields (site, app, device, user, video) together. 3.0 split that into layers: transport, format, a thin transaction layer (the Openrtb envelope with an item array), and a domain layer delegated to AdCOM 1.0. Alongside it, ads.cert added cryptographic request signing directly into the protocol: the Source object grew ds (digital signature), dsmap (the fields it covers), cert (signer certificate reference), and digest, so a buyer could verify a request actually came from the publisher it claimed to. We cover the full field-by-field mapping in OpenRTB 2.6 vs 3.0. This piece is about where things stand now, not how the spec reads.
ads.cert: the standard changed shape, and adoption still didn't follow
ads.cert 1.0, from 2018, was scoped to signing OpenRTB bid requests specifically, the fields listed above. IAB Tech Lab announced ads.cert 2.0 in September 2021, and it is a different thing: Call Signs (DNS-published public keys that identify a business) and Authenticated Connections (cryptographic signing for any server-to-server HTTP request, not just bid requests). The scope broadened from "sign the OpenRTB Source object" to "sign any programmatic HTTP call," with CTV supply-path fraud named as the driving use case.
The current ads.cert page states Authenticated Connections has been "ready for adoption" since a February 2024 update. The reference implementation tells a different story: the README for IABTechLab's adscert repository says outright that it is "a proof of concept and not meant for use in its current form." A standard can be declared ready and still ship only a reference library that its own maintainers say not to run in production. That is where ads.cert sits in 2026: published, not withdrawn, not obviously dead, and not something we found running at scale.
The more telling signal is what is missing. IAB Tech Lab's 2025 technical standards roadmap lists roughly 31 planned specifications and updates for the year: CTV ad formats, Global Privacy Platform work, live-stream RTB signaling, AI crawler access controls, a conversion API. Neither OpenRTB 3.0 nor ads.cert appears in it. That is not proof the programs are dead, but a standards body does not usually omit something it considers a current priority from its own annual roadmap.
Why 2.x absorbed the pressure to move
The mechanism is a versioning policy change, not industry inertia alone. Since the 2.6-202211 update (November 2022), IAB Tech Lab ships the 2.x line on a monthly, dated-snapshot cadence and only bumps the version number on a breaking change. Everything else, new fields, new objects, new enumerated values, lands as a same-version dated release: 2.6-202303, 2.6-202402, 2.6-202501, and on. See OpenRTB versions for the tracked list.
That policy removed the main argument for jumping to 3.0. GPP consent signaling, DOOH context objects, CTV pod bidding, and structured user-agent fields (replacing the freeform UA string) all shipped as 2.6 dated updates rather than waiting on a major version. If your integration only needs new capability, not a new architecture, 2.6 keeps giving you the capability without asking you to run a second parser. 3.0's case was partly architectural cleanliness and partly ads.cert; neither outweighed the cost of a non-backward-compatible dual stack for most buy- and sell-side teams.
What 3.0 already gives you, even if you never touch it
Two pieces of the 3.0-era work made it into 2.6 without anyone adopting the 3.0 envelope. First, AdCOM 1.0, the domain object model built for 3.0, is where 2.6's enumerated lists actually live now: device types, placement subtypes, API frameworks, creative attributes. The AdCOM repository is still actively maintained on the same dated-snapshot pattern as OpenRTB itself, because 2.6 depends on it. Second, no-bid and loss reason codes used across 2.6 responses are maintained in the OpenRTB 3.0 document itself. If you have ever looked up a loss reason code, you were reading a 3.0 artifact while running a 2.6 integration.
What would actually have to change
Architectural elegance did not move the industry in 2018 and will not move it in 2026. Two things plausibly could. One: fraud or compliance pressure serious enough that cryptographic request signing stops being optional, a regulator or a major buyer mandating verifiable request provenance rather than trusting ads.txt and SupplyChain declarations. Two: a closed or high-value vertical, a walled CTV ecosystem or a DOOH network with a small, motivated set of counterparties, deciding the dual-stack migration cost is worth it because everyone in that vertical can move together. Absent one of those, the cost-benefit math that has held since 2018 still holds.
What to check this week
If you integrate programmatic bid requests, do not build speculative OpenRTB 3.0 or ads.cert support. Build it when a specific partner requires it, not before. What is worth doing now: confirm which 2.6 dated snapshot your exchange or DSP actually targets, since fields move between snapshots, and validate against that exact one in the bid request tester or the rtblint CLI in CI. rtblint validates OpenRTB 2.6 bid requests, with the richest rule coverage on tracked 2.6 snapshots through 2.6-202505. It carries object catalogs for 2.0 through 3.0 for field-level checks, but full 3.0 rule depth and bid response validation are not there yet, and rtblint is not an IAB Tech Lab product. If a partner hands you a native 3.0 Openrtb envelope, that is the trigger to build for it, not a roadmap item to get ahead of.