Findings

What we were doing

Three more Android handsets through the app, in the run up to putting it on the store. Two were accepted. The third never got as far as a verdict about its hardware.

What we found

The server answered verified: false with one reason: cert chain order: android: ambiguous chain order (2 candidate leaves). Nothing about the boot state, nothing about the keystore, nothing about the patch level. The evidence was turned away before any of that was read, because the set of certificates it arrived in had two certificates that issue nothing else in the set.

What it changed

Nothing, and that is the point of publishing it. The code finds the end of a chain by asking which certificate issues none of the others. One such certificate means one answer. Two means the chain has two ends, and the attested key could be either of them. We could pick the first, or the one that verifies, or the one that looks right. Every one of those hands the choice to whoever supplied the chain, and the thing being chosen is which key the whole report is about. So the function stops and says so, and this is the first time a real device has made it stop.

What it does not mean

It is not a verdict on the phone. The handset may be in perfect order; what it sent was a certificate set we could not read unambiguously, and those are different sentences. It is also not a claim that the device did anything wrong, because an extra certificate in a chain is usually an accident of how it was assembled rather than an attack. What it means is that a verifier which guesses at the leaf is a verifier an attacker can aim, and ours would rather hand back a refusal somebody has to read than a verdict nobody can trust.

What we were doing

A Pixel 7 Pro attested for the first time. Twenty one claims came back, and three of them had never appeared on this site.

What we found

android.boot_key_device read Google Pixel 7 Pro. android.boot_key_device_agrees read true, meaning the model the key was published for and the model the device signed are the same model. android.boot_key_source named the list those digests came from. And os.distribution read stock, where every Android device on this page before it read stock-unlisted.

What it changed

It corrected us about our own system. The entry below this one says seven stock phones attested and we could not name the boot key on a single one of them, and the honest reading at the time was that our list was thin. The list was not the problem. The digests we pin are generated from GrapheneOS’s AttestationServer at one fixed revision, and that project publishes keys for Pixels. Not one device we had tested was a Pixel. The first Pixel through the door was named on the first attempt, by a mechanism that had been working the whole time and had never been handed a device it covered.

What it does not mean

It does not mean we can name boot keys in general. Our attribution covers Pixels and stops there, so a Samsung, a Motorola or an OPPO with a locked bootloader and a passing verified boot will still come back as stock-unlisted, which says the boot chain verified against a key the device holds and that we cannot say whose key it is. The agreement between the two model fields is a useful cross check and it is not proof: both describe the same device, so they can be wrong together. And the same Pixel reported a security patch level of October 2022 on Android 13, which is forty eight months behind. An attributable boot key and a four year old patch level arrived in the same evidence, and a policy that reads the first and not the second would call this phone current.

What we were doing

Version 1.1 of our app asks for device property attestation, which is what finally lets a handset put its own brand and model into the signed evidence instead of us writing it on a card by hand. Seven Android devices attested on 13 October, and for the first time the names on this site came from the hardware.

What we found

One of them signed its model as marvel. Not a phone anybody sells, not a name on a box: a Motorola internal codename, hardware-enforced, sitting in the evidence next to a locked bootloader and a verified boot state. The brand reads motorola and the manufacturer reads motorola, both correct and both useless for telling you which device this is. The one field a reader would actually look at is the one written in a language only the factory speaks.

What it changed

It stopped us from doing the obvious thing, which was to print the attested model on a certificate and call that an improvement. A receipt reading model: marvel is worse than one reading model: not attested, because the second is honest about what is missing and the first looks like an answer. So the attested model goes on the record exactly as signed, in a monospaced font, labelled as the model the device signed, and we do not translate it. A codename table maintained by us would be a guess with our name on it, and the next device to use a new codename would read as a known model until somebody noticed.

What it does not mean

This is not a fault in the device or in Android. Codenames are what the build system knows, and the attestation is faithfully reporting the string the firmware holds. It is also not universal: the Samsung and OPPO devices in the same sweep signed SM-A176B, SM-X736B, SM-F956B and CPH2721, which are real model numbers you can look up. What it means is that an attested model is a string, not an identity, and any product that builds a rule on it has to cope with the day the string is a word like marvel.

What we were doing

After a Galaxy M32 passed our check five years out of date (A phone whose security patches stopped five years ago passed our check with a clean verdict), we added a notice that tells whoever is holding the device how stale its patches are. Then we ran seven current Android devices, partly to widen the evidence and partly to find out how often that notice would actually speak.

What we found

A Samsung tablet on the newest Android release, with StrongBox and a fully verified boot chain, reported an operating system patch level of August 2025: fourteen months behind on the day it ran. An OPPO handset reported February 2025, twenty months behind, on Android 15 while the rest of the group was on 16. A third device in the sweep carried a boot patch level of August 2023, three years and two months old. None of these is a bargain phone from a drawer. They are devices on sale now.

The same sweep closed a question the earlier Motorola prototype had opened. On that device the operating system patch level and the boot patch level were two years apart, which we published as a warning that one date is not the whole picture. On all seven of these the two dates were identical. So the gap is not a constant property of Android. It is a thing that happens on some devices, which is exactly why we show both. One does not stand in for the other.

What it changed

