Third-Party SAM Tools and Oracle Java Audits: What's Accepted and How to Use Them in 2026

The Oracle Java Audit Landscape in 2026

Since Oracle's January 2023 Java SE subscription model change, the company's License Management Services team has substantially accelerated audit activity. Oracle Java audits doubled in volume through 2024 and continued at elevated rates into 2025 and 2026. The driver is straightforward: Oracle's new employee-headcount metric creates dramatically larger theoretical licensing obligations for most enterprises than the prior processor or named-user metrics, and Oracle's LMS team is systematically working through its installed base to convert that theoretical exposure into contracted subscription revenue.

The mechanics of the new metric bear repeating because they underpin the entire audit strategy. Under Oracle's 2023 subscription model, every organisation running any Oracle JDK installation — on any server, workstation, virtual machine, or container — must licence all employees in the organisation. Not the machines running Java. Not the users interacting with Java applications. All employees. A company with 15,000 employees and three Java-running servers has the same subscription obligation as a company with 15,000 employees and 3,000 Java-running servers.

This metric design creates enormous leverage for Oracle in audit conversations. The discussion shifts from "how many deployments can we account for" to "what is your total headcount" — a number Oracle can find from public filings even before any audit data is collected. SAM tools are essential in this environment not because they resolve the headcount question, but because they establish whether Oracle JDK is present at all and in what form, which determines whether the obligation arises in the first place.

Oracle-Verified SAM Tools: The 2026 Landscape

Oracle's SAM tool verification programme confirms that a tool's Java discovery data collection meets Oracle's standards for audit evidence. The key distinction is that verification covers discovery accuracy — not licence position calculation or compliance determination. As of 2026, five SAM tools carry Oracle verification for Java SE discovery.

Flexera One (incorporating Snow Atlas)

Following the Flexera-Snow merger, Flexera One has become the market's most comprehensive Oracle-verified SAM platform. It carries verified status across Oracle Database, Database Options, Oracle Fusion Middleware, Java SE, and Oracle E-Business Suite. For Java SE specifically, Flexera One automatically applies Oracle's recognition rules, distinguishes Oracle JDK from third-party OpenJDK distributions at the distribution level, and generates discovery reports in Oracle's preferred audit submission format. Its normalisation logic for Java SE is updated on a regular cycle as Oracle's product catalogue evolves.

For organisations with complex, mixed Oracle and non-Oracle environments, Flexera One provides the deepest Oracle-specific intelligence of any commercial SAM platform. The configuration investment is substantial — correctly configuring agent coverage, Java distribution recognition, and licence position rules for a large enterprise estate typically requires dedicated specialist time — but the resulting data quality is consistently the most defensible in audit contexts.

ServiceNow SAM Pro

ServiceNow SAM Pro achieves Oracle-verified Java SE discovery through the ServiceNow Discovery agent and CMDB data model. For organisations that have made ServiceNow their standard ITSM platform, SAM Pro delivers Java discovery integrated with existing asset and configuration data — reducing the need for additional agent deployments. Its Oracle-specific licensing rules require more manual configuration than Flexera, but ServiceNow's platform strength and broad enterprise adoption make it a practical choice for ServiceNow-standardised environments. USU Software Asset Management and Certero for Oracle round out the verified landscape with specialised capabilities for European enterprise and Oracle-focused environments respectively.

Where SAM Tool Verification Ends

The single most important thing to understand about Oracle's SAM tool verification programme is what it does not cover. Oracle verifies that the tool collects Java discovery data accurately. It does not verify that the tool correctly determines the licensing obligation arising from that discovery data, and it does not commit Oracle to accepting the tool's output as binding on the audit outcome.

This matters in practical terms because SAM tools cannot automatically apply all the factors that determine whether a specific Java installation creates a subscription obligation. Those factors include: the specific Java distribution installed (Oracle JDK versus any of the free OpenJDK distributions), the exact version and update number (which determines legacy licence eligibility), any perpetual licence entitlements the organisation holds under pre-2019 agreements, and contractual terms specific to the organisation's Oracle agreements that may modify the standard subscription rules.

An organisation that presents SAM tool output to Oracle as a complete compliance determination — without independent expert analysis of the licensing rules — is presenting an incomplete picture. Oracle will supplement it with its own analysis, and Oracle's analysis will maximise the obligation. The SAM tool produces the raw data. Independent analysis converts that data into a defensible licence position.

How to Configure SAM Tools for Oracle Java Audit Defence

A SAM tool deployed without Oracle-specific configuration produces discovery data that cannot be used effectively in an audit. These are the configuration requirements that determine whether your SAM tool data will help or hinder your audit position.

Complete Agent Coverage

Java can appear on any endpoint in the estate. SAM tool Java discovery must reach every managed machine — servers, workstations, virtual machines, containers, and cloud instances. Undiscovered endpoints represent the audit's largest risk: Oracle will characterise them as potentially unlicensed Java deployments. Before any audit commences, the organisation should have documented evidence of SAM agent coverage across at least 98 percent of the managed estate, with explicit inventory of any exceptions and the reason they cannot be covered.

Oracle JDK vs. OpenJDK Distribution Discrimination

This is the most commercially significant configuration requirement. Oracle's subscription obligation applies specifically to Oracle-branded JDK distributions. The numerous third-party OpenJDK distributions — Adoptium Eclipse Temurin, Amazon Corretto, Azul Zulu, Microsoft Build of OpenJDK, Red Hat OpenJDK, and others — do not create Oracle subscription obligations. SAM tools in default configuration frequently identify all Java installations without discriminating by distribution publisher, producing discovery data that systematically overstates Oracle JDK deployment.

