Maven Central is the default registry for every Java build in the world that uses Maven or Gradle with public dependencies. Changes to Maven Central's operating rules therefore affect millions of builds, and 2024 was the most consequential year for those rules in the last decade. Sonatype, which operates Maven Central, implemented several changes — tightened publishing requirements, namespace provisioning updates, signing expectations, retention policy adjustments — that together shifted the baseline posture of the Java supply chain. Most of the changes are net positive for security; some introduced operational pain for publishers. This post walks through what changed in 2024, what it means for consumers, and what it means for anyone publishing Java artifacts to Central.
What is the new publishing portal and what changed?
Sonatype rolled out a new publishing portal in 2024 to replace the legacy OSSRH (OSS Repository Hosting) system that had been the entry point for Maven Central publishers since 2009. The new portal tightens several things: namespace claims are faster and better audited, publishing credentials rotate more predictably, and the upload path uses a simpler signed-artifact submission rather than the staging/release workflow OSSRH used. For consumers, this is mostly invisible — the resulting artifacts in Central are the same. For publishers, the migration was a real project, and some long-inactive namespaces were consolidated or reclaimed during the transition.
The operational effect on the Java ecosystem was a temporary increase in publishing friction through mid-2024 as teams migrated, followed by faster and more reliable publishing once the migration was complete.
What changed about namespace ownership and verification?
Namespace verification got stricter. Claiming a group ID (e.g., com.yourcompany) now requires stronger proof of ownership — either DNS verification for domain-based group IDs or GitHub verification for io.github.username group IDs. This was always policy but inconsistently enforced; the 2024 enforcement is more uniform. For security, this closes a long-tail concern where weak ownership claims could potentially enable namespace squatting.
The downstream effect: teams whose group ID claim is weak (e.g., based on a lapsed domain) may find their ability to publish under that group ID contested or revoked. This is a small but real operational risk for old, rarely-published projects.
What are the signing expectations now?
Artifact signing with GPG has been a long-standing Central requirement. In 2024 Sonatype began more actively validating that signatures check against published keys and that keys have not been revoked. Submissions with invalid or revoked signatures now fail the publish pipeline rather than landing and being flagged after the fact.
Sigstore/cosign signing remains non-mandatory but the conversation about adding it as an optional additional signature format gained traction through 2024 — no concrete requirement yet, but planners should expect it within 18–24 months.
What about artifact retention and immutability?
Maven Central's immutability guarantee — once published, an artifact with a given coordinate cannot be overwritten — remained intact through 2024 and was reinforced. Unpublishing is explicitly not supported except in narrow malicious-content scenarios, which continues to be the correct design choice because consumers' reproducible builds depend on it. The change in 2024 was better documentation of the narrow cases where Sonatype will take down an artifact, and faster response when they do.
For consumers this is reassurance. For publishers this is a reminder that publish-time mistakes are forever.
How does this affect dependency confusion risk for Java?
Net positive but not eliminated. Dependency confusion in the Maven ecosystem has always been relatively constrained compared to npm because the group ID provides a strong namespace signal and most enterprise Java environments already use a private repository (Artifactory, Nexus) with configured upstream routing. The 2024 namespace verification tightening further reduces the attack surface for new group ID claims.
What remains: enterprises whose internal Java artifacts use a group ID that is technically available on Central (not registered) can still be attacked by a malicious registration of that group ID on Central, if the internal build resolves against Central before the private repo. The mitigation is the same as ever — configure your build tool to resolve private namespaces first, and register those namespaces on Central as defensive claims even if you don't publish there.
What about the SBOM and provenance direction?
Sonatype has publicly committed to SBOM availability for Central-hosted artifacts on a roadmap through 2024 and 2025, and partial rollout began in late 2024. Artifacts published with accompanying SBOM metadata are visible in the registry metadata; retrofit for older artifacts is not planned — only new publishes will have SBOMs.
Provenance attestations (SLSA-style) are not yet a Central feature. The work on in-toto provenance for Maven artifacts is active in the OpenSSF working groups but has not landed as a Central feature. Expect motion here in 2025.
What should Java teams be doing as a result?
Five concrete moves:
- Audit your group ID claims. If you publish to Central, verify your group ID ownership proof is still valid. If you use
io.github.*IDs, check that the backing GitHub accounts are still controlled by your organization. - Re-verify signing key publication. Make sure your published GPG public key is on the expected keyservers, has not expired, and is rotated on a schedule.
- Migrate off OSSRH if you haven't. The legacy system is being phased out; new publishes should use the new portal.
- Configure private repo resolution order. Ensure internal artifacts resolve against your private repo before Central, and register internal namespaces defensively on Central.
- Opt into SBOM publishing. As the feature rolls out, publish SBOMs alongside artifacts. Consumers increasingly expect them.
What about the Gradle Plugin Portal?
A parallel ecosystem with different rules. The Gradle Plugin Portal is not directly affected by Maven Central changes, but Gradle plugins' runtime dependencies typically resolve against Central. Plugin publishing rules have their own verification gates; the 2024 changes on Central did not immediately propagate, but expect alignment over time.
How Safeguard Helps
Safeguard's SBOM module ingests Maven Central metadata — including the new SBOM payloads as they become available — and correlates them with the reachability graph of Java applications consuming those artifacts. Policy gates can require valid signature verification and namespace ownership proof before allowing a dependency into a production build. Griffin AI surfaces group ID ownership risks, expiring GPG keys, and artifacts with weak provenance signals, so the operational hygiene this post describes is a platform output rather than a per-team checklist. For Java-heavy organizations navigating the 2024 Central changes, Safeguard provides a single view of which artifacts meet the new posture and which don't.