Telling a real chip from a software fake.

Some customers legitimately run in the cloud and want their own cloud devices to count. So we also labelwhat kind of chip we're looking at: a genuine hardware chip, a firmware chip built into the CPU, or a software emulator. Your policy can decide what to accept. But labeling is a convenience, not the defense. The defense is the manufacturer signature: a rogue emulator can name any vendor it wants, yet it can't forge a chain back to a pinned chip-manufacturer root, and that check runs no matter what the chip claims to be. Everything below is how the labeling works, for readers who want the mechanics.

Every EK certificate the platform produces can carry two pieces of evidence the classifier reads. It does not AND them. It takes the first that yields a class, checking the manufacturer code first and the issuer DN as the fallback:

• TCG manufacturer code (SAN attribute 2.23.133.2.1): a 4-byte ASCII vendor code the TPM asserts about itself. Examples: IFX (Infineon), INTC (Intel PTT), STM (STMicro), MSFT (Microsoft, Pluton or Hyper-V), and so on. Read first.
• Issuer DN: what CA signed this cert. Used as the fallback when the manufacturer code is absent or unrecognized: a substring match against known vendor and cloud names (Infineon, Nuvoton, Pluton, Azure, swtpm, …).

The classifier (TpmClassClassifier.cs) reads the manufacturer code first; if it maps to a known class it returns it, otherwise it falls back to the issuer-DN substring match. So IFX → HardwareDiscreteInfineon and INTC → FirmwareTpmIntelPtt without ever consulting the issuer, while a cert with no recognized manufacturer code is classified purely from who signed it. A couple of codes (MSFT, IBM) are shared across a hardware and a virtual use, so those (and only those) are disambiguated by an additional issuer substring check, described below.

Both Pluton firmware TPMs and the Hyper-V vTPM assert the same MSFT manufacturer code, so the code alone can't separate them. The classifier disambiguates with a plain string.Containson the EK cert's issuer DN: if it contains Pluton the device is classified FirmwareTpmPluton; if it contains Host Guardian or vTPM it's CloudVtpmHyperV. An ambiguous Microsoft issuer that matches neither marker defaults to Pluton. This is a substring heuristic, not a chain-depth analysis. The real gate on a Hyper-V vTPM is that the cloud-permissive path demands provider-signed instance-identity cross-validation before it is accepted.

The swtpm software emulator ships asserting the TCG-allocated IBM manufacturer code (0x49424D00) out of the box, documented in SUSE's virt guide and upstream swtpm sources. Two things follow, and it matters to state them precisely:

• The IBM manufacturer code alone does notmean "virtual." A cert carrying the IBM code whose issuer is not an swtpm CA classifies as HardwareDiscreteOther, a hardware class. There is no "IBM-is-virtual-by-default" rule and no per-class allow-list override.
• swtpm is caught by its issuer DN, not its manufacturer code: the classifier matches the issuer substrings swtpm, SW TPM, or Software TPM and returns EmulatedSwtpm. When the IBM manufacturer code is present it is only mapped to EmulatedSwtpm if the issuer also contains swtpm; otherwise it stays HardwareDiscreteOther.

Either way, classification is not the load-bearing defense against a rogue emulator. An swtpm instance can name any issuer it likes, but it cannot forge a chain to a pinned TPM-manufacturer root: EK-certificate chain validation rejects it before its class ever matters. Detecting the swtpm issuer is a fast, honest label layered on top of that cryptographic gate. Never a substitute for it.

Some customers legitimately operate in AWS / Azure / GCP and want device identity for their own infrastructure (containers in their own ECS, EKS, AKS, GKE). Strict rejection isn't the right policy for them. Instead, our cloud-permissive policy accepts cloud vTPMs only when they ship a fresh provider-signed instance-identity document binding the attestation to a specific cloud instance.

• AWS Nitro: NitroAttestationVerifier validates the COSE_Sign1/ES384 signature against the pinned AWS Nitro Enclaves Root G1, then Ec2InstanceIdentityVerifier binds the attestation to a specific EC2 instance via 16 per-region signing certs.
• Azure: AzureAttestedDataVerifier validates the PKCS#7 envelope against the pinned DigiCert Global Root G2, then binds via the IMDS attested-data instance identity.
• GCP: GcpInstanceIdentityJwtVerifiervalidates the JWT against Google's live JWKS with audience-as-nonce binding.

A relayed attestation from instance A cannot also produce an IID naming instance B. The relay case closes cryptographically.