Configuring your SAM tool to distinguish Oracle JDK from OpenJDK distributions at the publisher and package name level is a specific, deliberate configuration step. It should be validated by reviewing a sample of the discovery output against known machine configurations before the data is used in any audit context. The Java distributions to recognise as Oracle-licensed are: Java SE Runtime Environment, Oracle JDK, Java SE Development Kit with Oracle as publisher. The distributions to recognise as non-Oracle-licensed include any Temurin, Corretto, Zulu, Microsoft OpenJDK, and Red Hat OpenJDK builds.

Version and Update Granularity

The Oracle subscription metric applies to Oracle JDK version 8 update 202 and later, and all versions from JDK 11 onwards. Oracle JDK 8 update 201 and earlier may be covered by legacy perpetual licences under different terms. SAM tool discovery must report Java version at the update level, not just the major version. A report showing "Java 8" without update numbers cannot be used to assess legacy licence eligibility, because the distinction between update 201 and update 202 is the difference between a legacy perpetual entitlement and a subscription obligation.

Containerised and Cloud Discovery

Java deployments in containers (Docker, Kubernetes) and cloud-native environments present specific discovery challenges. Container-based Java is frequently not discovered by agent-based scanning tools configured only for traditional server environments. Similarly, cloud instances with ephemeral lifecycles may not be consistently covered by standard agent deployment. Confirming that your SAM tool configuration includes container-native discovery and cloud-native inventory collection is required for complete coverage in modern hybrid estate environments.

Converting SAM Tool Data into a Defensible Licence Position

Raw SAM tool discovery output is the starting point, not the destination. These are the analytical steps that convert discovery data into a Java licensing position you can defend in an Oracle audit.

Isolate Oracle JDK from All Other Java

Apply the distribution filter to produce a clean list of Oracle JDK installations only. This list represents the potential Oracle licensing scope. Document the filter criteria — Oracle will ask how you classified specific distributions, and the answer must be technically precise. For any installation where distribution cannot be determined from the SAM data alone (for example, older installations where publisher metadata is missing), treat them conservatively as Oracle JDK in the initial analysis and investigate individually.

Map Oracle JDK Instances Against Entitlements

Cross-reference Oracle JDK installations against the organisation's Oracle licence entitlement records. Legacy Oracle Java SE licences (perpetual licences acquired before Oracle's 2019 commercialisation of Java), Oracle Database licences that include bundled Java Runtime Environment rights, and Oracle application licences that include embedded Java coverage all reduce the subscription obligation. This mapping requires access to the organisation's Oracle contract library and the ability to interpret the relevant licence definitions — it cannot be automated by a SAM tool alone.

Segment the Remaining Exposure by Remediation Opportunity

For Oracle JDK installations not covered by existing entitlements, classify each by remediation feasibility. Installations where Oracle JDK can be replaced with a free OpenJDK distribution without business impact should be prioritised for immediate replacement. Installations where Oracle JDK is embedded in third-party applications (middleware, application servers, legacy enterprise applications) require vendor-level investigation to confirm whether Oracle JDK can be substituted. Installations where Oracle JDK is genuinely required and cannot be replaced represent the residual subscription scope.

Build the Quantified Position

The final defensible licence position quantifies the residual Oracle JDK scope after entitlement coverage and planned remediation: this is the Oracle subscription obligation the organisation acknowledges. It is supported by SAM tool discovery data (verified by an Oracle-accepted tool), entitlement mapping from the contract library, and a documented remediation programme that demonstrates proactive compliance management. This is the position the organisation presents to Oracle's LMS team — and the foundation from which audit negotiations proceed.

Seven Practical Recommendations for 2026

1. Verify your SAM tool's Oracle Java SE certification status now. Verification status changes as Oracle updates its programme and as vendors release new product versions. Confirm that your current tool version carries current Oracle verification for Java SE specifically, not just for Oracle Database or Oracle Middleware.

2. Audit your agent coverage before Oracle audits you. Run a coverage gap analysis against your full asset inventory. Any machine not covered by your SAM agent is a potential undiscovered Oracle JDK installation that Oracle will exploit.

3. Configure distribution discrimination — do not use default settings. Default Java discovery settings in every major SAM tool overstate Oracle JDK deployment by failing to filter out OpenJDK distributions. This is a known, correctable misconfiguration. Fix it before any audit engagement.

4. Preserve SAM discovery data with timestamps. In an audit context, the date on which discovery data was collected matters. Timestamped discovery runs create a defensible record of your compliance position at specific points in time. Oracle's LMS typically asserts that the compliance position exists as of the audit notification date — having timestamped data from before that date strengthens your position.

5. Replace Oracle JDK with OpenJDK where feasible — now, not later. Every Oracle JDK installation replaced with a free distribution reduces the subscription scope. This is not a task for the audit response — it is a continuous estate management activity. Organisations that undertake systematic Oracle JDK remediation before Oracle arrives at their door are in a structurally better negotiating position than those that start remediation after receiving the audit notification.

6. Do not share raw SAM tool data directly with Oracle without independent analysis. SAM tool output presented to Oracle without independent analysis of the licensing implications gives Oracle the raw material to construct the maximum possible claim. Have independent counsel review the data before sharing.

7. Engage independent Oracle Java advisory before the audit clock starts. Oracle's audit letter typically sets a 30-day response window. Engaging independent advisory support before the audit notification — or within the first few days of receiving it — provides the maximum time to build a defensible position. Oracle Java audits that reach senior commercial negotiations without independent advisory support consistently result in worse outcomes than those where independent counsel was engaged from the outset.