Detecting Certificate Migration: How to Track a PKI Key Across Devices

A certificate is only as trustworthy as the device holding its private key. If an attacker exports a key from one laptop and installs it on another, every system that trusts the certificate is now trusting the wrong device.

To detect PKI key migration, bind the private key to hardware on the original device and force every relying party to verify that binding at authentication.

What Is PKI Key Migration?

Public key infrastructure (PKI) key migration is the act of moving a private key from the device it was issued on to a different device.

Some migrations are legitimate (a Hardware Security Module (HSM)-backed certificate authority (CA) root moving to a new appliance, for example) while most are not.

When an end-entity certificate’s private key leaves the laptop, phone, or server it was provisioned on, the certificate’s identity guarantee collapses. Anyone holding the key can impersonate the original device.

The defense: generate the key inside hardware that does not allow export, then force every authentication event to prove the key still lives there. That proof is called key attestation.

How Hardware-Backed Storage Prevents PKI Key Migration

The first line of defense against PKI key migration is generating the key inside hardware with no export interface. Three categories appear in most enterprise PKI deployments.

Trusted Platform Module (TPM)

A TPM is a discrete (standalone chip) or firmware-based cryptoprocessor on a personal computer (PC) or server motherboard.

Since Windows 8, a key generated inside the TPM can be marked non-exportable, meaning the operating system (OS) has no Application Programming Interface (API) to retrieve the key material.

Mimikatz-class memory dumping tools cannot extract a TPM-protected key because it never leaves the chip.

Hardware Security Module (HSM)

A hardware security module is a network-attached or Peripheral Component Interconnect Express (PCIe) cryptoprocessor for high-volume cryptographic operations.

HSMs hold CA root and issuing keys in most well-run enterprise public key infrastructures (PKIs) and are Federal Information Processing Standards (FIPS) 140-3 certified to enforce non-extractability.

An HSM is overkill for end-user device keys; its role is to anchor the CA.

Secure Enclave and Mobile Equivalents

The Apple Secure Enclave is a dedicated coprocessor integrated into the Apple systems-on-a-chip (SoC), on Mac, iPhone, and iPad.

Keys generated through the Secure Enclave API are non-exportable by design. Android offers a parallel construct: StrongBox on devices with dedicated hardware, or the Trusted Execution Environment (TEE) backing the Android Keystore.

Hardware Comparison

Hardware	Typical use	Export possible?
TPM	End-user device certificates	No, when non-exportable
HSM	CA root and issuing keys	No, FIPS 140-3 enforced
Secure Enclave	Per-app keys on Apple devices	No, API does not exist
Android Keystore	Mobile device certificates	No, when bound to StrongBox or TEE

How Key Attestation Detects PKI Key Migration

Hardware-backed storage stops migration at the source. Attestation lets a relying party verify, at enrollment and authentication, that the key is still where it was generated.

The Attestation Flow

1. The device generates a key pair inside the hardware module (TPM, Secure Enclave, StrongBox).
2. The hardware module produces a statement, signed by a manufacturer-rooted attestation key, asserting the new key is non-exportable and bound to this module.
3. The device sends the certificate signing request and the attestation statement to the CA.
4. The CA verifies the manufacturer signature, confirms key properties, and issues the certificate.
5. The CA marks the certificate with an issuance policy object identifier (OID) indicating it was hardware-attested.

A relying party such as a RADIUS server reads that OID and treats the certificate as proof of device identity, not just key possession.

Issuance Policy OIDs as Provenance Tags

Active Directory Certificate Services (ADCS) and most modern CAs encode attestation results into the issuance policies extension as an OID.

Microsoft ACDS defines three assurance levels, each with a different OID:

• Endorsement Key: When the CA matches the device’s EKpub against an administrator-managed allowlist. (High assurance, OID 1.3.6.1.4.1.311.21.30).
• Endorsement Certificate: When the EKCert chains to a trusted TPM manufacturer root. (Medium assurance, OID 1.3.6.1.4.1.311.21.31).
• User Credentials: When the requester proves only that they hold valid AD credentials. (Low assurance, OID 1.3.6.1.4.1.311.21.32).

A certificate without an attestation OID could have come from a software keystore. A certificate with the right OID guarantees the key never left its hardware home.

ACME Device Attestation: Attestation at Enrollment Scale

Hand-rolled TPM attestation works for a few hundred PCs in one Active Directory domain. It does not scale to a fleet of mixed Mac, Windows, and iOS devices managed by a mobile device management (MDM) platform.

Automated Certificate Management Environment (ACME) Device Attestation (ACME DA) closes that gap.

ACME DA extends the ACME protocol so a managed device can prove, during enrollment, that the requested key is hardware-backed and bound to that device.

The enrollment exchange:

