Choose keyless signing when your CI has an identity provider and you can reach Sigstore. Choose a KMS or Vault key when you need keys under your control or must sign without public services. Choose a plain key pair only for small, low risk cases where you can protect the file.
What each model means
Sigstore's docs say identity based signing is the default, because managing and distributing keys securely is hard. Keyless signing associates an identity, not a key, with a signature: a certificate authority issues a short lived certificate binding an ephemeral key to an OIDC identity, and the signing event goes in the Rekor log.
Cosign can also use external key stores. The key management page lists AWS KMS, GCP KMS, Azure Key Vault, HashiCorp Vault, OpenBao, OVHcloud KMS and Kubernetes Secrets.
Comparison
| Keyless | KMS or Vault key | Local key pair | |
|---|---|---|---|
| Who holds the private key | Nobody, it is ephemeral | Your key service | A file you protect |
| What verifiers check | Identity and issuer | A public key | A public key |
| Needs public Sigstore services | Yes, for public instance | No | No |
| Rotation burden | None for keys | Yours | Yours |
| Audit trail | Public log entry | Your KMS logs | Little by default |
| Works air gapped | Needs private deployment or offline bundle plan | Yes | Yes |
Decision guide
- Public open source project with CI on a major platform: keyless fits well. Verifiers check your repository workflow identity.
- Private software with strict data rules: a KMS key keeps signing inside your cloud boundary. Note that keyless public logging can expose emails or repository names in certificates.
- Disconnected environment: use a KMS, Vault or a private Sigstore deployment you run.
- Prototype: a local key pair is fine, but do not ship it to customers without a plan for storage and rotation.
Practical details for KMS keys
- Generate the key in the provider with the generate key pair command and a provider URI.
- Export the public key and verify with the file, so verification does not call the KMS each time.
- For AWS, the docs warn that key creation is not supported through cosign with key ARN or key ID forms, and recommend aliases.
- Kubernetes Secrets storage keeps the private key and password in one secret, so review cluster access carefully.
What to verify, whichever you choose
Keyless: certificate identity and issuer. Key based: that the public key is the one you published, through a channel an attacker cannot rewrite. In both cases, verify the digest you deploy.
What signing alone does not do
None of these choices prove the code is safe. They prove who signed.
Where Safeguard fits
Safeguard's policy gates and SBOM scanning sit beside signing as a check on content, and compliance and evidence automation helps document the controls you chose.
Quick check
Can I switch models later?
Yes, but consumers must learn the new verification rule. Publish the change and keep the old key or identity trusted for old releases.
Is keyless less secure than a KMS key?
They fail differently. Keyless removes stored keys but trusts identity providers and the CA. A KMS key trusts your cloud access controls.
Sources
Last reviewed: 19 October 2026.
