A TPM Is Not a Key Lifecycle

“The private key is in the TPM, so the certificate lifecycle is handled.”

Let me stop you before that becomes an asset-management strategy.

A TPM is not a key lifecycle.

A TPM can generate or hold a device-bound private key.

Keep it from crossing the hardware boundary in plaintext.

Bind a secret to a measured boot state.

Produce evidence about that state.

Strong properties.

They matter.

They don’t decide who may enroll the device.

Or which service owns your certificate.

Or when the certificate renews.

Or whether a compromised credential is revoked.

Or how every consumer cuts over.

Or what happens when the hardware is gone.

You would never say “the encrypted backup exists, so recovery is handled.”

Put a TPM in the sentence and suddenly the asset register, the CA, your deployment path and the recovery runbook are apparently all inside a small piece of silicon.

They aren’t.

TPM 2.0 defines a hardware key and measurement model.

Key management is the operating system around that model.

Generation.

Assignment.

Issuance.

Inventory.

Renewal.

Rotation.

Revocation.

Recovery.

Audit.

The point where they meet is important.

It is also very much a point, not a merger.

1. “But the Key Cannot Be Exported.”

Good.

That is exactly the property a TPM is meant to supply.

A TPM performs hashing, signing, encryption and related operations inside its own boundary.

The caller submits data and receives a result.

Not the private key.

The storage root key is generated on-chip and wraps the keys below it.

Its private half is never exposed to a host process, a user, or the operating system.

Categorically better than leaving a key file on disk and hoping file permissions remain an existential truth.

TPM 2.0 separates those objects through platform, storage and endorsement hierarchies.

The storage hierarchy protects wrapped keys.

The endorsement key supports device identity for attestation.

That is a deliberate change from TPM 1.2’s single hierarchy, and TPM 2.0 is explicitly not backward-compatible with it under ISO/IEC 11889:2015.

None of that answers whether your certificate bound to the public half is still wanted.

A certificate is issued after a certificate signing request, validation, issuance and installation.

The private key’s extraction path is one property in that sequence.

Your certificate’s authority, and your service’s ownership, are different properties.

Non-exportable does not mean nonrevocable.

If a device is deprovisioned, a role changes, a service moves, or the hardware is suspected of compromise, you still have to decide what happens to your certificate.

A TPM can refuse to give up the old key.

It cannot telephone the CA.

Or update the load balancer.

Or identify the forgotten client that still trusts the old chain.

A chip isn’t a change board because it has a private key.

2. “But Secure Boot Measures the Device State.”

It doesn’t.

Measured boot measures the device state.

Secure Boot enforces a signature check before code runs.

That distinction isn’t a branding detail.

In measured boot, each stage hashes the next stage before handing it control.

The TPM accumulates the result in Platform Configuration Registers through an extend operation: PCR_new = hash(PCR_old || new_measurement).

That makes the final PCR value depend on the ordered measurement history.

Later software cannot simply overwrite an earlier value in an ordinary log and call the device clean.

TPM 2.0 commonly provides 24 PCRs per hash bank, conventionally PCR 0 through PCR 23.

PCR 7 commonly covers Secure Boot state.

Banks can operate in parallel for SHA-1, SHA-256 and sometimes SHA-384 or SM3.

That is the specification’s answer to algorithm agility, not a guarantee that every old hash has become wise.

Secure Boot uses a Platform Key, Key Exchange Keys, the db allow-list and the dbx revoked-signers list to verify the next stage before executing it.

It halts that path when the required signature does not verify.

Measured boot can record a stage the platform nevertheless permits to run.

One detects.

One blocks.

Neither answers whether a certificate assigned last quarter should remain usable today.

Remote attestation extends the measurement to a verifier.

A TPM signs current PCR values in a quote, using a device-bound key associated with its endorsement key.

That can inform an enrollment or conditional-access decision.

It does not remove your need to define who sets the expected baseline, who owns an exception, or what revokes the resulting credential.

A quote is evidence for a policy decision.

It isn’t your policy decision’s personnel department.

3. “But the Certificate Renews Automatically.”

Excellent.

Automation is how a certificate lifecycle becomes survivable.

It isn’t how it becomes complete by implication.