1. The MDM tells the device to enroll at the ACME endpoint.
2. The device generates a key pair inside its Secure Enclave, StrongBox, or TPM.
3. The device requests an attestation challenge from the ACME server.
4. The platform attestation service signs a statement linking the key to the device hardware identifier.
5. The ACME server verifies the signature against the platform attestation root and issues the certificate.

The result is a certificate that a RADIUS server, VPN, or zero-trust gateway can trust as proof of device identity.

Identity Provenance Signals for RADIUS and Wi-Fi Infrastructure

When a device authenticates to Wi-Fi using Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), the RADIUS server checks the client certificate.

EAP-TLS proves the client holds the private key; it does not prove the key has not been migrated. The RADIUS server has to evaluate identity provenance, not just signature.

Several signals are available:

• Issuance policy OID: Reject certificates lacking a hardware-attestation OID, or tier access policies by attestation status.
• CA scope: Only accept certificates from a CA that requires attestation as a precondition of issuance.
• Certificate template metadata: When the CA is internal, encode the template name in an extension and treat attested templates as higher trust.
• Real-time identity lookup: A modern cloud RADIUS server can query the identity provider at authentication to verify the device account is active.
• Certificate revocation list (CRL) and Online Certificate Status Protocol (OCSP): Standard revocation checks remove access for any revoked certificate, the fallback when migration is detected after the fact.

A SecureW2 Cloud RADIUS deployment pairs provenance with policy-based access control.

The server reads the certificate, queries the identity provider, and applies Virtual Local Area Network (VLAN), role, or deny decisions based on the live state of the user, device, and certificate.

Configuration Choices That Make Migration Detectable End-to-End

A migration-resistant PKI is a stack of decisions made together. Skipping any one creates a gap large enough to undo the rest.

• Generate keys inside hardware. Never use a CA template that lets the client generate the key in software and import it.
• Require attestation at enrollment. Configure templates to reject any certificate signing request (CSR) without a valid attestation chain rooted at the platform manufacturer.
• Encode the trust model in the certificate. Use issuance policy OIDs to tag every attested certificate.
• Tighten certificate lifetimes. Short lifetimes limit the blast radius of any undetected compromise. Pair them with Dynamic PKI for automated reissuance.
• Evaluate provenance at authentication, not just issuance. Most deployments skip this step, which is why many teams running TPM-attested PKI still cannot detect migration.
• Centralize visibility. Logs from the CA, RADIUS server, and MDM should land in one Security Information and Event Management (SIEM). Migration signals are correlations across systems.

Detect a Migrated Key in a Live Environment With SecureW2 Cloud RADIUS

The SecureW2 JoinNow Cloud RADIUS server is the natural detection point for customers running 802.1X authentication with EAP-TLS.

Every authentication carries the certificate serial number, issuer, and subject alternative name (SAN), plus network metadata (MAC address, switchport, access point, and internet protocol).

When the same certificate authenticates from two distinct hardware identifiers within a short window, that is a high-fidelity signal of a cloned key.

Adding the attestation OID makes detection of migrated keys easier and more reliable. If migration is detected, administrators can revoke the certificate, require re-enrollment with fresh attestation, and audit the original device.

Detecting PKI key migration looks easy on a slide and gets messy in a real fleet.

The SecureW2 JoinNow Platform simplifies PKI key migration detection through these capabilities:

• Hardware-attested enrollment
• A cloud-native RADIUS server that reads attestation OIDs at authentication
• A unified policy engine that blocks migrated certificates without breaking legitimate users
• Centralized policy enforcement across users, devices, and certificates

To see how the full stack works in your deployment, schedule a demo with SecureW2 today.

---

Frequently Asked Questions

How does TPM key attestation work?

The TPM generates a private key, signs a statement about its properties using a manufacturer-rooted attestation key, and sends the statement with the CSR to the CA.

The CA verifies the signature, confirms the key is non-exportable, and issues the certificate with an issuance policy OID marking it as attested.

Can a TPM-backed private key be exported?

No, when generated as non-exportable inside the TPM. The TPM has no API that returns raw private key material. Migration of a non-exportable TPM key requires breaking the TPM itself, a hardware attack outside normal IT operations.

What is the difference between a TPM, an HSM, and a Secure Enclave?

A TPM is a per-device cryptoprocessor on PCs and servers. An HSM is a high-volume cryptoprocessor for protecting CA keys at the network level.

A Secure Enclave is the Apple per-device coprocessor inside the application processor. All three enforce non-exportable storage but serve different roles.

How do you prove a certificate’s private key has not been copied?

Use key attestation at enrollment to bind the certificate to a hardware module, encode the result in an issuance policy OID, and enforce that OID at authentication. A certificate without attestation cannot prove non-migration; one with attestation can.

What is ACME Device Attestation?

ACME Device Attestation (ACME DA) is an extension to the ACME enrollment protocol that lets a managed device prove the requested key is hardware-backed and bound to that device.

Apple, Microsoft, and Android platforms support ACME DA, enabling hardware-attested certificate enrollment across mixed enterprise fleets.