It moved the patch notice from a thing built for an outlier to a thing most of our evidence set would trigger. We had been thinking of it as the M32 case: an old device, an obvious warning, rare. Of the three devices whose operating system patch level we could read, two would be warned about, and all four of the others carry a boot patch level more than a year old. That changes the tone of the feature. This is no longer an alarm for the odd device. It is a routine disclosure, and it should read like one. Nobody is being accused of anything.

What it does not mean

It does not mean these devices are unsafe, and it does not mean their manufacturers are negligent. Test devices are not always updated the way a person updates a phone they carry, and we cannot tell from the evidence whether an update was available and declined or never offered. What the evidence says is the date, and the date is what we publish. We enforce no minimum, we have never claimed to, and whether fourteen months is acceptable belongs to whoever is placing the work.

What we were doing

Our verifier reads the hardware-enforced verified boot key and tries to say which operating system image signed the boot chain. That claim is called os.distribution, and a policy that refuses an unattributable operating system reads on it. We had built it, tested it against a known key, and never run it across a group of ordinary retail handsets.

What we found

Every device in the sweep that reported the claim reported the same value: stock-unlisted. A Motorola, three Samsungs and an OPPO, all with locked bootloaders, all with verified boot passing, all signed by a key our list has never heard of. The claim worked perfectly and told us nothing, five times out of five.

What it changed

It told us the honest size of our own list, which was smaller than the feature implied. stock-unlisted is a deliberate value and we are glad it exists: it says the boot chain verified against a key the device holds, and that we cannot attribute that key to a named image. That is a true and useful sentence. But a claim whose only observed value is we do not know is a claim a customer should not be sold as attribution yet, and the wording wherever it appears has to make the difference between stock, named and stock, unlisted impossible to miss.

It also set the work. Every manufacturer signs its stock images with its own keys, and the digests are observable: we have five of them now, from five devices whose brand and model are in the same evidence. The list grows one measured device at a time, and nothing goes in it that we have not seen signed. A list of keys copied from somewhere else would be worse than an empty one, because a wrong attribution is a sentence we would be putting our name to about somebody else's phone.

What it does not mean

It does not mean these devices were running modified software. Every one of them reported a locked bootloader and a verified boot state, both hardware-enforced, which is the part that actually protects anything. Unlisted is a gap in our records, not a finding about the device. It also does not mean the claim is useless: the day a device reports a key we can name, or a self-signed key we definitely cannot trust, this is the field that says so, and it will say it correctly because it has been honest about the easy cases.

What we were doing

Working through Android handsets to widen the evidence set beyond current flagships. Most devices we had examined were recent. We wanted one that was not.

What we found

A Samsung Galaxy M32 attested and was accepted. Fourteen claims, eleven of them hardware-enforced, a locked bootloader, a verified boot state, a hardware-backed key in a trusted execution environment, and a signing certificate matching the one this coordinator pins. On every question the attestation is asked, it answers correctly. And then it reports a security patch level of 2021-11-01 and an operating system version of 11.0.0.

Five years of security patches, missing, on a device that verifies. For comparison, in the same evidence set a Pixel 8 reports October 2023 and the newest handset we have checked reports June 2026. The verdict on all three is the same word.

What it changed

It gave us the device this research had been missing. Every Android result we held was a pass or a refusal on structural grounds; none of them was a device that ought to worry somebody. This one is, and it is why we publish the claims and not a score. A reader can see os.patch_level = 2021-11 and decide. A reader handed the word verified and nothing else cannot.

It also settled a question we had been carrying about our own product. We enforce no minimum patch level, and we never said we did. But a customer could reasonably assume that a service selling verification would refuse a phone five years out of date. It does not, because that is a policy decision belonging to whoever is placing the work, and because a floor we invented would be wrong for somebody. What follows from this device is that we have to offer the choice and explain it, instead of leaving every customer to think of it unprompted.

What it does not mean

The M32 is not compromised, not rooted, and not lying. It is an ordinary handset doing exactly what it should: proving, in hardware, what it is and what state it is in. Nothing here is a fault in the device and nothing here is a fault in the attestation. The gap is between what the evidence says and what a reader assumes the word verified covers. Verified means the evidence held up. It has never meant the device is safe, it does not mean this one is current, and a product that lets those two readings blur is the thing we are arguing against.

What we were doing

Our own bar for selling against an attestation root requires four things, and one of them is a second genuine device that differs structurally from the first: a different vendor, a different chip class, or a certificate chain of a different depth. One device that passes proves a verifier can say yes. It proves nothing about whether it can say no. For Apple we had written that the structural difference would come from iOS 27, which adds two fields to the signed data describing how the application was distributed.

What we found

Two different models on iOS 27.0 produced no trace of either field, and so did an iPhone on iOS 17.0. Our verifier parses those fields, treats their absence as normal, not as failure, and was right to: there was nothing to parse. Six models and seven runs, phones and a tablet, produced one evidence shape. So the difference we were looking for is not something a device carries. It is something the build carries, and our build was compiled against an earlier SDK than the one those fields arrive with.

What it changed

