Trust anchors · Reference

The keys every attestation check depends on.

Attestation verification reduces to one question: does this evidence chain to a key I decided in advance to trust? Everything else — the parsing, the measurements, the nonce — is machinery around that.

Which makes the list of keys the load-bearing part, and it is the part nobody maintains in one place. Each vendor publishes their own, separately, in their own format, and announces rotations to their own audience. A verifier built against last year’s list does not fail loudly. It goes on rejecting perfectly genuine hardware while its operator concludes the devices are at fault.

Below is every root this product pins, with the fingerprint computed from the file we actually ship. We sell nothing that runs on this hardware, so we have no reason to flatter any of it.

Pinning a root and enabling it are different things. Several of the verifiers below are complete and deliberately switched off on the live coordinator until they have been proven against hardware we have held. This page documents what the software trusts, not what the service currently accepts.

What changed in 2026, and what it broke

Android’s attestation root moved, and stale verifiers are rejecting current phones right now. Google introduced an ECDSA P-384 root that took effect on 1 February 2026, and from 10 April 2026 every remotely-provisioned device chains to it. Remote Key Provisioning is mandatory on hardware that launched with Android 16, so this is not a slow migration — it is most new phones.

A verifier still pinning only the older RSA root refuses all of them. The failure is indistinguishable from a device that genuinely cannot attest, which is why it can run for months unnoticed. The older root expired on 24 May 2026 and Google no longer publishes it, so a correct verifier holds the two Google serves today and does not pin the dead one. Factory-keyed devices are admitted by a dated carve-out applied to the chain, which is where that exception belongs.

On PCs, the Secure Boot certificates expire this year. The Microsoft KEK CA 2011 and the third-party UEFI CA 2011 expire in June 2026 and the Windows Production PCA 2011 in October 2026. Installing the replacements changes PCR 7, which is a measurement a great deal of software seals secrets to — so this is a trust-anchor change that moves an attestation value as a side effect.

The roots we pin

These are vendor root certificates — the certificate at the top of a manufacturer’s chain. They are not the same thing as an attestation root, which is a whole kind of evidence with its own verifier. Several vendor certificates can sit inside one attestation root: every Nuvoton entry here lives inside TPM 2.0.

Fingerprints are SHA-256 over the complete DER encoding, computed from the certificate this product pins. The date is 26 September 2026 unless a root below carries one of its own. Section 04 has the command, so you can check rather than believe.

Root certificates pinned by the SEVEN KG verifier, with algorithm, expiry and SHA-256 fingerprint.
Used for	Certificate	Key	Valid until
Android Key Attestation	Key Attestation CA1	ECDSA P-384	15 July 2035
Android Key Attestation	Legacy factory-provisioned root	RSA 4096	15 March 2042
Apple App Attest	Apple App Attestation Root CA	ECDSA P-384	15 March 2045
Intel TDX and SGX	Intel SGX Root CA	ECDSA P-256	31 December 2049
AWS Nitro Enclaves	AWS Nitro Enclaves Root G1	ECDSA P-384	28 October 2049
NVIDIA devices	NVIDIA Device Identity CA	ECDSA P-384	31 December 9999
NVIDIA reference values	NVIDIA CoRIM signing Root CA	ECDSA P-384	8 March 2053
AMD SEV-SNP	ARK-Turin	RSA 4096	15 May 2048
AMD SEV-SNP	ARK-Genoa	RSA 4096	26 January 2047
AMD SEV-SNP	ARK-Milan	RSA 4096	22 October 2045
TPM 2.0	Nuvoton TPM Root CA 2111	ECDSA P-256	7 September 2037
TPM 2.0	STM TPM EK Root CA	RSA 2048	31 December 2039

Key Attestation CA1

Android Key Attestation

