Sigstore keeps Rekor v1 as its public default

Sigstore announced on June 28 that its public-good service will keep Rekor v1 as the default transparency log for the foreseeable future. The project update says Rekor v2 remains available in production and supported by modern verification clients, but making it the default would introduce breaking client behavior.

Compatibility changed the rollout

Rekor v2 offers infrastructure advantages and handles large DSSE envelopes through a hashed-record flow, yet its client behavior differs from v1. Sigstore chose to avoid forcing that disruption now, noting that a future post-quantum cryptography transition will bring another breaking change. Combining transitions may reduce the number of migrations imposed on ecosystem users.

Teams should read this as a configuration boundary. Existing users of Sigstore’s distributed signing configuration remain on the public default. Ecosystems that control both signing and verification may opt into v2, but the project says they should consume current configuration through TUF rather than hard-code rotating log URLs.

Verify both sides before opting in

The dangerous migration sequence upgrades signers before every verifier understands the resulting bundles. That can produce valid new signatures that older deployment gates reject. Inventory all verification points—including admission policy, package publishing, offline verification, and audit tools—before changing the signing configuration.

A controlled test signs a disposable artifact through the v2 path and verifies it with each supported client version in the organization. Retain the bundle and verification output as migration evidence.

Sigstore’s decision favors predictable ecosystem behavior over an automatic cutover. Rekor v2 is still available for adopters that need it, but opting in becomes an explicit compatibility project rather than a background service change.