It changed what we are willing to count. A seventh, eighth or tenth device would have produced a longer list and the same single data point, and a count of devices is exactly the thing our own bar was rewritten to stop rewarding. The Apple root stays unsold until the bar is met, which is where it has been since the first iPhone attested on 2 October, and what meets it is a rebuild, not a purchase.

What it does not mean

The six attestations are not wasted and they are not a negative result. They are the measurement behind We ran five iPhones across ten iOS releases and the evidence could not tell them apart, and they are the first evidence we hold that this root behaves identically across four major OS versions, five phone chassis and a tablet, which is worth knowing on its own. What they are not is a second structurally different case, and saying so costs us nothing, where counting five handsets as five kinds of proof would cost a reader everything they came here for.

What we were doing

Apple App Attest publishes no operating system version. We have written that on this site for weeks, taken from Apple’s documentation, and documentation is not a measurement. So we took six Apple devices and attested each one: an iPhone 12 on iOS 17.0, an iPhone Air on iOS 26.0, an iPhone 17e on iOS 26.4, an iPhone 16 Pro Max on iOS 27.0, an iPhone 18 Pro Max on iOS 27.0 twice from two separate instances, and an iPad Pro 13.

What we found

Seven attestations. Every one accepted. Every one carrying exactly four hardware-backed claims: the application identity, the distribution environment, the key security level, and the workload identity. Ten major iOS releases between the oldest device and the newest, a tablet among the phones, and the evidence is the same shape in all seven cases. Nothing in any of them says iOS 17, or iOS 27, or iPad. The claim sets are interchangeable.

What it changed

It moved a sentence we had been quoting into a sentence we have measured. A customer asking whether SEVEN KG can tell them that an Apple device is patched now has an answer with seven attestations behind it, not a citation. On that question Apple is strictly weaker than Android, where a handset reports its verified boot state, its OS version and its security patch level, and where we have published a device running a patch level nearly three years behind another checked the same day. Our verifier has said so in its own source comments since September; now the page says it with a measurement attached.

What it does not mean

Nothing here is a fault in these devices, and nothing here is a fault in App Attest. App Attest answers one question extremely well, which is whether a genuine, named application is running on genuine Apple hardware with a key in the Secure Enclave, and all six proved exactly that. What it does not do is describe the operating system underneath. A jailbroken iPhone and a clean one are not distinguished in this evidence, and neither is a current device from one several releases behind. If your policy needs the state of the operating system, this root cannot give it to you, and no newer handset will change that.

What we were doing

Publishing counts beside each refusal reason and each device row for the first time, and reading them back the way a stranger would.

What we found

Every count on these pages answers how many times the coordinator observed that thing. It does not answer how many machines were involved, and the two are not the same number. One handset attesting three times contributes three. Three handsets attesting once each also contribute three. Nothing on this page distinguishes those two situations, and nothing can, because the row that would tell them apart is a per-device identifier and we do not publish those.

Our own refusal list makes the point better than any explanation of ours could. One reason reads cert chain: x509: malformed extension critical field, seen three times. That was not three faulty phones. It was our certificate parser rejecting a legal encoding, written up in Refused over one byte. One defect of ours, met by some number of genuine handsets we cannot recover from this page. Another reads UnknownPackage, seen twice, while An app with no signature describes that as a single unit. Both statements are true at the same time, and if you read the 2 as two handsets you have learned something we never told you.

One more gap, stated because it is visible to anyone who adds up: seventeen attestations were refused and sixteen refusals carry a published reason. The missing one is a value still awaiting review. Nothing is hidden. The value is unapproved, which on this site is a different thing, and we count it separately.

What it changed

Nothing in the data. It changed what the counts are called and what we will say about them when asked. A reader who treats times seen as a fleet size will over-read every figure here, and that misreading flatters us, it does not harm us, which is exactly why it needs writing down.

What it does not mean

It does not mean the counts are meaningless. They are honest observation totals and they move only when something real happens. It means they are a floor on activity and not a census of hardware. If you need a device count, ask us and we will tell you what we actually hold. A table should not have to imply it.

What we were doing

Approving the values that had queued up for review, after changing the app so a handset would attest its own brand and model. A phone will not tell you what it is unless you ask explains that change. This is what it produced.

What we found

A Google Pixel 11 Pro now appears on the hardware page under a name it signed itself. Not a name we typed next to it. device.manufacturer, device.brand and device.model all arrived inside the attestation, marked as hardware sourced, alongside seven claims in total and four separate statements of what the evidence does not prove.

The rows around it that carry no model will stay that way, and that is permanent. They are attestations collected before the app asked. A brand and a model are only inside an attestation if the key requested them at the moment it was created, and a past attestation cannot be reopened and asked again. Those devices would have to attest afresh. We are not going to label them from our notes and present that as evidence, which is the whole reason the hand recorded cards on that page sit in their own section under their own heading.

And the named row still does not say much. Its key security level, its operating system version and its patch month are all absent, because those particular values are still in review, with 310 values unapproved across the service. The name arrived. The detail beside it has not been released. A row that names a device and reports nothing about its state is worth less than it looks, and publishing it in that condition beats waiting and presenting it as complete.

What it changed

The generated section of the hardware page can now carry a device identity that came out of hardware and not out of a person. Everything hand recorded stays labelled as hand recorded. The two will never be mixed into one section.