Subject: CN=Key Attestation CA1, OU=Android, O=Google LLC, C=US
Key: ECDSA P-384
Valid until: 15 July 2035 · issued 17 July 2025
SHA-256: 6D:9D:B4:CE:6C:5C:0B:29:31:66:D0:89:86:E0:57:74:A8:77:6C:EB:52:5D:9E:43:29:52:0D:E1:2B:A4:BC:C0

The new root. Effective 1 February 2026; all remotely-provisioned chains switched to it on 10 April 2026.

Published by the vendor at https://android.googleapis.com/attestation/root

Legacy factory-provisioned root

Android Key Attestation

Subject: serialNumber=f92009e853b6b045
Key: RSA 4096
Valid until: 15 March 2042 · issued 20 March 2022
SHA-256: CE:DB:1C:B6:DC:89:6A:E5:EC:79:73:48:BC:E9:28:67:53:C2:B3:8E:E7:1C:E0:FB:E3:4A:9A:12:48:80:0D:FC

Expired 24 May 2026, and Google no longer publishes it. Do not pin it. Devices with factory-injected attestation keys are admitted by a dated, vendor-specified carve-out applied to the chain, which is where that exception belongs. A verifier that drops expired roots is behaving correctly.

Published by the vendor at https://android.googleapis.com/attestation/root

Apple App Attestation Root CA

Apple App Attest

Subject: CN=Apple App Attestation Root CA, O=Apple Inc., ST=California
Key: ECDSA P-384
Valid until: 15 March 2045 · issued 18 March 2020
SHA-256: 1C:B9:82:3B:A2:8B:A6:AD:2D:33:A0:06:94:1D:E2:AE:4F:51:3E:F1:D4:E8:31:B9:F7:E0:FA:7B:62:42:C9:32
Computed: 3 November 2026

The only root on this page supplied as a file at startup rather than compiled into the verifier. The coordinator reads it from disk and refuses to start with Apple switched on and the file absent. Apple publishes one root for App Attest and this is it, so there is no second generation to pin and no rotation to watch. This entry was missing from this page until 3 November 2026 while the root was pinned and accepted in production, which is the direction of error this page exists to prevent.

Published by the vendor at https://www.apple.com/certificateauthority/Apple_App_Attestation_Root_CA.pem

Intel SGX Root CA

Intel TDX and SGX

Subject: CN=Intel SGX Root CA, O=Intel Corporation, L=Santa Clara, ST=CA, C=US
Key: ECDSA P-256
Valid until: 31 December 2049
SHA-256: 44:A0:19:6B:2B:99:F8:89:B8:E1:49:E9:5B:80:7A:35:0E:74:24:96:43:99:E8:85:A7:CB:B8:CC:FA:B6:74:D3

TDX quotes are converted to a signable form by an SGX enclave, so a TDX verifier inherits SGX’s certificate chain and this root anchors both.

Published by the vendor at https://certificates.trustedservices.intel.com/Intel_SGX_Provisioning_Certification_RootCA.cer

AWS Nitro Enclaves Root G1

AWS Nitro Enclaves

Subject: CN=aws.nitro-enclaves, OU=AWS, O=Amazon, C=US
Key: ECDSA P-384
Valid until: 28 October 2049
SHA-256: 64:1A:03:21:A3:E2:44:EF:E4:56:46:31:95:D6:06:31:7E:D7:CD:CC:3C:17:56:E0:98:93:F3:C6:8F:79:BB:5B

The only root here that needs no online lookup of any kind. Attestation documents verify completely offline, with revocation checking disabled by design — no CRL, and therefore no revocation.

Published by the vendor at https://docs.aws.amazon.com/enclaves/latest/user/verify-root.html

NVIDIA Device Identity CA

NVIDIA devices

Subject: CN=NVIDIA Device Identity CA, O=NVIDIA
Key: ECDSA P-384
Valid until: 31 December 9999
SHA-256: 10:2B:F6:59:D5:41:96:14:C9:D8:E6:AE:CE:BC:80:45:4E:B2:6B:1D:F6:A7:69:AC:72:0B:9A:69:0B:16:7B:48

