OpenJDK for government and the public sector
FIPS 140-3 validates a cryptographic module. It says nothing whatsoever about the process an assessor is actually looking at. This is the gap nobody in the industry says out loud.
A FIPS certificate attests the module, not your process
The certificate says a specific piece of software, in a defined configuration, met the requirements. It is a real and rigorous thing, and it is what your procurement process asks for.
Did that JVM load the validated module? Is the provider chain the one the policy file declared, or did application code call Security.insertProviderAt and put something else at position one? Did the module run its power-on self-tests, and did they pass, or did it fall back to a non-approved path that computes the same answers? Is approved-only operation actually in force right now?
Every one of those questions is about state that exists only inside the process. The provider chain is resolved at runtime. The self-test outcome is an event inside the module. Approved mode is a mode the module is in, not a file on disk.
So the industry has quietly accepted a proxy: the presence of a validated artifact stands in for evidence of validated operation. That substitution is invisible in an audit and fatal in an incident.
Eliya ships a FIPS-validated cryptographic module in 25.0.4, and in 25.0.7 it can attest its own cryptographic posture: which providers resolved, in what order, that the module loaded and self-tested, and that approved-only operation is in force. Signed, by the runtime, about itself.
That is the difference between handing an assessor a certificate and handing them evidence.
Data sovereignty is not a setting
Eliya sends nothing outward. No telemetry. No SaaS dependency. No callback home.
Every diagnostic artifact stays inside your boundary because there is no mechanism to send it anywhere. This is not a configuration flag you must remember to set, and not a promise in a privacy policy. There is nothing to review, because there is nothing to review.
For an air-gapped estate, a classified environment, or any deployment where a call to a vendor's endpoint is an incident in itself, that property is the entire conversation.
Supply chain, and what we will and will not say about it
Executive Order 14028, OMB M-22-18 and NIST SSDF have made provenance a procurement gate, and rightly.
| What you get | When |
|---|---|
| Signed releases (Ed25519), SHA-256 checksums, SPDX SBOM | Shipped |
| CycloneDX SBOM alongside SPDX, and signed SLSA v1.0 build provenance as an in-toto attestation | 25.0.4 |
| Loaded-code attestation: what the JVM actually loaded, not what the image contains | 25.0.7 |
On reproducibility, we are careful, and you should hold us to the exact wording. Our builds are reproducible, and that is independently verifiable on request. What you verify at your end is the download: the checksum and the detached signature, which you confirm yourself, without trusting us. We do not tell you to rebuild the JDK from scratch and compare, because that is not the claim we are making.
On loaded-code attestation we will also be blunt about what is not new. A JVMTI agent can already enumerate loaded classes today. The inventory is commodity, and any vendor claiming "only the runtime knows what is loaded" should be pressed on it. What an agent cannot do is attest: it can be left unattached, refused by -XX:-EnableDynamicAgentLoading, or have its output rewritten by in-process code, and it signs what it observed rather than what the runtime knows. The differentiator is the signature and the non-defeatability. It is a narrower claim than it first looks, and it is the true one.
What the outside cannot close
| Requirement family | The control | Why | Eliya |
|---|---|---|---|
| FIPS 140-3, NIST SC-13 | Cryptographic posture provable, not asserted | The provider chain and the self-test outcome exist only inside the process. | 25.0.4 module, 25.0.7 attestation |
| NIST CM-6 / CM-7 | The hardened configuration is the one in force | An admission controller validates the spec it can see, not JAVA_TOOL_OPTIONS in an image layer or a value the process changed after startup. | 25.0.5 |
| NIST AU-2 / AU-9 | The audit trail cannot be silenced or suppressed from inside | A WORM store seals what it received. It cannot detect a record suppressed before it left the host. | 25.0.7 |
| NIST SC-8 | The negotiated TLS result actually holds | A library can build its own SSLContext and ignore java.security. | 25.0.6 |
| SI-2, EO 14028 | The fixed code is the code running | "Installed" is not "loaded": shading, classloader order, an unrestarted process. | 25.0.7 |
Where we stand today
Eliya does not hold a FIPS 140-3 certificate today, and does not claim one. The validated module lands in 25.0.4. Eliya is not currently FedRAMP authorised, and is not a FedRAMP shortcut: your authorisation boundary is yours, and a JDK is one component inside it.
Of the compliance profile values reserved in the flag architecture, only PCIDSS is a named release deliverable, in 25.0.7. FedRAMP and the rest remain demand-gated: they are built when a named customer asks, and we would rather tell you that than show you a roadmap slide.
Eliya is built from public OpenJDK source under GPLv2 with Classpath Exception, so you hold a perpetual right to the source and to keep building it. If Asymm stopped existing tomorrow, you would still have working, source-available binaries, and you could fall back to Eclipse Temurin in under a day. There is no lock-in, and we would rather you knew that before you bought than after.
Talk to the Chief Architect about approved-mode evidence. Or verify your download, or read the policy point.
Eliya 
Dial