What it does not mean

It does not mean we can recognise that handset again. The name describes a model thousands of people own and nothing in it is unique to one unit. It does not mean the device is current, safe or suitable either. A verified attestation with no patch level published tells you that a real Pixel 11 Pro signed a challenge, and that is the end of what it tells you. Naming a device is the smallest claim on this page, and it took a code change on our side to earn even that.

What we were doing

Finding Which device produced it on this page has said since September that most Android attestations do not say which device produced them. We had taken that for a property of Android. It is not. It is a property of how the asking app is written, and this entry is us correcting our own earlier one.

What we found

Android will put the handset’s brand, manufacturer and model inside the signed attestation, but only if the app asks for them at the moment it creates the key. Ours never asked. So thirty attestations arrived from eight different handsets across six brands with all three fields empty, and our own published table called every one of them an unnamed device. The evidence was never missing. It was never requested.

We changed the app to ask, and a Google Pixel 11 Pro came back with device.manufacturer = Google, device.brand = google and device.model = Pixel 11 Pro, each one marked as hardware sourced, not reported by software. The phone’s secure element had signed its own name.

Asking is not free, and this is the part worth knowing if you ever build one of these. Google’s own specification is blunt about it. On a device that does not support identifier attestation, or one where that capability was permanently destroyed, a request including those fields fails the entire attestation. Not the name. Everything. A naive change here would have cost us devices we already verify correctly, in exchange for a label.

So the app now tries four combinations in a fixed order and takes the first that works, and the order is the whole point. A handset with a dedicated secure element but no identifier attestation keeps the secure element and loses the name, never the other way round. Key security is evidence. A name is a label. We do not trade the first for the second.

What it changed

Our published hardware table can now name a handset from signed evidence instead of from a line somebody typed. Everything above that section was written by hand and is marked as such. Everything the generated section says about a device from here on came out of the device.

It also changed what Which device produced it means. The claim there was accurate about what we observed and wrong about why, and leaving it uncorrected would have been the comfortable option.

What it does not mean

It does not mean every phone will name itself. A device that cannot attest its properties still reports nothing, and we designed for that outcome. Nothing failed. It does not hand us a serial number, an IMEI or any other per handset identifier either. Those live behind permissions a Play Store app cannot hold, we do not request them, and our publication rules exclude that whole class by name. A brand and a model describe a class of hardware that thousands of people own.

What we were doing

Counting. We were not testing anything in particular, just reading our own published figures back and asking what they say about the service, not about any one device.

What we found

Across every Android attestation this coordinator has verified and published, eighteen were accepted and twelve were refused. Counting all six evidence types together, forty-one attestations reached it. Twenty-four were accepted. Seventeen were not.

The refusal rate is the figure we never expected to be publishing, and it is the one we most want a prospective customer to look at. A verifier that accepts everything is a verifier that checks nothing. Two in five is not a sign the service is unreliable. It is the only evidence available that the service is doing anything at all.

Four distinct refusal reasons sat published beside the devices, and not one of them was exotic. A certificate the coordinator does not accept. An application it does not recognise. A confidential machine whose report arrived empty. Each is a sentence a person can read and act on, which is deliberate, because a refusal nobody can diagnose costs a second trip to hardware that may no longer be available.

What it changed

Nothing in the code. It changed what we put first when we describe the service. The interesting figure was never how many devices passed.

What it does not mean

This is not a failure rate for Android handsets in the field, and nobody should read it as one. Our sample is deliberately adversarial. Test handsets, fixtures we broke on purpose, our own development machines, and a handful of attestations made for no reason other than to see what a refusal looks like. A fleet of ordinary phones in ordinary condition would not refuse at anything close to this rate. The figure describes what we pointed at the verifier, not what the world contains.

What we were doing

Deciding, on 3 October, which of eighty-four candidate strings were honest enough to publish. Three of them were the words our verifiers use for how well a key is held: strongbox, tee and secure-enclave.

What we found

They are not three rungs of one ladder, and putting them in a single column invites exactly that reading. strongbox is Android’s name for a separate tamper resistant chip. tee is Android’s name for a protected mode of the main processor. secure-enclave is Apple’s name for its own separate chip, and it is not a synonym for either Android word. It is a different vendor’s design, with a different threat model and a different set of published guarantees.

The comparison that actually helps turned out to be the one sitting right beside them. All three of those words, across Android and Apple alike, produce the same isolation description: key-custody-only. The hardware holds a key and will sign with it. The hardware does not run the work. A dedicated security chip and a protected processor mode differ in how hard the key is to get out, and not at all in whether your workload was isolated from the owner of the machine.

What it changed

We kept all three vendor words instead of flattening them onto a tidy high, medium and low scale of our own invention, because that scale would be ours and not theirs. A policy may require strongbox and refuse tee, and that is a decision for the person writing the policy, with the vendor’s documentation open in front of them.

And key-custody-only stays on every row it applies to. That line is what stops a key holding chip being read as a confidential computer.

What it does not mean

It does not mean the three are equivalent, or that the choice between them does not matter. It means we will not rank them on your behalf. Anyone offering a clean ordering across two vendors’ silicon is asserting something neither vendor publishes.

What we were doing

