Eliya: OpenJDK for regulated production by industry

Some controls cannot be reached from outside the process

A wrapper script, a Helm chart, an admission webhook, a service mesh, a -javaagent: all of them are powerful, and all of them stop at the same wall. They cannot change what the JVM's own code does on the inside. A sidecar cannot rewrite the bytes a heap-dump writer is emitting while it emits them. A mesh has no view of which crypto provider a library registered inside the process. A scanner reads the image on disk and cannot tell you which classes the running JVM actually loaded.

Eliya is an OpenJDK 25 LTS distribution that establishes the policy point inside the runtime, for the small and characterisable set of controls that can only be completed there.

We can name that set, and cite the clause

We maintain a compliance knowledge base that decomposes standards clause by clause and asks one question of every control: can an outer layer complete this end to end, against unaudited in-process code?

Most of the time the answer is yes, and we say so. Network identity, authorisation between services, key custody inside an HSM, log retention in WORM storage, patch delivery: an outer layer owns these, and Eliya does not compete for them.

For a specific set of controls the answer is no. They fail for one of two structural reasons.

Reach

There is no external surface to act on.

The runtime acts before exposure: a native writer emits cleartext as the stream is written, so an external tool only ever sees a file that already contains the secret.
The runtime owns the memory lifecycle: an immutable String's backing array cannot be zeroed from outside, and a moving collector may already have left copies in vacated regions.
Only the runtime can attest its own internal state: an outside observer signs what it saw, never what was internally true.

Non-overridability

A surface exists, but code inside the process defeats it.

Security.addProvider registers a weaker provider at runtime.
A library builds its own SSLContext and ignores java.security entirely.
JAVA_TOOL_OPTIONS wins flag precedence after the reviewed specification was signed off.

Settable from outside and enforceable from outside are not the same property. Most of the confusion in this area comes from conflating them.

That analysis is the product. Name a control and we will show you the clause it comes from, the argument for why a runtime is necessary, and the argument against it that we ran and failed to make stick.

Choose your sector

Sector	The control an outer layer cannot close
Financial services	A heap dump of a payment service is cardholder data at rest. PCI DSS 3.5.1 says PAN must be unreadable anywhere it is stored, and a dump is storage.
Healthcare	The same dump holds ePHI. Diagnostics stay inside your environment: Eliya sends nothing outward, ever.
Government	A FIPS certificate attests the module. Only the process can prove the module actually loaded, self-tested, and is operating in approved mode.
Telecom	Carrier-scale CVE response across estates too large to answer by hand, with evidence that never leaves the operator perimeter.

The release ladder

Eliya is a phased platform. Every capability below is either shipped, targeted at a named release, or demand-gated.

Release	Capability
Shipped (25.0.3)	Production-readiness defaults behind one flag (`-XX:EliyaProfile=Production`). Quarterly security refresh within about two weeks of upstream OpenJDK, critical CVEs targeted inside a week, committed through the JDK 25 LTS window (September 2029). Signed releases (Ed25519) with SHA-256 checksums and an SPDX SBOM. Provable flag provenance: every value carries its origin, so `{default}`, `{ergonomic}` and `{command line}` are distinguishable, and an auditor can prove where a setting actually came from.
25.0.4	In-process secret redaction at the serialisation boundary. FIPS-validated cryptographic module. CycloneDX SBOM alongside SPDX, plus signed SLSA v1.0 build provenance.
25.0.5	Signed attestation of the resolved configuration: what the process actually resolved to, not what the spec declared.
25.0.6	Hardened TLS that holds, behind `-XX:+UseEliyaSecurityStrict`. The default `java.security` stays bit-identical to upstream.
25.0.7	Runtime security-event stream and the guarantee it cannot be silenced from inside the process. Audit-stream integrity sealed at emission. In-heap secret lifecycle for the JDK's own key material. Loaded-code attestation. Runtime posture attestation, including approved-mode. And the `PCIDSS` profile (`-XX:EliyaProfile=PCIDSS`), which fails closed rather than run in violation.
Demand-gated	The remaining compliance profile values (`HIPAA`, `SOX`, `FedRAMP`, `GDPR`, `ISO27001`, `SOC2`). Reserved in the flag architecture, built when a named customer asks.

Verification is yours to do: every release ships with checksums and a detached signature, so you confirm the download independently. Our builds are reproducible and that is independently verifiable on request.

Who this is not for

If Temurin or Corretto fits you, stay on them. They are good, they are free, and we will tell you so.

Eliya is for the case where an outer layer has run out of room, and you can name the control it ran out of room on.

Talk to the Chief Architect about the control you cannot close. Or read the policy point, the essay that sets out the general case.