Endorses GPUs AND networking silicon — ConnectX-7/8/9/10, BlueField-3, LinkX, and the Quantum and Spectrum switch ASICs all sit as intermediates beneath it. The year 9999 expiry is NVIDIA’s, not a typing error on our part.

Published by the vendor at https://docs.ndis.nvidia.com/certs/identity-root/Root-CA.cer

NVIDIA CoRIM signing Root CA

NVIDIA reference values

Subject: CN=NVIDIA CoRIM signing Root CA, O=NVIDIA, C=US
Key: ECDSA P-384
Valid until: 8 March 2053
SHA-256: 12:97:7B:51:15:AC:B0:38:11:79:27:9F:FF:EB:5A:8C:4D:26:49:71:EB:B3:22:98:02:3A:46:5F:A4:1D:F5:D1

A separate hierarchy from device identity. This one signs the reference measurements a device’s firmware is compared against — a different question from whether the device is genuine, and it deserves a different key.

Published by the vendor at https://docs.ndis.nvidia.com/CoRIM/CoRIM%20Certificates.html

ARK-Turin

AMD SEV-SNP

Subject: CN=ARK-Turin, O=Advanced Micro Devices, OU=Engineering
Key: RSA 4096
Valid until: 15 May 2048
SHA-256: sha256 of the DER: 1f084161a44bb6d93778a904877d4819cafa5d05ef4193b2ded9dd9c73dd3f6a

AMD issues a separate root per processor generation. A verifier that pins one generation silently refuses every machine of another.

Published by the vendor at https://kdsintf.amd.com/vcek/v1/Turin/cert_chain

ARK-Genoa

AMD SEV-SNP

Subject: CN=ARK-Genoa, O=Advanced Micro Devices, OU=Engineering
Key: RSA 4096
Valid until: 26 January 2047
SHA-256: sha256 of the DER: 4c6598d19c18719c5dfd4a7d335f674e5bfe1d8f800cea2cf270c10d103db2f1

Genoa, Bergamo and Siena — the EPYC 9004 family.

Published by the vendor at https://kdsintf.amd.com/vcek/v1/Genoa/cert_chain

ARK-Milan

AMD SEV-SNP

Subject: CN=ARK-Milan, O=Advanced Micro Devices, OU=Engineering
Key: RSA 4096
Valid until: 22 October 2045
SHA-256: sha256 of the DER: 69d063b45344d26a2e94e1f4210de49ef555308287d4c174445c95639a540bcd

EPYC 7003. The oldest generation with SEV-SNP at all; 7001 and 7002 have SEV or SEV-ES only and cannot produce a general attestation report.

Published by the vendor at https://kdsintf.amd.com/vcek/v1/Milan/cert_chain

Nuvoton TPM Root CA 2111

TPM 2.0

Subject: CN=Nuvoton TPM Root CA 2111, O=Nuvoton Technology Corporation, C=TW
Key: ECDSA P-256
Valid until: 7 September 2037 · issued 11 September 2017
SHA-256: CD:81:85:FF:89:95:ED:09:81:19:70:09:0A:8C:36:FA:FA:B3:4E:F8:7F:47:FA:51:FD:B9:EC:F9:5C:9C:2E:04

The anchor this product has actually enrolled hardware against. A discrete TPM on a development laptop chained to it in production on 21 September 2026. Sixteen further Nuvoton roots are pinned alongside it, because a TPM manufactured in a different year chains to a different root of the same vendor, and pinning only one means only one generation of chip can enrol. All seventeen were confirmed present in Microsoft TPM root certificate program package on 27 September 2026, which is what makes them corroborated rather than merely self-consistent. The complete file is linked below so every digest can be checked rather than taken on trust. ONLY THIS ROOT IS LIVE TODAY: the other sixteen are compiled into the verifier and have not yet been deployed to the production coordinator.

Published by the vendor at /tpm-roots-nuvoton.pem

STM TPM EK Root CA

TPM 2.0