Working through the publication queue on 3 October. Eighty-four strings, each one waiting on a decision about whether it could appear on a public page. Thirty-seven were claim names, which is the vocabulary of what a certificate is able to report. Things like tpm.pcr_digest, boot.key_digest, nitro.module_id.

What we found

Several of those names describe values that would identify one specific machine for as long as it exists. A TPM platform register digest. The digest of the key a phone’s bootloader was checked against. An enclave’s module identifier. Our own privacy commitment forbids publishing any of them, and someone working through eighty-four strings at a single sitting is exactly the circumstance where one slips past.

Not one of their values was in the queue. It held names, and had never once been offered the contents. We checked. We did not assume. The export publishes a claim’s name and a count of how many devices carried it, while a claim’s value has to clear a separate list, and the three identifier bearing claims are kept off that list by name, each with its reason written beside it.

So the commitment was being kept by the shape of the system and not by anyone remembering to keep it. A policy asks people to be careful. A guard does not need them to be. We are reporting this as something we discovered about our own design, not something we planned, because we went looking after the fact instead of before.

What it changed

It changed how we write the next one. The reason each excluded claim is excluded now sits in the source right beside the exclusion, so the next person widening that list reads the argument instead of working it out again from scratch. An earlier version of the same list quietly left out a GPU’s model number, a part number thousands of cards share, which is not an identifier, and every published device row read as unnamed for days because of it. A list is worth no more than the reasons written next to it.

What it does not mean

It does not mean a digest can never be published. A hash of something a thousand machines share is a fact about a model. A hash unique to one machine is a name for that machine, whatever the field happens to be called. The distinction lives at the level of the value and not the claim, so we settle it one value at a time, in public, and the refusals go on the record alongside the approvals.

What we were doing

One phone of each major brand, with our attestation app installed on each from the Google Play Store, and watching what real hardware reports, not what the specification says it should. Eight phones across six brands passed. Two did not, and the two taught us more than the eight.

What we found

A Google Pixel 6 was refused, with a message naming the calling application as UnknownPackage. Every attestation carries the package name of the app that asked for the key, along with the digests of the certificates that signed it, and the phone is the one asserting both. This one named a package we have never shipped, and listed no signing certificates at all. Not a wrong one. None.

We could not say that at first, because our own refusal message named only the package. Being unable to answer a question we had just asked is itself a defect, so the verifier was changed to print the certificate digests it had actually seen. The second run printed the empty list, and that is how we know it is empty and not merely unrecognised.

The same app, installed the same way, produced a flawless attestation on a Pixel 8 and again on a Pixel 11 Pro. So this is not a property of Pixels, and not a property of older Android versions, and we are not going to pretend we know what it is.

What it changed

Nothing about the verdict. The phone was refused and refusing it was correct. An attestation that cannot name the application it came from cannot be used to identify that application, which is the entire purpose of the field. A device presenting no signing certificate is not a device we can tie to our app.

What changed is how much a refusal tells you. Both application checks now print the certificates they observed, because a refusal nobody can diagnose costs a second run on hardware that may not be there any more.

What it does not mean

It does not mean the phone was tampered with. We have no evidence of that and we are not implying it. Test devices are reset between sessions, and the fault may well lie in how this unit was prepared and not in the hardware.

What it does mean is that we will not guess. One unit, unexplained, published as unexplained. If we find the cause we will say so here, and if the cause turns out to be ours we will say that too.

What we were doing

The same run of phones. A OnePlus 15R on Android 16, key generated in StrongBox, which is a separate security chip and the strongest hardware backing Android offers.

What we found

We refused it. The whole certificate chain failed to parse, so not one of our checks ever got to run.

Inside a certificate, every extension carries a flag marking it critical. The strict encoding rules say true must be written as the byte 0xff. The older, looser rules allow any non-zero byte, and this phone writes 0x01. Our language’s certificate parser accepts only the strict spelling and throws the certificate out.

The phone was telling the truth about itself and we could not read the sentence. Oppo, the sibling brand, on near identical silicon, had passed cleanly minutes earlier. So this is one vendor’s encoder. It is not a family trait.

What it changed

We now accept that one byte and nothing else. The tolerance applies to that single flag, only after the strict parser has already refused the certificate for that exact reason, and every other malformation is refused exactly as before.

The signature is still checked against the bytes the phone actually signed. That phone signed a statement containing 0x01. Rewrite the byte to tidy it up, then check the signature against the tidied version, and you have verified nothing whatsoever. So the corrected copy is used only to read the fields, and the original bytes are what the signature is tested against. That one distinction is the entire safety of the change, and it is the part a careless version gets wrong.

An appraisal from one of these devices now says so, in the list of what the proof does not establish. A customer seeing that their hardware encodes certificates out of spec is better served than a customer whose hardware was quietly treated as identical to hardware that does not.

What it does not mean

None of this means the chain is checked less carefully. It must still reach Google’s attestation root, every signature must still verify, and the device must still be a genuine unit with a locked bootloader.

Nor does it mean we would read an unrecognised value as false. Critical means a reader has to understand the extension, so reading an unexpected byte as true is the cautious direction and reading it as false is the dangerous one. We read it as true.

What we were doing

