On January 28, 2025, Sonatype announced that the Central Publisher Portal had begun validating Sigstore signature bundles for artifacts published to Maven Central. The change is incremental rather than revolutionary, layered on top of the existing PGP signature requirement that Maven Central has run since the early 2010s, but the direction it sets is significant: Java is finally on a path to the same OIDC-backed, transparency-log-anchored provenance story that PyPI and npm have shipped. This post walks through what the new validation actually does, how the rollout fits with the broader namespace-verification work the Central Publisher Portal has shipped, and how a consuming organization should be reading and verifying the Java-ecosystem signals in 2026.
What did Maven Central actually change?
The Central Publisher Portal now accepts .sigstore.json Sigstore bundle files alongside the artifacts in a publishing bundle. When a publisher uploads a bundle that includes Sigstore signatures, the portal validates them against the Sigstore public-good Rekor transparency log and shows a warning if the signature is invalid. Crucially, Sigstore signatures are not yet required: a publisher can continue to publish using only the existing PGP signature, and the portal does not reject missing Sigstore signatures. The Sonatype announcement is explicit that invalid Sigstore signatures will eventually block publishing, but missing signatures will not, preserving the option for publishers who do not yet have OIDC-based CI infrastructure. PGP is also not going away: the Sonatype team's blog post explains that PGP has served the repository well and any replacement decision will depend on Sigstore adoption rates over the coming years.
How does this fit with namespace verification?
Maven Central's namespace model is older and stricter than npm's flat package namespace, and that turns out to be an asset for defenders. To publish to Maven Central, a publisher must own a Maven coordinate prefix (groupId) and prove ownership: typical proof is a DNS TXT record under the prefix's domain, or for io.github.<username> prefixes, an automatic verification through GitHub account ownership. The Central Publisher Portal documentation explains that the io.github shortcut lowers the friction for individual publishers while still tying every published artifact to a verified identity. Combined with PGP signatures and now Sigstore validation, the result is that any artifact in Maven Central carries three trust-relevant claims: a verified namespace, a publisher PGP signature, and (optionally) a Sigstore attestation that ties the build to its CI workflow.
What signals can a consumer read on a Maven artifact in 2026?
Four signals appear in the Maven Central metadata and in the artifact bundle itself. The first is the verified namespace, evident from the groupId being one the publisher demonstrably controls. The second is the PGP signature file (.asc), which has been the canonical signature mechanism for Java artifacts for over a decade. The third, new in 2025, is the Sigstore signature bundle (.sigstore.json), present for publishers who have adopted the new flow. The fourth is the Sonatype-issued repository metadata, which records the publisher account and the verification status. A consumer can verify all of these directly against the artifact rather than relying on a registry-side claim, which is unusually strong relative to the npm or PyPI model where the registry is the canonical source of truth.
How do you verify a Maven artifact in CI?
The defender pipeline combines a PGP verification step (long-standing) with a Sigstore verification step (new in 2025-2026). For Sigstore, the sigstore-maven-plugin published at dev.sigstore:sigstore-maven-plugin provides Maven-native verification.
<!-- pom.xml plugin entry to verify Sigstore signatures during build -->
<plugin>
<groupId>dev.sigstore</groupId>
<artifactId>sigstore-maven-plugin</artifactId>
<version>1.4.0</version>
<executions>
<execution>
<id>verify</id>
<goals><goal>verify</goal></goals>
<configuration>
<identityRegex>^https://github.com/upstream-org/.+</identityRegex>
<oidcIssuer>https://token.actions.githubusercontent.com</oidcIssuer>
</configuration>
</execution>
</executions>
</plugin>
For PGP verification, the existing Maven workflow (mvn verify with the gpg:verify goal) continues to work. For SBOM-level checks, the CycloneDX Maven plugin produces a build SBOM that can be cross-referenced against vulnerability and malicious-package feeds the same way the npm and PyPI workflows do.
# Generate a CycloneDX SBOM for the build's resolved dependencies
mvn org.cyclonedx:cyclonedx-maven-plugin:makeAggregateBom
# Cross-check the SBOM against vulnerability and malicious-package feeds
grype sbom:target/bom.json
What policy gate catches the next Maven-side incident going forward?
Three gates align with the layered trust-signal stack. Gate one is "require valid PGP signatures matching a publisher allow-list for any production dependency," which the Maven ecosystem has supported for years but many organizations leave unenforced. Gate two is "prefer Sigstore-attested artifacts when available and alert on artifacts that lack Sigstore signatures for selected tier-one dependencies," a softer gate that reflects the in-progress migration. Gate three is "verify the namespace ownership chain for any new groupId," which catches the rare but real cases where a previously legitimate publisher's namespace transfers to a new owner. Maven Central has historically been less attractive to attackers than npm because of the higher friction and stronger namespace model, but defender posture should not assume that comparative advantage persists indefinitely.
What did the broader Java ecosystem teach about migration pace?
Two observations from the 2025-2026 rollout window are worth recording. The first is that publisher adoption of new signature mechanisms is slow in mature ecosystems. PGP has been the de facto standard for so long that many publishers have key-management workflows built around it, and shifting to Sigstore requires updating CI configuration, build plugin versions, and sometimes core build tooling. Sonatype's deliberate choice to validate Sigstore without requiring it gives publishers time to migrate without breaking the existing flow. The second is that the io.github automatic-namespace shortcut measurably increased individual-publisher participation in Maven Central, which is an instructive defender-relevant pattern: lowering the publishing-side friction for verified identities produces better outcomes than raising the friction for everyone.
What still has to mature?
Two gaps remain visible. The first is the lag in publisher adoption of Sigstore: Maven Central has begun validating but not requiring Sigstore signatures, which means consumer-side verification is opt-in until adoption rises enough to justify enforcement. The second is the SBOM and provenance pipeline integration for Java builds. Tools like the CycloneDX Maven plugin and the Sigstore Maven plugin work well in isolation, but integrating them into the larger SLSA-style provenance story still requires careful CI configuration that many Java teams have not yet done. The OpenSSF SLSA project has published Java-specific guidance, but the long tail of Java projects that build with custom Ant or Gradle configurations is large.
How Safeguard Helps
Safeguard's Maven Central support reads PGP signatures, Sigstore attestations, and namespace verification metadata for every Java artifact in your tenant's SBOMs. Per-tier policies can require PGP signatures from a publisher allow-list, prefer Sigstore-attested artifacts for selected critical dependencies, and alert on any new groupId added to the dependency graph. The provenance verification engine consumes Sigstore bundles from Maven Central alongside the equivalent signals from npm, PyPI, RubyGems, crates.io, and NuGet, giving defenders a single policy grammar across every ecosystem in their stack. Malicious-package feed integration covers Maven Central removals and the GitHub Advisory Database, and the CycloneDX SBOM pipeline feeds directly into the policy gate evaluation. The build-time integration uses the Sigstore Maven plugin's verification output as a policy input, so a build that resolves a tier-one dependency without a valid attestation can be failed at the policy-gate step rather than allowed silently. The result is that the Java ecosystem's gradual migration toward Sigstore translates into actionable, auditable policy from day one of any tenant adopting Safeguard.