Chips and SLSA: Why TPMs Matter for Code Commits

What Does SLSA Source Track Require for Identity?

SLSA (Supply chain Levels for Software Artifacts) Source Level 2 and above require "strongly authenticated actor identity" for every commit. The SLSA v1.2 specification mandates that activities on the Source Control System (SCS) be attributed to authenticated identities. Source Provenance attestations must provide contemporaneous, tamper resistant evidence of WHO made changes. 

The problem is that SLSA defines WHAT is required (authenticated identity) but not HOW to achieve it. Organizations are left to choose between source control services (GitHub, GitLab), cryptographic signatures (GPG), or extending existing auth systems (Active Directory, Okta). 

This requirement is no longer optional for many organizations. The U.S. federal government now mandates SLSA aligned practices for all software suppliers, making authenticated identity a prerequisite for federal contracts.

Why Are SSH Keys Insufficient for SLSA Compliance?

SSH keys are software artifacts that can be copied, stolen, or exfiltrated. They prove possession of a credential, not identity of a human or device. 

There are four critical failures of SSH keys for SLSA compliance:

1. No Binding to Corporate Identity: An SSH key can be generated by anyone on any device with any email address. There is no cryptographic link to your SSO, Active Directory, or device trust. Git allows developers to set arbitrary author names and emails, making it trivial to impersonate others.
2. Exportability and Theft: SSH keys are stored as files on developer laptops. They can be copied to USB drives, exfiltrated via malware, or stolen when devices are lost. Once an attacker has the key file, they can use it from any device, anywhere in the world.
3. Zombie Credentials: When a developer leaves the organization, their SSH keys live on their personal laptop forever. Unlike SSO credentials that can be revoked instantly, SSH keys have no centralized management. Organizations have no visibility into which keys exist, where they are, or who has access to them.
4. Weak Key Management: Research from the University of Tennessee identified SSH and GPG keys as the "most weak" authentication method on development platforms, with no indication of improving without intervention. Developers often reuse keys across personal and work projects, use weak encryption due to familiarity, and rarely rotate keys.

The Credential Theft Crisis: In 2025, there was a 160% increase in compromised credentials. Credential theft now accounts for one in five data breaches. In June 2025, 16 billion stolen login credentials were exposed in a single breach. SSH keys often establish direct, privileged root access to critical systems, making them high value targets.

The Bottom Line: If your commit signing keys can be stolen, you cannot prove identity. You can only prove that someone, somewhere, had access to a key file at some point in time. This does not satisfy SLSA's requirement for "strongly authenticated actor identity."

How Do TPMs Enable Phishing Resistant Commit Signing?

What Is a TPM?

A Trusted Platform Module (TPM) is a hardware security chip (secure crypto processor) built into modern laptops, desktops, and servers. It is a physical component on the motherboard designed to be tamper resistant. 

Unlike SSH keys, which are software files, a TPM backed key is not a file at all. It is a cryptographic operation that can only be performed by a specific piece of hardware. If the hardware is not present, the key cannot be used.

TPMs provide five critical security capabilities:

1. Generate and store cryptographic keys that never leave the chip, traverse the network, or synced to the cloud
2. Provide hardware backed device authentication using a unique, strong encryption key burned into the chip
3. Ensure platform integrity by measuring and recording the boot process
4. Prevent key exfiltration by making keys unavailable outside the TPM
5. Dictionary attack protection that locks down the chip after too many incorrect authorization attempts

How TPMs Achieve Phishing Resistant Identity

Phishing resistant authentication means no shared secrets at any point in the process. 

TPM backed commit signing achieves this through three mechanisms:

1. Hardware Binding: The private key is generated inside the TPM and never leaves the chip. Even if an attacker compromises the operating system, they cannot extract the key. The key is cryptographically bound to the device's hardware identity. If the laptop is stolen, the key cannot be copied to another device.
2. Identity Attestation: TPM backed keys can be tied to corporate identity systems. When a developer enrolls, their device's TPM generates a key pair and attests to the device's health and identity. The commit signature proves: "This commit was made by [authenticated user] on [trusted device] at [specific time]." This is the "strongly authenticated actor identity" that SLSA requires.
3. Deterministic Revocation: In a TPM-backed model, the private signing key is generated inside the device’s hardware and never leaves it. When a developer offboards or a laptop is lost, a standard corporate device wipe removes the only instance of the private key, preventing any future use. Centralized policy can also disable signing from that device, providing immediate control. While revocation lists remain useful for policy completeness and auditability, the combination of hardware-bound keys plus device wipe delivers stronger assurance than revocation alone, effectively eliminating the ‘zombie credential’ risk.

The SLSA Connection: TPM backed commit signing provides cryptographic proof of identity backed by hardware. It is not just a signature. It is an immutable, auditable record that ties every commit to a verified human on a trusted device, satisfying SLSA Source Level 2 requirements for authenticated identity and source provenance.

Why Does This Matter for SLSA Source Track Compliance?

SLSA Source Level 2 requires Source Provenance attestations that prove WHO made the change (authenticated actor identity), WHEN the change was made (timestamp), and WHICH technical controls were enforced (policy compliance). 

Without hardware backed identity, organizations cannot satisfy the "authenticated actor identity" requirement with high assurance. An SSH key signed commit proves someone had access to a key file. A TPM signed commit proves a specific, verified human on a trusted device made the commit.

The Compliance Imperative: Executive Order 14028 mandates SLSA aligned practices for all software sold to the U.S. federal government. The 2023 deadline has passed, and federal agencies are now enforcing these requirements. Enterprise customers are following suit, requiring SLSA compliance from their software suppliers. Auditors are asking: "How do you PROVE identity for every commit?"

The answer is hardware backed credentials using TPMs. They are the only scalable, auditable, phishing resistant solution that satisfies SLSA Source Track requirements.

How Can Organizations Implement TPM Backed Commit Signing?

The Practical Benefits

TPM backed commit signing delivers five operational benefits that go beyond compliance. 

1. It provides zero onboarding friction. Developers do not manually generate or manage keys. The TPM handles it automatically, allowing new developers to start signing commits on day one with zero configuration. 
2. It eliminates zombie credentials. When a developer leaves, their TPM backed certificate is revoked instantly. No more SSH keys living on laptops forever. 
3. It creates audit ready provenance. Every commit is cryptographically linked to a verified identity and trusted device, creating an immutable audit trail. 
4. It prevents insider threats. Even a malicious insider cannot exfiltrate their signing key to use on another device because the key is hardware bound.
5. It scales effortlessly. The same security assurance works for 10 developers or 10,000 developers with centralized policy enforcement.

If you’re interested in a plug-n-play solution for secure commit signing, see a demo of Beyond Identity’s Secure DevOps product today. 

Frequently Asked Questions (FAQ)

Q: Do I need to replace all my developers' laptops to use TPM backed commit signing?

A: No. Most enterprise laptops manufactured after 2010 already include TPM chips. Windows 11 requires TPM 2.0, and macOS devices use the Secure Enclave (Apple's equivalent). Linux also supports TPM 2.0. Organizations can verify TPM availability using built in OS tools before deployment.

Q: Does TPM backed keys work with GitHub, GitLab, and other Git platforms?

A: Yes. TPM backed keys generate standard cryptographic signatures that are compatible with all major Git platforms. The difference is WHERE the key is stored (hardware chip versus software file), not the signature format itself.

Q: What happens if a developer's laptop is lost or stolen?

A: The organization can instantly revoke the key, rendering the device unable to sign commits. Because the key cannot be extracted from the TPM, the attacker cannot use it on another device. This is a significant improvement over SSH keys, which remain valid even after a device is lost.