Eight NVIDIA H100s, to test the one thing we had never been able to test: that when a node presents several GPUs at once, the proof ties all of them to the same machine. With a single GPU that check is satisfied trivially and proves almost nothing.

What we found

The multi-GPU part worked. All eight GPUs were tied to a single processor proof. Reorder two of them and it breaks. Remove one and it breaks. That is what we went there to find out.

We also found two readings on the same machine that looked like they contradicted each other:

CC State                   : OFF
Multi-GPU Mode             : Protected PCIe
GPU CC Capabilities        : CC Capable

Read on its own, the first line says the GPUs are not protecting anything. We did not publish a conclusion from it. We asked the provider whether that reading was expected on that configuration, and told them we would publish whatever they said.

They answered the same day. The first line is how Protected PCIe reports itself, and the second line is the one that actually describes the machine. An eight GPU node runs Protected PCIe, and the vendor’s diagnostic prints OFF for the single GPU setting that no longer applies to it. A single GPU instance in the same family prints ON, which is exactly what makes the first line look so decisive.

Their published evidence for that instance type, dated three weeks before our test, says the same thing, and it carries NVIDIA’s own attestation service verifying all eight GPUs against a fresh challenge and both firmware manifests. The machine was protected.

Our own evidence agreed. Every one of the eight signed reports stated the mode explicitly, in a field our verifier was not reading.

What it changed

The verifier now takes the mode from the signed report and ignores anything the host says about itself. Where a GPU’s firmware is too old to state a mode, the bundle still verifies but makes no claim about protection, so a customer asking for a protected GPU cannot be matched to that machine. The gap is named in writing and enforced by the absence of the claim.

Worth reporting on its own. Our verifier called that node verified and the answer was correct, but it never asked about protection, so it would have given the same answer on a machine that genuinely had none. An answer that happens to be right without being checked is not a verification.

The same work turned up a second limit, and this one nobody can engineer around. The switch fabric cannot be attested from inside a guest at all. The evidence is collected through a host side interface that a virtual machine does not have. What a GPU signs is its own account of which switches it is attached to, which is the GPU speaking for its neighbours, and not the neighbours speaking for themselves. We record it and we say so.

The provider is updating their instance page to state the reading. We would never have known to ask if their own documentation had not told customers to run that check in the first place.

What it does not mean

It does not mean anything was misconfigured or misrepresented. The GPUs were real, the binding across them held, the processor enclave was real, and the protection was on.

It does not mean that reading is always benign either. On a single GPU, CC State: OFF means exactly what it says, and on that hardware it is a reason to stop. The mode line is what tells the two cases apart.

And it does not mean we now detect everything. Protection across a switch fabric cannot be verified from a guest by anyone, ourselves included, and a GPU whose firmware predates the mode field tells us nothing about it. We say that instead of assuming the flattering answer.

What we were doing

Closing out a hardware test from five days earlier. On 25 September we collected attestation evidence from an NVIDIA RTX PRO 6000 Blackwell Server Edition running inside an Intel TDX confidential VM. The collector deliberately captured a CPU quote bound to the exact bytes of the GPU evidence, so the combined check could be run later without paying to rent the machine twice.

We also fetched the two reference manifests NVIDIA publishes for that exact driver and VBIOS. Those are the signed documents that say which firmware measurements are the approved ones.

What we found

The combined proof works. The processor’s sealed data matched, byte for byte, what our own code computes from the GPU evidence. Change a single bit of that evidence and it breaks. The whole design rests on that property, because it is what stops a genuine GPU report from one machine being presented under a genuine processor report from another. That result stands unchanged.

Then the firmware comparison disagreed, and we published that too. We reported that 36 of 64 measurements did not match the approved values, that one measurement the manifest described was not reported at all, and that 27 matched. We listed four ordinary explanations we had ruled out, and said we did not yet know which of the ones left standing was true.

One of the explanations we ruled out was misaligned numbering. We dismissed it in a single sentence: 27 measurements do match, and a shifted index would match almost none.

It was misaligned numbering. The protocol the GPU speaks numbers its measurements from one. The manifests number theirs from zero. We were not correcting for the difference, so every measurement was being compared against its neighbour. The vendor’s own software handles this correctly in a single line, which we had read and not noticed.

With the numbering corrected, against the same evidence and the same manifests:

41 of 41 approved measurements match
 0 mismatches
 0 not reported

The firmware was correct the entire time.

The sentence that dismissed the real cause was wrong twice over. Twenty-seven measurements did not match. Four did. And there are 41 approved measurements, not 64, because the 27 came from subtracting one number from another instead of counting anything. A number nobody had counted kept the true explanation off the table for three weeks.

The symptom that should have given it away was sitting in the same output we published. One measurement in the manifest that the GPU had not reported, at index zero. A report that numbers from one has no index zero, and never will.

What it changed

The comparison is fixed, and the correction is pinned by a test that runs against real published evidence.

The more useful finding is why nothing caught it. Every test we had written for this comparison asserted a refusal. A tampered manifest. An expired one. A manifest for the wrong firmware. Malformed documents. All of them passed. Not one of them asserted that a correct report matches a correct manifest, so every test was passing for precisely the same reason the feature was broken.

