Adversarial Verification of GxP Controls: How to Prove an eBR Actually Holds

Every electronic batch record proposal lists the same capabilities: 21 CFR Part 11 compliant electronic signatures, step sequencing controls, complete audit trail, out-of-specification value blocking. The list is nearly identical from one vendor to the next, and reasonably so — it is the baseline for any serious pharmaceutical manufacturing system. Which is exactly why it distinguishes no one.

The question that rarely appears in a vendor qualification process is the one that determines whether the system survives an inspection: how was that control tested?

Most commercial demonstrations show the system doing precisely what it is designed to do. An operator enters a value, the system accepts or rejects it against the configured range, the screen advances to the next step. It looks good. And it says nothing at all about what happens when someone — through intent or through operational error — tries to make the system do something other than what was intended.

That second test is the one almost nobody shows. This article documents it.

What adversarial verification means

Adversarial verification starts from an uncomfortable but necessary premise: a control that has only been tested in correct use has not been tested.

Every critical control undergoes two rounds. The first is conventional: the system is used as intended, and the control is confirmed to act. The second is adversarial: the control is deliberately tested through the paths a user, a configuration error, or an infrastructure failure would exploit in production.

The three test paths we apply against electronic batch record controls:

• Direct server invocation, bypassing the user interface entirely. If a control exists only on the screen, this test exposes it immediately.
• Request payload manipulation, altering data the system might be treating as trustworthy simply because it arrived from the client.
• Deliberate interruption of dependent services, to observe whether the system fails closed or lets the data through once the component that validated it stops responding.

This exercise does not replace formal operational qualification or the full computerized system validation lifecycle. What it does is feed that validation with substantially stronger evidence than a functional specification and a demo run under ideal conditions.

Three cases illustrate the method.

Case 1. Skipping a step the interface never offers

The attempt. Force execution of the next step in a batch without completing the previous one, by sending a direct request to the server, bypassing every button and screen in the system.

The result. Rejected. Not because a button was hidden or disabled in the interface, but because the task corresponding to the next step does not yet exist inside the process engine. There is nothing for the system to execute, even when asked directly. A second, independent verification layer also fails closed if the prior step is incomplete.

Why it matters. There is a fundamental difference between an interface control and a state control, and this test is exactly where it becomes visible:

• An interface control prevents the user from seeing the option to proceed. Anyone with basic technical knowledge can bypass it by calling the server outside the screen.
• A state control makes the action impossible in the engine itself, regardless of how it is invoked.

To an inspector, the difference between the two is the difference between a lock on a door and a door that does not exist yet.

Case 2. Approving your own work

The attempt. A user registered as the author of a version attempts, through direct manipulation of the server request, to also be recorded as the approver of that same version.

The result. Rejected, verified before the signature is accepted. The server retains authorship of the record, and the electronic signature service checks that authorship before admitting any approval signature. This is not a question of which buttons appear on screen for that user: it is a server-side verification against data the client does not control. Even the scenario where the signature service stops responding mid-operation is covered — the system rolls back the operation in progress rather than leaving it half-complete.

The part worth telling in full. This control was not right on the first design. Its first version failed this exact test: under certain conditions, it allowed the same user to be recorded as both author and approver. The failure was documented, the mechanism was corrected, and it was tested the same way again until it held.

Why it matters. A system that has never been subjected to this test has no way to demonstrate it would hold. A system with a documented, corrected, and reverified failure has something more valuable than a clean record: evidence that the development process detects gaps and closes them, which is precisely what a change control regime must be able to demonstrate. The absence of failures in the record guarantees nothing. A history of failures found and closed does.

Case 3. When the validating component goes down

The attempt. Deliberately shut down the service responsible for evaluating whether a captured value falls within the permitted range, while an operator is mid-capture on the floor.

The result. The system blocks the save. It does not let the value enter the record unvalidated simply because the validator became unavailable.

Why it matters. This is the difference between a system that fails closed and one that fails open, and it is among the points an auditor recognizes instantly because it connects directly to the data integrity principles captured in ALCOA+.

A system that allows progress without validation when a component goes down is not failing safely: it is opening a window in which unvalidated data enters the regulatory record, unnoticed until batch history review. Fail-closed discipline has to be present in every component a critical control depends on, not only in the primary one.

What this method does not solve

It is worth being precise about the limits of the exercise, because a vendor presenting its methodology as infallible is describing marketing, not engineering.

Adversarial verification confirms that a control withstands the tests actually applied to it. It does not prove resistance to every possible test. It does not replace IQ, OQ, and PQ protocols, the validation master plan, or the formal data integrity assessment a system of this type requires before entering production.

Nor does every control in a system demand the same level of segregation. Some design decisions are deliberate and should not be read as gaps: the fact that two specific roles cannot be held by the same person at one point in the flow does not mean that no combination of roles may be shared at another point where the applicable regulatory requirement does not demand it. The correct question is not whether everything is segregated, but whether what requires segregation actually has it, and whether that decision was documented as such in the specification.

The question that belongs in every vendor qualification

The standard question in a qualification process is some variant of “is your system 21 CFR Part 11 compliant?”. Almost any vendor can answer yes, and that ease is exactly what makes it useless as a decision criterion.

A question that does demand evidence:

Can you show me the record of a deliberate attempt to evade this control, and the result of that test?

How to read the answer:

• If it arrives as a functional specification or a demo of the system in normal use, adversarial verification probably never happened.
• If it comes back with successes only, ask how many attempts were run and of what type.
• If it includes at least one attempt that exposed a gap, along with the correction applied and the subsequent reverification, you are looking at a development process that takes the possibility of failure seriously.

That question separates a vendor who designed controls from one who put them to the test. And in practice, it is one of the few qualification criteria a technical committee can evaluate without relying on the vendor’s word.

How this connects to the revised Annex 11

The draft revision of EudraLex Annex 11, published in July 2025 alongside PIC/S, reinforces three requirements this methodology addresses directly: formal assessment of vendor capability, documented demonstration of change control over validated systems, and the incorporation of cybersecurity into the GMP compliance perimeter.

A vendor who can only show that the system works satisfies none of the three convincingly. A vendor who can show how it was tested, what was found, and how it was closed satisfies all three with the same body of evidence.

The full analysis of the draft changes is available in Annex 11 and Annex 22: what changes for an eBR, and the point-by-point checklist is available to Quality and Validation teams.

A note for teams evaluating a nearshore engineering partner

If you are a US or EU based manufacturer considering an engineering partner in Latin America for a regulated systems project, the five-question framework above applies unchanged. There is one additional question worth asking early, because it reveals more than any capability matrix will:

Was this system designed against the regional regulatory baseline, or against the stricter framework with the regional requirement mapped on top?

Systems built to the stricter framework absorb regional compliance almost automatically; what remains is documentation mapping, not re-engineering. Systems built to the regional minimum and later scaled toward US or EU export require architectural rework mid-operation, which is the most expensive point in the lifecycle to discover a gap.

The same logic applies to the verification discipline. A partner who only ever had to satisfy a less demanding inspection regime has had no reason to develop adversarial testing practice. Ask to see the evidence, not the claim.

Let’s talk about your scenario

If your Validation team has an attack scenario in mind against your own electronic batch record system — one you never ran in production because the risk did not allow it — let’s discuss how that test would be structured in a controlled environment.

The system does not have to be ours for the conversation to be worth having.

Explore Valdrent’s pharmaceutical practice

Valdrent designs and implements electronic batch record systems in accordance with 21 CFR Part 11, EudraLex Annex 11, and RTCA 11.03.42:07, deployed within the client’s own infrastructure.