Every security team that has ever managed a code signing key at scale has a story about it. The HSM that could not be reached during an incident. The key rotation that broke three consumers downstream. The signing ceremony that took six people and four hours to execute. The offline backup that no one was confident would actually work if needed. These stories are so common they have become the expected cost of "doing signing properly," and that expectation is wrong. My thesis: long-lived signing keys are operational debt, and keyless signing — built on ephemeral certificates and transparency logs — is the default architecture for 2026 forward. Programs still running the old playbook are paying a tax that no longer buys them anything.
I am not predicting this transition. It already happened in the ecosystems that ship the most software. The shift is documented, the tooling is production-grade, and the holdouts are mostly organizations that have not reviewed their signing strategy since the early 2020s.
What Was Wrong With Traditional Signing?
The fundamental problem was that the security of the signature depended on the security of a long-lived secret, and long-lived secrets are operationally brittle.
Key compromise was catastrophic. If a signing key leaked, every artifact signed with it became untrustworthy. Recovery required issuing a new key, re-signing everything in flight, and somehow communicating the compromise to every downstream consumer. In practice, this was done rarely and poorly.
Key rotation was painful. Best practice said to rotate signing keys on a regular cadence. Actual practice was to avoid rotation as long as possible, because each rotation required downstream consumers to update their trust anchors. The mismatch produced keys that were in use for years past their intended lifetimes.
Key custody was a weak link. Keys in HSMs were relatively safe but expensive and inflexible. Keys in CI/CD environments were convenient but sitting in blast radius of compromised build systems. Keys on developer workstations were — well, we all know how that went.
Identity binding was weak. A signature told you the artifact was signed by a holder of a particular key. It did not tell you who, exactly, that holder was, or whether they were authorized to sign the particular artifact. The mapping from key to identity lived in external systems and was often out of date.
These problems were tolerable in the 2010s because the alternative was worse. They are not tolerable in 2026 because the alternative is better.
What Does Keyless Signing Actually Do?
The keyless model reframes the problem. Instead of trusting a long-lived key, you trust an ephemeral certificate issued at signing time by an authority that verifies the signer's identity. The signature is recorded in a tamper-evident transparency log. The certificate itself is short-lived — on the order of minutes — so compromise is bounded.
The architecture, in the Sigstore instantiation, involves three components:
An OIDC-based identity provider asserts who the signer is. This might be a GitHub Actions workflow, a Google account, or a corporate SSO identity. The assertion is what it always was, just applied at signing time.
A certificate authority (Fulcio, in the Sigstore ecosystem) issues a short-lived certificate binding the signer's identity to a freshly generated key pair. The key pair exists only for the signing operation and is discarded immediately afterward.
A transparency log (Rekor) records the signature immutably. Anyone can inspect the log and verify that a given signature was actually made by the claimed identity at the claimed time.
Verification consumers check three things: the signature is valid for the artifact, the certificate's identity matches what they expect, and the signature is present in the transparency log. No long-lived keys anywhere in the trust path.
But Doesn't This Just Move Trust to the Identity Provider?
Yes, and that is the correct place for it to live. The identity provider is already the source of truth for authentication at most modern organizations. Adding signing to the identity layer consolidates trust rather than multiplying it.
The specific question — can the identity provider be compromised? — is a real one, but it is the same question you already had to answer for every other use of that identity. If your IdP is good enough to gate production deployments, cloud access, and source code reads, it is good enough to gate signing. If it is not, you have a larger problem than signing.
The other advantage: the identity provider naturally supports the kinds of fine-grained assertions signing actually needs. "This artifact was signed by CI run 12345 on repository X, triggered by commit Y" is a richer and more verifiable statement than "this artifact was signed by a holder of key Z." The richness is what enables real policy decisions downstream.
How Do You Build Policy on Top of Keyless Signatures?
This is where keyless signing stops being a cryptographic novelty and starts being an operational superpower.
A downstream consumer — say, a production deployment system — can require that every deployed artifact was signed by a specific GitHub Actions workflow on the main branch of a specific repository, that the signature is less than 24 hours old, and that the corresponding transparency log entry exists. This is a policy that cannot be expressed with long-lived keys; the key itself has no concept of which workflow or which branch produced it.
Policies like this shut down entire categories of attack. A developer who compromises their workstation cannot produce artifacts that deploy to production, because their local identity does not match the required workflow. A CI job running on a feature branch cannot produce signed artifacts, because the branch does not match. An attacker who compromises a maintainer's PAT cannot backdate signatures, because the transparency log timestamp is adversarial to the attacker.
The combination of identity-bound signing and transparency logging gives you verifiable statements about how an artifact was built, not just who built it. That is the property that actually stops supply chain attacks.
Is Keyless Ready for Air-Gapped and Regulated Environments?
Mostly yes, with caveats.
For air-gapped environments, the central Sigstore infrastructure is obviously not reachable. Private deployments — Fulcio and Rekor running inside the organization — are available and increasingly production-grade. The trust root shifts from the public good instance to the private one, which is both a cost (you now run the CA and log) and a benefit (you control the trust anchor).
For regulated environments, the story is improving quickly. FedRAMP-aligned deployments exist, signatures are recognized in SLSA level 3 and above, and the major compliance frameworks have updated their language to accommodate ephemeral signing. The remaining gaps are mostly auditor familiarity — if your auditor has not heard of keyless signing, explaining it takes a meeting.
The one environment where keyless still struggles is offline signing of physical media — medical devices, aerospace firmware delivered on sealed hardware. The fundamental model assumes network-available identity verification, which does not fit those workflows. For those cases, HSM-backed long-lived keys remain the right answer, and probably always will. That is a small fraction of the software supply chain.
What Should Organizations Do in the Next Twelve Months?
Three concrete steps, in order.
First, catalogue your current signing infrastructure. Which keys exist, where they live, who has access, and what they sign. This is usually an uncomfortable exercise because the answers are worse than people expect.
Second, adopt keyless signing for new projects by default. New CI/CD pipelines, new release processes, new service deployments — start them on keyless and treat long-lived keys as an exception requiring justification.
Third, migrate existing signing workflows on a ranked basis. The highest-risk, highest-volume signing workflows migrate first. The long tail of one-off release scripts migrates over the next 18 to 24 months. A small remainder of genuinely offline workflows stays on HSM signing indefinitely.
Throughout, invest in verification. The value of signing is realized downstream, when consumers actually verify the signatures they receive. A signed artifact with no verification policy is decorative. Build the verification into deployment gates, into package install flows, and into vendor acceptance processes.
How Safeguard.sh Helps
Safeguard.sh is built on the assumption that keyless signing and transparency-log-backed provenance are the baseline, not the aspirational state. The platform verifies signatures and attestations on every artifact it ingests, cross-references them against transparency logs, and enforces identity-bound deployment policies — "this artifact must be signed by workflow X on repo Y, and the signature must be less than N hours old." Private Sigstore deployments are supported for air-gapped environments. Long-lived keys remain supported where they are unavoidable, but the product defaults steer organizations toward the architecture that has already won in the ecosystems that matter. Signing is one of the areas where the right answer changed meaningfully in the last five years, and the platform reflects that.