Subject: CN=STM TPM EK Root CA, O=STMicroelectronics NV, C=CH
Key: RSA 2048
Valid until: 31 December 2039 · issued 28 July 2009
SHA-256: F8:E3:7A:86:B6:89:A2:0A:6C:C0:C4:0C:C3:F8:1F:B1:30:FA:9F:44:CE:7F:FA:60:D6:25:90:AA:F8:72:73:A9

The second TPM vendor we hold hardware for. Verified on 29 September 2026 against a first-hand ST33HTPHAHE4 discrete chip, chain built to depth two and terminating here. It is not yet the anchor of a production enrolment. This certificate is NOT self-signed, and that is deliberate: GlobalSign issued it, so by signature it is an intermediate and a root only by name. Pinning the self-signed certificate above it would be tidier and substantively wrong, because it would quietly admit every manufacturer in GlobalSign’s Trusted Computing programme to our trust base under the label STM. A pin is a statement about whose silicon we are willing to believe, and GlobalSign does not make silicon. The digest came from Microsoft’s TPM root certificate program package, which is neither STMicroelectronics nor the chain it validates, so it is corroborated to the same standard as the Nuvoton entries. It is the subject of published finding f5.

Published by the vendor at /stm-tpm-ek-root.pem

Checking your own verifier

Print the fingerprint of every root your system trusts and compare it with the table above. Anything you hold that is not listed, or listed and not held, is worth understanding before you rely on it.

openssl x509 -in root.pem -noout -subject -enddate -fingerprint -sha256

Google serves the Android roots as JSON with escaped newlines rather than as PEM, so they need decoding before OpenSSL will read them. The error is an unhelpful unable to load certificate, which reads like a corrupt file.

curl -s https://android.googleapis.com/attestation/root \
  | python3 -c "import sys,json;[print(c) for c in json.load(sys.stdin)]"

If that returns two certificates and your verifier holds one, you have found the problem described in section 00.

What is not here, and why

A registry that lists only what it has is half a reference. Three of these are absent because no key exists to list, which is a fact about the technology rather than about us.

AMD firmware TPM root: An AMD fTPM endorsement root is pinned in the verifier and is deliberately not live. Its digest was obtained by walking the certificate’s own AIA pointer over plain HTTP — a source named inside the very certificate it is meant to vouch for, which is circular. Microsoft’s package carries eighteen intermediates issued by this root but not the root itself, so a second independent source does not yet exist. It stays lab-only until one does, and no production enrolment may anchor to it.
Arm CCA: There is no published root. The platform attestation key is provisioned by whoever made the chip, endorsements are distributed out of band per vendor, and the IETF draft meant to standardise their publication still carries a TODO in its security considerations. CCA silicon now exists — NVIDIA Vera — but no cloud exposes a Realm to a customer, so there is nothing to pin and nothing to check it against.
Arm PSA (RFC 9783): No public key infrastructure exists, and the reference firmware ships a hardcoded attestation private key that is enabled by default, so an out-of-the-box development board signs with a key anyone can download. PSA evidence can be appraised against keys a device owner registers with us. It cannot be used to establish that hardware is genuine, and we will not claim otherwise.
GrapheneOS: Not a certificate authority. GrapheneOS publishes a verified-boot key digest per device model; we pin 21 of them, generated from their AttestationServer source at a named commit rather than transcribed by hand. The chain itself still roots to Google.

Method, and corrections

Every fingerprint was computed from the certificate this product pins, not copied from a vendor’s web page. Most are compiled into the verifier; the Apple root is read from a file at startup, and it is the one row with a date of its own. A trust anchor that arrives by the same path as the evidence it is meant to check is not a trust anchor, so each of these was obtained from the vendor independently and compared.

This page will go out of date. Roots rotate, vendors add generations, and expiry dates arrive. If a value here disagrees with what you measure, we would rather hear about it than not: security@svnkg.com.

SEVEN KG LLC · Kansas Business ID 10090770. We verify hardware. We sell none of it.