For years, a large part of advertising in CTV has rested on an uncomfortable paradox. Inventory is presented as premium, yet a significant part of the technical trust in the environment still relied on declared signals: device metadata, user agent, app context, and other useful fields that are also susceptible to manipulation. In October 2025, IAB Tech Lab launched support for Device Attestation within OM SDK precisely to reinforce that layer of trust, with initial compatibility for Apple and Fire TV devices.
The change does not involve adding another advertising or opening a new tracking path. What changes is the type of truth measurement can rely on. According to the , in this context a device attestation is a statement made by the device manufacturer that the device is authentic, rather than a simple self-assertion by the device itself or the software running on it. That nuance is decisive: the signal stops being merely declarative and instead becomes supported by an external verification mechanism.
The IAB Tech Lab document starts from a very specific observation: both bid requests and measurement beacons carry device information used to make campaign decisions, classify inventory, and measure results, but that information usually travels as text and can therefore be altered. The guide identifies this vector as device spoofing and places it within the Invalid Traffic (IVT) frameworks that the industry is trying to detect and filter. Put simply, an impression may appear to come from a real television, even when the underlying environment is not.
That is the real value of Device Attestation: it does not seek only to detect inconsistencies, but to create a positive signal of authenticity. The IAB Tech Lab launch note itself describes it this way, and supported the capability because it can strengthen IVT detection and improve confidence that the measured impression is occurring on the type of device the inventory claims it is.
Why does this capability live within OM SDK?
OM SDK was already the standard measurement layer for impression, viewability, and verification in CTV and video, and the official IAB Tech Lab page itself defines it as a common foundation so that apps, players, and measurement vendors do not have to solve every integration in a proprietary way. In CTV, that standardization is especially important because it reduces differences between platforms and normalizes access to measurement signals. Device Attestation fits naturally into that framework: it is not a targeting technology, but rather an additional signal within the measurement context.
The guide is explicit on this point: the mechanism operates purely within the measurement context, does not depend on user identity, and is not designed to become a persistent device identifier. That technical decision is very important. It makes it possible to reinforce the authenticity of the environment without turning the system into a new tracking tool.
The most serious aspect of the design lies in its security foundation. The implementation guide explains that, for the system to be robust, the attestation must rely on a hardware-backed root of trust, normally associated with a device-specific private key. It also adds that the protocol between the client and the attester should not allow an emulator to obtain a validation equivalent to that of a genuine physical device. In other words, the goal is not to verify whether the device “looks like” a television, but whether it can cryptographically prove that it is an authentic device recognized as such.
That point marks a huge difference compared to many previous practices across the ecosystem. Until now, part of the industry inferred the quality of the environment from patterns, rules, or anomalies. With Device Attestation, verification begins to rely on a stronger proof, anchored in the device platform itself. That does not eliminate all fraud, but it does harden one of the weakest layers of the CTV stack.
To solve this verification problem without turning it into a new form of persistent tracking, IAB Tech Lab adopts Privacy Pass, an IETF architecture designed for privacy-preserving authentication. RFC 9576 describes Privacy Pass as a framework for proving client properties without revealing more information than necessary, and RFC 9577 defines the associated HTTP scheme for token redemption. OM SDK adapts that approach to the advertising and measurement use case.
The choice is not a minor one. It means the industry has not opted for an additional identifier, but for a controlled proof system. The objective is not to know who the user is, but to better know whether the device claiming the premium impression is authentic. In the current regulatory and privacy context, that is probably the only reasonable way to reinforce inventory authenticity without opening another front.
How does the architecture actually work?
The guide describes four main roles: Client, Verifier, Attester, and Issuer. The client is the app or video player running the ad; the verifier is usually a measurement or verification company, although other actors in the chain could also play that role; the attester is the device manufacturer; and the issuer sends out tokens only after validating the attester’s attestation mechanism. In certain deployments, verifier and issuer may be the same entity.
The flow begins when a creative containing a verification script is delivered to the player. That script contains the verifier URL and passes it to OM SDK through an Attest API-type call. From that point on, the SDK manages the subsequent client-side logic. If applicable, OM SDK sends an Attestation Request; the verifier may then respond with a challenge; the client obtains the proof through the mechanism supported by the attestation ecosystem; and finally the verifier validates the token and aggregates the resulting signal. All of this happens within the measurement framework, not as an independent identity transaction.
One of the system’s strengths is that it does not attempt to verify every impression. The guide establishes that attestation should operate with sampling, both to protect resources and to avoid degrading the user experience. OM SDK sends requests with a predefined probability and, in addition, each verifier can decide which ones to respond to with a challenge based on its own logic or the available context.
That turns Device Attestation into a statistical and aggregated trust signal, not a binary decision key for individual impressions. The guide insists that the goal is to build trust at the seller level and across sliding data windows, not to pursue exhaustive validation of every session. Technically, this approach makes a great deal of sense: it reduces cost, avoids rigidity, and makes it harder for the system to become fragile due to unrealistic expectations of total coverage.
IAB Tech Lab makes it clear that Device Attestation cannot be used as an exclusionary criterion. It should not be used as a mandatory requirement to accept or reject individual impressions, it should not run pre-bid, and the absence of a token should not automatically be assumed to mean fraud. It also recognizes that there may be legitimate reasons why a challenge does not end in successful verification, such as rate limiting, temporary unavailability of the attester or issuer, expiration, or simply sampling decisions.
This point is key because it prevents a misinterpretation of the standard. The value of the signal does not lie in blocking inventory by default, but in detecting persistent patterns. If a seller shows anomalous behavior compared to its usual behavior, then the signal starts to become truly useful. Properly understood, Device Attestation is not a switch; it is a new layer of evidence.
From a practical standpoint, the first requirement is that the app or player integrates OM SDK 1.6 or higher in order to be considered compatible with this capability. The guide also explains how to audit that eligibility during sessionStart, by reviewing library version fields or the OM service version depending on the type of integration.
The second point is understanding the difference between general OM SDK coverage and specific Device Attestation support. OM SDK already covers environments such as tvOS, Android TV, and, through OM Web Video, Samsung and LG TV; however, Device Attestation was initially launched for Apple devices and Fire TV. That means deployment should be approached as a progressive stack capability, not as a universal checkbox available overnight.
The third point is that the session can expose from the start which attestation mechanisms it supports. The guide shows examples such as FireTVFOSDAT on Fire TV and ApplePAT on Apple environments. From a product perspective, this is very useful because it makes visible and auditable a capability that did not previously exist: the app no longer only declares which measurement SDK it uses, but also whether the session is technically capable of participating in this new authenticity model.
IAB Tech Lab does not leave this capability at a simple “there is a token or there is not.” The guide proposes specific metrics such as Attestation Eligible Impressions, Attestation Attempted Rate, Attested Impression Rate, and Error Rate. The first defines the compatible universe; the second helps detect possible signal suppression; the third measures the proportion of successful verifications over issued challenges; and the fourth helps distinguish operational failures from real authenticity issues.
The operational interpretation of these metrics is especially powerful. If a seller shows an abnormally low Attempted Rate compared to its usual behavior, there may be signal suppression or implementation problems. If what declines is the Attested Impression Rate, the guide suggests that this may indicate device spoofing or other failures preventing the attestation from being completed. In other words, the system not only adds a new signal; it adds a much more refined way of distinguishing between coverage, errors, and real authenticity.
Why does this truly matter for CTV?
The reason Device Attestation deserves attention is not just anti-fraud. It is also a matter of product and supply quality. IAB Tech Lab presents OM SDK as the only measurement foundation supported by native device signals rather than merely inferred data, and its message to the market is quite clear: as adoption grows, buyers, sellers, and verification companies will be better able to distinguish trustworthy inventory from inventory that is not.
That could eventually have fairly broad implications. Not because Device Attestation alone solves every problem in CTV, it does not fix a poorly populated schain, correct defective bundles, or replace other verification layers, but because it addresses a particularly sensitive weakness: the ease with which inventory could appear premium without strong proof of the underlying device. In an ecosystem where technical trust increasingly determines the quality of spend, that change carries significant weight.
Device Attestation in OM SDK does not try to know more about the user. It tries to know better whether the device claiming a premium impression is really who it says it is. And in CTV, where the distance between a genuinely premium environment and one that is only apparently premium can cost a great deal of money, that is not a minor improvement. It is a new layer of technical truth.
At tvads we has a professional team able to advise you on this field and and guide you in any area of your streaming advertising business, advising you or even operating it on your behalf if necessary
All author posts