ACME, standardized in RFC 8555, automates domain validation, issuance and renewal as an API exchange.

Let’s Encrypt issued its first certificate on 14 September 2015 and its billionth by 27 February 2020.

Those dates matter because automatic issuance is not a novelty.

It is the machinery that lets certificate fleets operate without a person carrying every CSR from validation to installation by hand.

But renewal extends certificate validity.

Rotation replaces the underlying key material.

A renewal can use a new CSR while reusing the existing key, or generate a new key pair.

Those are different decisions.

A certificate renewed on the same TPM-bound key has a newer certificate and the same key exposure history.

The published schedule makes this operational rather than theoretical.

The CA/Browser Forum maximum validity for a publicly trusted subscriber certificate is 200 days from 15 March 2026.

100 days from 15 March 2027.

47 days from 15 March 2029.

The domain and IP validation reuse period falls to 100 days, then 10, on those same dates.

A TPM doesn’t watch any of those clocks.

AWS KMS makes the same distinction in another layer.

Automatic rotation for a symmetric customer-managed key defaults to 365 days when enabled, and does not re-encrypt data already protected by your key.

It generates new material for later operations while retaining older material to decrypt earlier data.

Rotation bounds later exposure.

It doesn’t announce that history has been washed by a calendar event.

4. “But Lost Devices Can Be Wiped.”

A wipe is an endpoint action.

Device loss is a lifecycle event.

TPM sealing is useful here, and again narrower than the conclusion usually assigned to it.

A TPM releases a sealed secret only when current PCR values match the values recorded when that secret was sealed.

BitLocker’s TPM-only mode uses that behaviour: an unexpected change in the measured firmware or bootloader chain prevents silent release of the disk key.

That protects the local unsealing path.

It does not tell you which certificate was installed on a service.

Or whether another device or workload still depends on it.

Or whether the issuer should revoke it.

Or whether a replacement must be generated.

The local boot decision and your certificate authority’s trust decision are not secretly the same database with different logos.

Your recovery procedure needs an owner for your key and certificate, a documented authority to replace or retire them, an inventory of consumers, and a verified cutover.

For a TLS or signing key, retirement means revoking or not renewing the old certificate after the overlap window closes.

For a symmetric encryption key, old material may remain available to decrypt earlier data while no longer encrypting new data.

Different recovery outcomes, because your keys do different work.

Root changes show why a local-device story can’t cover the whole lifecycle.

When the DST Root X3 cross-sign expired on 30 September 2021, devices not yet updated to trust ISRG Root X1 directly lost trust in many certificates.

The remedy for most affected users was an operating-system update.

Not an action at the issuing CA.

Trust propagation is a system dependency, not a TPM feature.

5. “But Hardware-Backed Keys Are Phishing Resistant.”

The TPM gives a credential a stronger custody property.

It does not, by itself, describe an authentication protocol’s resistance to a fraudulent relying party.

Which is exactly why hardware roots of trust are useful without becoming mystical.

A private key that stays inside the chip means software above your boundary cannot read it out and reuse it elsewhere.

The device can perform a signature operation.

It can attest to PCR values.

It can release a sealed secret only in the recorded state.

Those claims concern extraction, device binding and state.

A phishing-resistance claim concerns the ceremony through which a relying party accepts an assertion, and the checks that ceremony performs.

So verify that claim for your particular authentication flow, rather than stapling it to the word “TPM.”

Hardware-backed is not a synonym for every useful security adjective.

Use the hardware property where it applies.

Then keep the authentication policy, the enrollment authority, your certificate issuer and the revocation path visible.

“Your key cannot be copied” is a very good answer to “can the key be extracted?”

It is a strange answer to “which identity may use this service, and until when?”

6. “But Key Escrow Is an Edge Case.”

It isn’t.

Escrow is a governance decision, and the right answer changes with your key category.

For a signing or authentication key, there is no legitimate recovery need for the usable private key.

Lose it and the correct response is to generate a replacement and revoke the old identity.

Escrowing another usable copy adds a second target without solving a necessary recovery problem.

For a data-encryption key, loss can make the protected data unrecoverable by definition.

An organization that cannot accept that may escrow a recovery key in a controlled internal system, judging the exposure of that path lower than permanent data loss.