A suite made only of refusals cannot notice a component that always refuses. Three of the fixtures had the fault written into them, because they had been built to match our code instead of the protocol.

There is a quieter consequence worth saying out loud. Under the old numbering, a correct manifest and a manifest for completely different firmware both scored zero matches. The comparison could not tell those two apart, which means it was never measuring anything at all, and no GPU could ever have been reported as running approved firmware.

What it does not mean

It does not mean the hardware was ever at fault, and it does not mean NVIDIA published anything wrong. Both were correct. Our arithmetic was not. We said at the time that we did not know which explanation was true, and that saying so beat picking the flattering one. That was right, and the answer turned out to be the least flattering one on the list.

It does not mean the rest of the comparison is now proven. It means the comparison can finally succeed, and that one machine’s firmware does. Confidential GPU nodes stay switched off here for the reasons given elsewhere, and none of those reasons was this.

We had been here before, five days earlier, when the same hardware refused to verify at all until we found that this generation stores one certificate field a level deeper than every chip we had tested. That one was the vendor’s format and we adapted to it. This one was ours from the first line.

What we were doing

Finishing the STMicroelectronics work from the entry below this one. We pinned the STM certificate and not the GlobalSign anchor sitting above it, because the STM certificate is the highest point in the chain that is unambiguously STMicroelectronics. Anchoring at GlobalSign would have let every manufacturer in that programme into our trust base under one vendor’s label. Then we put a real ST33HTPHAHE4 in front of it.

What we found

It verified. It also volunteered something we had not asked about:

pinned root STM TPM EK Root CA expires 2039-12-31,
before this endorsement certificate expires 9999-12-31;
path validation will begin failing at the earlier date

The chip’s endorsement certificate declares itself valid until 31 December 9999. That is not a defect. A TPM’s endorsement key is meant to last as long as the silicon does, and a vendor writing forever is being honest about the intent. The root it chains to expires in 2039.

So the certificate outlives its own trust path by roughly eight thousand years. On 1 January 2040 every one of these chips is holding a certificate that is valid on its face and unverifiable in practice. Nothing will have been revoked, compromised or altered. The paper above it will simply have run out.

What it changed

Nothing yet, and we are saying that out loud instead of leaving you to work it out. The date is fifteen years away, it breaks nothing today, and it is exactly the sort of detail a verifier that only ever reports a clean pass would never show you.

Our appraiser keeps two piles. Things that disqualify, and things that are real without disqualifying. The second pile travels out with the result as an anomaly instead of being thrown away. This chip passes, and the anomaly rides along with the pass. Writing down a fact fifteen years early costs us a line of text. Finding it on the day it starts refusing hardware costs considerably more.

What it does not mean

It does not mean the chip is faulty, or the certificate malformed, or that STMicroelectronics made a mistake. A long lived endorsement certificate is the correct design. It does not mean these machines stop working in 2039 either, since the silicon is unaffected and vendors reissue roots well before expiry. Nor is any of this unique to STMicroelectronics. It is written up here because it was the first time our own tooling told us something true that nobody had thought to ask about.

What we were doing

A tester’s laptop with an STMicroelectronics TPM in it kept being refused, because we pin no STM root. Adding one looked like half an hour of work. Take the vendor’s roots out of Microsoft’s TPM root bundle, the same source that corroborates every Nuvoton root we already pin, write down the fingerprints, done.

What we found

The bundle ships six certificates for STMicroelectronics in a directory called RootCA. Two of them are not roots. ST TPM EK Root CA and STM TPM ECC Root CA 01 are both issued by GlobalSign, and both carry pathlen:1. They are intermediates sitting under a folder name that says otherwise.

The real trust anchors belong to GlobalSign, and a chain off an STM chip runs four certificates deep where a Nuvoton chain takes two:

Both anchors are published by fingerprint, so you can repeat the check instead of believing us:

GlobalSign Trusted Platform Module Root CA
  sha256  f27bf02c6e00c73d915eeb6a6a2f5fbf0c31ae0393149e6b5c31e41b113841c3

GlobalSign Trusted Platform Module ECC Root CA
  sha256  5a8c7b5eb888cfce9322068e80e82b28b554ffeb7fdc9638dcb3763077401d26

What it changed

It stopped the half hour job cold. Pinning a certificate as a trust anchor because a folder called it one is exactly the error our verifier exists to make impossible, and we came within a few minutes of making it ourselves.

It also turned up an assumption we had been leaning on without noticing. Every root we pin carries the vendor it belongs to, and we refuse any chip whose self reported manufacturer contradicts the root that signed it. That check works beautifully for Nuvoton, because Nuvoton signs its own roots, so chains to this root and is this vendor’s chip turn out to be the same sentence. GlobalSign is a different animal. It runs a TPM programme that can sign for more than one manufacturer. Anchor a pin there, label it with a single vendor, and one day we refuse another vendor’s entirely legitimate chip over a contradiction that never happened.

So STM stays unpinned until that is sorted out properly, and a tester with an STM chip still gets turned away. Being honestly unable to verify a device is a better place to stand than verifying it against an anchor we have misread.

Update, 29 September 2026. Resolved the same day. We pin the STM certificate itself and not the GlobalSign anchor above it, for the reason set out in the entry above. STM chips now enrol.

