We at Microsoft are committed to providing customers with a secure ecosystem of tools for building and deploying applications. As part of this commitment, we continuously update our Java container image offerings to ensure they meet the highest security standards.

Back in January 2022, we announced the End of Updates for the Azul Zulu for Azure build of OpenJDK. As part of that announcement, we shared that Microsoft and Azul Systems were no longer going to provide further updates, security patches, and support for this specific Azul Zulu for Azure build of OpenJDK. Since then, we have updated Azure Platform services and have encouraged customers to transition to the Microsoft Build of OpenJDK or other supported OpenJDK distributions, including Azul Zulu, to ensure customers continue to receive security updates and benefit from the latest enhancements in Java. Additionally, Microsoft and Azul have also ended the availability of the binaries of Azul Zulu for Azure for direct download.

While many customers have already migrated to supported options, Azul Zulu for Azure has remained available through container images in the Microsoft Container Registry (MCR). Unfortunately, our registry telemetry indicates that these outdated and insecure container images of Azul Zulu for Azure build of OpenJDK continue to be downloaded. An example of an image that continues to be pulled is mcr.microsoft.com/java/jdk:11-zulu-ubuntu. The full list of outdated images are under the mcr.microsoft.com/java/ path and can be found in our End of Updates article from 2021.

After careful consideration, we have decided to remove these outdated, end-of-life Java related container images of Azul Zulu for Azure builds of OpenJDK from our repositories on June 30th, 2025. This action is critical to safeguarding your systems and ensuring you are building your applications on robust, up-to-date foundations.

Your security is our priority. Outdated images may expose your systems to vulnerabilities that are no longer patched. Removing these images eliminates the risk of inadvertently building on insecure foundations. We understand that some customers may discover their usage of these images only after encountering build errors due to these images no longer being available. While this can be inconvenient, it is a valuable opportunity to audit your systems and ensure alignment with secure, up-to-date resources.

Which container images for Java workloads should customers be using on Azure?

Customers should be using container images published and maintained by the Microsoft Build of OpenJDK team. More information can be found in the documentation.

Which container images are being deleted?

All images under mcr.microsoft.com/java/ will be affected and subject to deletion. Tags will include, for example:

• microsoft.com/java/jdk:11-zulu-alpine
• microsoft.com/java/jre:8-zulu-alpine
• microsoft.com/java/jre-headless:7-zulu-centos
• microsoft.com/java/maven:3.8-zulu-debian10
• microsoft.com/java/tomcat:10-zulu-ubuntus
• And 1,800 more.

There are over 1,800 tags published under mcr.microsoft.com/java/ and all of them will be deleted on June 30th, 2025. If your system is using any of these, make sure to update your system accordingly. Alternatives to these images can be found in the End of Updates announcement from 2021.

Audit your pipelines. Review your build and deployment pipelines to identify any dependencies on mcr.microsoft.com/java/ images. Ensure you are using images with active support and regular updates.

Challenges in Communicating End of Life (EOL) for Container Images

One of the complexities we have faced with in tackling this issue, is the lack of a standard mechanism for container image publishers to communicate End of Life (EOL) notices effectively to image consumers. Container images are often consumed through automated pipelines and container orchestration platforms. Many users may unknowingly continue to pull and deploy deprecated images for lack of proper and continuous security auditing and inspection.

Additionally, other commonly scenarios also do not provide proactive security information.

• The docker pull command does not inform the user when an image has reached EOL, or even if a given image has security issues (e.g. CVEs).
• Registries currently do not provide a watching mechanism to receive automated notifications or alerts for security issues, deprecated images, or EOL statuses.
• Notifications are often provided through READMEs and Overview pages of container images, drafted by container images authors themselves.
• Image consumers must proactively and manually track the support status of the images they use, requiring significant effort and coordination across development and operations teams.

There is a subtle yet important distinction between CVEs and End-of-Life metadata. While images may not have any security vulnerabilities, they could still reach their end-of-life, and container image security scanners typically focus on identifying CVEs only. That said, we would like to share how customers can improve their systems to detect both types of issues.

Identify CVEs in container images

Identifying Common Vulnerabilities and Exposures (CVEs) in container images is essential for ensuring secure deployments. Docker Scout is a powerful and user-friendly tool designed for this purpose, enabling you to scan container images for known vulnerabilities effortlessly. It integrates smoothly with your Docker environment and existing workflows, making it easy to identify and address security issues. With a simple command, Docker Scout analyzes the layers of a container image and generates a comprehensive CVE report. To begin scanning your container images, make sure Docker Scout is installed. If you’re using Docker Desktop, Docker Scout is already included and accessible through the “Docker Scout” tab in the Docker Desktop dashboard. From there, you can view a detailed security report like this:

To integrate Docker Scout in your CICD pipeline, use the following command to scan an image:

docker scout cves <image-name>

For example, let’s scan one of the images we are planning to delete:The results include actionable insights, such as which packages are affected and how to mitigate the vulnerabilities. For example, if the CVEs are in a base image, updating to a more recent version or switching to a different, secure base image can resolve the issues. By regularly running this as part of your CI/CD pipeline, you can proactively identify and address vulnerabilities before they reach production, ensuring your containerized applications remain secure.

Continuous inspection of container images End of Life metadata with ORAS 

The ORAS CLI introduces a way to attach and discover lifecycle metadata. This includes EOL metadata, which can provide critical insights about the lifecycle of a consumed image. By leveraging the ORAS CLI, consumers can inspect this metadata programmatically in an automated fashion.

• Microsoft uses ORAS to attach lifecycle artifacts (e.g., application/vnd.microsoft.artifact.lifecycle) to images, indicating their EOL date, deprecation warnings, or replacement recommendations.
• Be aware that other vendors may use different annotations.
• The ORAS CLI can be integrated into CI/CD pipelines to periodically inspect consumed images, helping identify deprecated or end-of-life images early in the development lifecycle.

Customers can run the following command to obtain the end-of-life notices for container images on Microsoft Container Registry:

oras discover --format json --artifact-type "application/vnd.microsoft.artifact.lifecycle" <image>

The above command will give an output similar to this below:

By integrating tools like ORAS into their workflows, organizations can stay ahead of lifecycle issues, ensuring their applications remain secure and up-to-date. However, to truly address the challenges, the container community must push for broader adoption of lifecycle standards and built-in registry mechanisms to bridge the gap in EOL communication.

Shared Responsibility for a Secure Ecosystem

As we move toward the removal of outdated and insecure images on June 30th, 2025, we recognize that this action, while necessary, also underscores the broader challenges of managing container image lifecycles. Our primary goal is to ensure that your systems remain secure and resilient, and we are here to support you through this transition. This change is a timely opportunity to audit your dependencies, integrate lifecycle inspection with tools like Docker Scout and ORAS, and adopt modern, supported container images. By doing so, you not only align with industry best practices but also strengthen your systems against potential vulnerabilities.

We urge the container ecosystem to collectively address the limitations in EOL communication. Standardized lifecycle metadata, registry-based notifications, and automated mechanisms for alerting consumers to image deprecations are critical to ensuring that the ecosystem evolves to meet the needs of its users. For any questions, concerns, or guidance, please contact our support team. Together, we can build a secure, sustainable future for containerized applications.

Thank you for your understanding and continued trust in Microsoft.