One organization can rightly escrow disk-encryption recovery material and refuse to escrow its code-signing keys.

That isn’t inconsistency.

It is key management noticing what each key actually does.

The 1993 Clipper chip remains a useful warning about confusing an escrow mechanism with a recovery outcome.

It used mandatory escrow through a classified Law Enforcement Access Field whose integrity rested on a 16-bit hash.

Matt Blaze showed in 1994 that the LEAF protection could be forged, and your programme was defunct by 1996.

The defect wasn’t that recovery is philosophically forbidden.

It was that the recovery mechanism created exposure while failing to deliver reliable recovery.

The CA/Browser Forum made the storage part concrete for code signing.

Since 1 June 2023, code-signing private keys must be generated and stored in a hardware crypto module meeting at least FIPS 140-2 Level 2 or Common Criteria EAL 4+.

That is a custody requirement.

It does not create a second, hidden escrow policy.

Or name a recovery authority.

Or decide when a certificate stops representing an authorized signer.

7. No, This Does Not Mean Hardware-Backed Keys Are Optional.

They aren’t.

Hardware-backed keys substantially improve key custody.

A TPM’s anti-hammering behaviour is also not decorative.

Windows configures TPM 2.0 to lock after 32 consecutive authorization failures and forget one failure every 10 minutes.

The limiting control is enforced by the TPM.

Not merely requested by the operating system.

Common Criteria makes another useful distinction.

ISO/IEC 15408 assigns Evaluation Assurance Levels from EAL1 through EAL7, and a higher EAL reports how rigorously the product’s stated claims were evaluated, not an absolute ranking of “more secure.”

A TPM or secure element needs its Protection Profile read alongside the number.

Certification depth and operational lifecycle are separate questions.

Use TPM-backed, non-exportable keys where your platform supports them.

Use sealing when a secret should depend on a known boot state.

Use remote attestation when enrollment policy needs evidence about the actual device.

Those are meaningful controls at the hardware and device-state layers.

They still need the layer above them.

Your inventory.

The issuance policy.

Expiry monitoring.

The renewal and rotation schedule.

Revocation authority.

Recovery authority.

The audit trail.

Stronger custody does not relieve you of deciding what the key is for.

It makes that decision worth protecting.

8. What You Should Actually Do

Generate keys inside a TPM, HSM or KMS boundary where supported, and record which boundary each key uses.

For code signing, meet the post-June-2023 hardware-module requirement rather than pretending a carefully permissioned file is equivalent.

Record key owner, certificate owner, issuing CA, consuming services, intended purpose and recovery authority alongside the asset.

Bind attestation evidence to an explicit enrollment policy. Define the acceptable PCR and Secure Boot conditions, the exception owner, and the action when a device’s quote no longer meets policy.

Do not collect a quote merely because the platform has a quote API.

That is how attestation becomes an expensive decorative receipt.

Separate the timers and the procedures. ACME can renew a certificate; your system has to state whether renewal generates new key material.

Set renewal and rotation schedules by key role, not by a single cheerful house interval.

A key-wrapping key, a direct data-encryption key, a TLS key and a signing key do not carry the same operational exposure.

Publish and test the lost-device, compromised-device, deprovisioning, revocation and recovery paths. The procedure generates replacement material in the designated boundary, issues and installs it, distributes it to all consumers, verifies cutover, preserves a bounded overlap where needed, and retires the predecessor.

Separate recovery authority from routine use.

A procedure that has never survived hardware loss is a story with verbs in it.

Make escrow an explicit per-category decision. Escrow recovery material for data only where permanent loss is unacceptable and the recovery system is controlled.

Replace and revoke signing and authentication identities instead of producing a second usable private key.

Review every exception, because “the TPM has it” is not a record of what you have promised to recover.

9. The Actual Model Is Not Complicated.

The TPM answers: can this device keep a key inside a hardware boundary, bind a secret to a measured state, and prove something about that state?

Key management answers: why does this key exist, who owns it, where is it used, when does it renew or rotate, what revokes it, how is it recovered, and who proves those actions happened?

Hardware security protects the root of trust. Key management governs the trust’s life.

Use both.

Do not call one the other because a certificate happened to be generated on a device with a TPM.

That is not a lifecycle.

It is a very well-protected unanswered question.