The Maven Central migration away from long-lived GPG keys toward Sigstore-based signing has been one of the slower-moving supply chain stories in the Java world, and for good reason. Central is a twenty-plus-year-old infrastructure, serving an ecosystem with deep reproducibility requirements and a lot of tooling that assumes GPG. A rushed migration would have been worse than the status quo. In 2026 the migration is real, and teams that last looked at this in 2024 will be surprised by how much has changed.
What is Sonatype actually doing with Sigstore in 2026?
The Central Portal supports Sigstore-based signing as a first-class alternative to GPG for new and existing publications. The Gradle and Maven plugins that Sonatype and the community maintain can produce Sigstore bundles alongside or in place of detached GPG signatures. Verification tooling on the consumer side is improving but still lags the publisher-side story by a visible margin.
What is not happening is the deprecation of GPG. Sonatype has been explicit that GPG signatures are not going away for the foreseeable future, because the installed base of builds that verify GPG is enormous and unmovable. The current direction is dual-signing: publishers attach both a GPG signature and a Sigstore bundle, consumers verify whichever they have tooling for, and over a long horizon the Sigstore side becomes the primary trust anchor. In 2026 we are still early in that long horizon.
Why did Maven take so much longer than npm or PyPI?
Three reasons, all structurally interesting. First, the Java build toolchain is older and more federated than Node's or Python's. There is no single CLI that ninety percent of users run; there are Maven, Gradle, sbt, Leiningen, Bazel, and each has its own plugin ecosystem for signing and verification. Second, Maven's dependency resolution is stricter about artifact integrity in ways that make wholesale changes to the signature format risky. Third, the Java community has a long tail of users who cannot update their tooling quickly, including large enterprises that still run builds on Java 8 with plugin versions pinned from five years ago.
The result is a migration that looks slow from the outside but is actually proceeding at close to the maximum speed the ecosystem can absorb. If Sonatype had forced a flag day, they would have broken builds across a huge fraction of the enterprise Java world, and the political fallout would have set the migration back years.
Should you adopt Sigstore signing for your own Maven artifacts today?
If you publish to Central and you have control over your CI pipeline, yes. The dual-signing approach costs you almost nothing: configure your publish workflow to generate both GPG and Sigstore signatures, attach both, and let consumers use whichever they prefer. You get the transparency-log guarantees of Sigstore for the consumers that verify it, and you keep GPG compatibility for everyone else.
The setup is a one-time investment of maybe a day for a small library, more for a complex multi-module build with existing signing conventions. The Sonatype docs have gotten genuinely good in the last year. The most common friction points are OIDC configuration in CI, which is exactly the same problem you would hit migrating to npm provenance or PyPI trusted publishing, and Gradle plugin compatibility, where older Gradle versions have known bugs in the Sigstore plugins.
How should consumers verify Sigstore signatures on Maven artifacts?
This is where the tooling is still catching up. Maven itself does not have a first-class Sigstore verification step in the default resolver pipeline. Gradle's support is better but not universal. For most teams the pragmatic pattern in 2026 is a CI-side verification step that runs after dependency resolution and before deployment: fetch the Sigstore bundles for critical dependencies, verify them against your allowlist of trusted workflow identities, and fail the build if verification fails for anything on your watchlist.
The dependency graph for a typical Java application is large enough that verifying everything is impractical, so you end up with a tiered approach. High-trust dependencies get full Sigstore verification. Second-tier dependencies get GPG verification and SBOM-based policy checks. Third-tier dependencies get standard SCA scanning. The tiering is a policy decision, not a technical one, and every Java shop doing this thoughtfully has a slightly different tier definition.
What happens to the existing GPG keys and keyserver infrastructure?
They stay. The keyserver situation for Maven-adjacent GPG keys has been operationally unpleasant for a decade, with the keyserver SKS network effectively defunct and replacements like keys.openpgp.org working but differently. Sonatype has moved to host keys directly alongside artifacts for Central-published signatures, which sidesteps most of the keyserver pain for Central users but leaves the broader GPG ecosystem in its usual precarious state.
The practical guidance is to not invest in GPG-specific supply chain tooling for Java artifacts in 2026. Keep your GPG verification working because the installed base requires it, but do not build new controls on top of GPG that you expect to still be running in five years. The direction of travel is clear, even if the timeline is long.
How does reproducible build verification fit in?
Reproducible builds are a related but separate concern. Sigstore tells you who built an artifact and when; reproducibility tells you that anyone else building the same source produces the same bytes. Both together are the strong property, and the Java ecosystem has been moving on both fronts in parallel. Reproducible Maven builds have gotten noticeably more common in critical libraries over the past two years, and the combination of a Sigstore-attested build plus a reproducible build gives you real supply chain assurance.
The catch is that neither is universal and neither is on by default. For your own publications, push for both. For your consumed dependencies, treat the presence of either as a positive signal and the presence of both as a strong positive. Tools like rebuilderd give you a way to independently verify reproducibility claims, though running them at scale is a nontrivial operational commitment.
What about internal Maven repositories like Nexus and Artifactory?
Both Sonatype Nexus Repository and JFrog Artifactory have Sigstore support in reasonably current versions, but as with the other ecosystem tools, the handling of signatures when proxying is uneven. Older versions silently strip Sigstore bundles from proxied artifacts, which then fails verification on the consumer side in ways that are hard to debug. If you operate an internal Maven repository, check your version against the vendor's current changelogs specifically for Sigstore handling, and test the end-to-end verification flow against your actual configuration rather than trusting the marketing page.
The internal repository is also the right place to enforce your dual-signing policy for first-party artifacts. Reject publications that are missing either signature type, and you avoid the situation where a rushed internal release goes out with partial signing that someone has to retroactively fix later.
How Safeguard.sh Helps
Safeguard.sh tracks Sigstore adoption across your Java dependency graph, verifies both GPG and Sigstore signatures where available, and flags dependencies whose signing posture has regressed between versions. We help you build the tiered verification policy that maps to your actual risk tolerance, and we surface mirror and proxy configurations that silently strip Sigstore bundles from proxied artifacts. The outcome is a Maven supply chain posture that reflects where the ecosystem is actually moving, not where the tooling defaults have been stuck.