OpenJDK for financial services and payments

Your heap dump is cardholder data at rest

An HPROF file serialises the entire live object graph to disk, so every card number your payment service was holding as a String or a byte[] is written out in cleartext, at the exact moment the JVM is in the most trouble. The same is true of the fatal-error log when the VM crashes, and of a Flight Recorder file that captured an exception message.

You have two options today, and you already know both of them.

Turn the diagnostics off. Drop -XX:+HeapDumpOnOutOfMemoryError, forbid jmap by policy, run a base image with no diagnostic tooling. Your compliance floor goes up and your incident-response capability goes down, and you discover exactly how far down on the night you need it most. You have traded away the single most valuable forensic artifact a JVM produces in order to satisfy a clause about storage.

Scrub it afterwards. The tools are real and they are good. Every one of them opens a file that already contains the card numbers. The control said the PAN must not be in the artifact. It was in the artifact. You are now managing the consequences of a disclosure that already happened.

Neither is a fix, because neither can stand where the problem is. The writer is native, it is inside the process, and it emits cleartext as the stream is written. There is no moment at which an outer layer holds those bytes and could decide otherwise.

Eliya redacts at the serialisation boundary, inside the VM, as the stream is written. Targeted at 25.0.4. It is the one place the control can be completed, and it kills the dilemma instead of trading one risk for another.

What else PCI asks that a wrapper cannot answer

We decomposed PCI DSS v4.0.1 clause by clause. These are the ones where an outer layer runs out of room.

PCI clause	The control	Why the outside cannot close it	Eliya
3.5.1 PAN unreadable wherever stored	Secrets never reach a diagnostic artifact	The writer emits cleartext as it streams. Post-hoc scrubbing acts on a file that already contains the PAN.	25.0.4
3.3.1 SAD not stored after authorization	Track data, CVV and PIN blocks unrecoverable, including from memory	Since JEP 454 an application can hold its own secrets off-heap and zero them. It cannot touch the `byte[]` inside a `SecretKeySpec` from `KeyStore.getKey`, whose `destroy()` throws in the common providers, nor the copies a moving collector left behind.	25.0.7
3.6.1 / 3.7.1 key custody and lifecycle	Key material controlled from birth to death	An HSM with non-extractable keys genuinely wins, and we say so. But nothing stops in-process code loading a raw key, and envelope encryption structurally requires the plaintext data key in process memory.	25.0.7
4.2.1 strong transit cryptography	The negotiated result actually holds	`jdk.tls.disabledAlgorithms` is settable. A library can still build its own `SSLContext` with a permissive `TrustManager` and negotiate whatever the peer offers. A mesh does not see the call your app makes directly to a gateway.	25.0.6
10.2.1 / 10.3.x audit logs enabled, active, protected	The trail cannot be silenced or suppressed from inside	A WORM store seals what it received. It cannot detect a record suppressed before it ever left the host: absence is indistinguishable from "nothing happened".	25.0.7
2.2.1 configuration standards	The hardened config is the one in force	An admission webhook validates the spec it can see. It cannot see `JAVA_TOOL_OPTIONS` baked into an image layer, nor a value the process changes after startup.	25.0.5
6.3.3 patches installed within a month	The fixed code is the code running	"Installed" is not "loaded". A scanner reads the image. Shading, classloader order, and a process nobody restarted mean the vulnerable class can still be live.	25.0.7

A profile that fails closed

Those capabilities compose. In 25.0.7, -XX:EliyaProfile=PCIDSS activates them as a curated set and treats them as regulator-owned rather than operator-owned: a conflicting override is refused at startup rather than quietly accepted, and the profile will not boot on a non-FIPS binary at all. Redaction, hardened TLS, the audit stream, the secret lifecycle and both attestations become mandatory boot artefacts rather than things somebody remembered to switch on.

This is the one compliance profile that is not demand-gated. It is a named release deliverable because PCI is where we decomposed the standard first.

What we do not claim

We will not sell you compliance. PCI DSS has twelve requirements and most of them are yours: network segmentation, physical security, staff training, policy, vulnerability scanning. A JDK cannot satisfy or violate any of them, and any vendor telling you otherwise is selling paperwork.

We will not claim a control an outer layer already closes. Your KMS should hold your keys. Your SIEM should retain and review your logs. Your gateway should tokenise at ingest so that SAD never enters your JVM at all, and where you can do that, do it: it is the right answer and it dissolves the problem.

And we will not tell you a plan is a product. In-process redaction lands in 25.0.4. It is not shipped today. What ships today is the quarterly cadence, the signed release with an SBOM, production-readiness defaults behind one flag, and provable flag provenance.

The evidence an assessor actually wants

Your QSA does not want a policy PDF. They want to know what was in force, not what was declared.

From 25.0.5, Eliya emits a signed attestation of the configuration the process actually resolved to, after every default, ergonomic decision, environment variable, container override and late launch input has been applied. Today the foundation is already shipped: every flag value carries its origin, so {default}, {ergonomic} and {command line} are distinguishable, and an auditor can prove where a setting actually came from.

That is the difference between "we configured it correctly" and "the runtime says this is what it resolved to, and here is the signature".

Talk to the Chief Architect about Requirement 3. Or download Eliya, or read the policy point.