What it does not mean

Nothing here suggests STMicroelectronics or GlobalSign have done anything wrong. The certificates are correctly issued and the chain is sound. A folder name was never a cryptographic claim and nobody ever promised it was, which is precisely the point. A verifier that reads directory names instead of the issuer field will trust the wrong thing eventually, and it will do it while reporting success.

What we were doing

Trying to get AMD firmware TPM desktops accepted in production. Our coordinator enrols a machine only when its endorsement certificate chains to a root we pin, and these machines kept being refused.

What we found

The endorsement key on a real AMD desktop chains through an intermediate named PRG-SSP to a self signed root named AMDTPM, valid from 2014 to 2039. There was exactly one way to obtain that root: an address written inside the intermediate itself, served over unencrypted HTTP. The evidence was telling us where to go and fetch the thing that is supposed to vouch for the evidence.

Microsoft publishes a bundle of trusted TPM roots and intermediates as part of its TPM root program, 2,571 certificates in all. We checked ours against it:

Both fingerprints are published, so you can repeat the check instead of believing us:

AMDTPM root  :  NOT in the Microsoft bundle
  sha256  67bd2472a546751caca5f358a78f80727531671338960a9bcfdfbe6a34d0c6a1

Nuvoton TPM Root CA 2111  :  present, and pinned in our production coordinator
  sha256  cd8185ff8995ed09811970090a8c36fafab34ef87f47fa51fdb9ecf95c9c2e04

What it changed

AMD firmware TPM stays a laboratory root and production goes on refusing it. Not because the cryptography is weak, since the chain verifies correctly every single time, but because no party other than the chain itself vouches for its anchor. A trust anchor that arrives alongside the evidence is not a trust anchor.

It also held our own standard to account. The Nuvoton root running in production is in Microsoft's bundle, so the bar AMD failed is the same bar our shipped root clears.

What it does not mean

None of this says AMD firmware TPMs are insecure, or that AMD has done anything wrong. AMD operates a real PKI and Microsoft distributes part of it. It says our particular machine chains to a certificate authority that no independent publisher we can check happens to carry. A different AMD machine, chaining to one of the eighteen intermediates Microsoft does carry, could be anchored today.

What we were doing

Working out how long a stored evidence bundle stays re-verifiable, since we hold attestation evidence for as long as an account is open and then twenty-four months beyond it.

What we found

Everyone will tell you that an Android attestation leaf is short lived and everything above it lasts for years. Put a real Motorola handset in front of you and the chain does not look like that at all. Among its five certificates sits a per device intermediate, issued by Google's remote key provisioning, valid for 293 hours and 40 minutes. A little under twelve and a half days.

On a Samsung Galaxy S22 the leaf itself was good for 33 minutes.

Chain validation checks the validity window of every certificate in the chain, not only the leaf. A stored bundle therefore stops verifying the moment the soonest certificate in it lapses, wherever in the chain that certificate happens to sit.

What it changed

Our verifier now reports the earliest expiry anywhere in the chain instead of the leaf's, and every bundle carries that date. It also changed what we say retention is for. Re-checking an Android chain months later cannot re-establish trust, because the certificates have gone. What can be run again is our own appraisal of the evidence. So stored evidence is a record we can audit our verifier against, and that is how we describe it. We do not call it a proof that keeps.

What it does not mean

Short lived certificates are a deliberate privacy design and not a defect, and stored evidence is far from worthless. It does mean that anyone offering to re-verify a stored mobile attestation years after the fact should be asked, politely but precisely, what they intend to re-verify.

What we were doing

Reading three attestation chains captured off physical handsets, because we wanted to know what real evidence contains, not what the schema permits.

What we found

Brand, model, manufacturer and device name are optional fields. A phone fills them in only when the application asks for device property attestation at the moment the key is created, and most applications never ask.

What it changed

So our device catalogue recognises a model by the shape of its evidence. Which claims it proves, where each one came from, how its certificate chain is put together. Not by a model string that two of the three real handsets we have read decline to give us.

What it does not mean

The S22 is not less trustworthy for keeping its own name to itself. Its boot state, its key security level and its patch levels were all there and all hardware enforced. What it does mean is that a fleet report listing device models is reading those names from somewhere other than the attestation, and that somewhere is ordinary software.

What we were doing

Running the same three handset chains past our pinned roots one more time.

What we found

The Sony Xperia chain verifies perfectly. Every signature checks out and it ends at a legitimate Google root. That root happens to be the one Google publishes for software attestation. Read the key description and you find a security level of software, no root of trust, no verified boot state, and no patch level anywhere in it.

The evidence is authentic. What it tells you is that a key exists, in software, on a device. And that is all of it.

What it changed

This is why a result from us never collapses into a tick. Every verification hands back the claims it actually got hold of, and beside them a written list of what it could not establish. A software backed key therefore reads nothing like a StrongBox backed one, even though both are honestly described as verified.

What it does not mean

A software backed key is not a sign of a compromised device. It is what a device produces when hardware attestation is not available to it, and there are several ordinary reasons for that. What it does mean is that the attestation verified says nothing by itself about security. Any product that reports it as though it did is not telling you enough.