Why "EAL4" and "EAL4+" Are Not the Same Thing for Procurement

There is a procurement bug baked into nearly every Common Criteria tender we see. The specification reads “EAL4 minimum.” The bid evaluation matrix has a single Common Criteria column. Every candidate whose certificate prints “EAL4” or “EAL4+” gets the same green tick. The matrix rolls up, the steering committee signs off, and a recommendation goes forward.

The plus sign hides the variation that actually matters. Two products both marketed as “EAL4+ certified” can have been measured against materially different assurance packages, and a specification at “EAL4+ minimum” resolution gives the bid evaluator no way to tell them apart. This post is about which augmentations move the procurement needle, how the same headline can mean very different things in practice, and the one-sentence change to your specification that closes the gap.

For the underlying machinery, the guide to EAL levels is the baseline explainer. This piece assumes you already know what an EAL is and goes straight at the specification-drafting problem.

What EAL4 actually fixes

EAL4 is a defined Security Assurance Requirements (SAR) package in Common Criteria Part 3, the assurance components catalogue. The package fixes which assurance components from which families the evaluation must address, at which level. For EAL4 (methodically designed, tested, and reviewed) the baseline includes things like ADV_IMP.1 (the evaluator gets a sample of the implementation representation), ATE_DPT.1 (testing covers the basic design), AVA_VAN.3 (focused vulnerability analysis at the enhanced-basic attack-potential level), and ALC_DVS.1 (basic development security).

Read the package as a contract between the evaluator, the developer, and the certifier: these are the assurance activities, performed to this depth, against these classes of evidence. A vendor with an EAL4 evaluation has paid for that contract to be executed end to end.

The procurement-relevant point is that bare EAL4 is a fixed shape. Two candidates both at base EAL4 have been measured against the same yardstick. Once a plus sign appears, the yardstick changes per certificate.

What the plus sign signals, and what it hides

“EAL4+” is industry shorthand for “EAL4 plus one or more augmented SARs.” The CC concept is augmentation: you take the EAL package and add specific components from outside it, or you raise specific components within it to a higher level. The certificate text usually spells the augmentation out, in the form EAL4+ALC_DVS.2+AVA_VAN.5 or similar. The Security Target is the authoritative source for which components were actually augmented.

In sales collateral, the ”+” frequently appears alone. That is where the trap lives. Two products both marketed as “EAL4+” can carry completely different augmentations. The plus tells you something was added; it does not tell you what.

The augmentations that actually move the procurement needle

Three augmentation families come up over and over in real certificates, and each one changes a buy decision in a different way.

AVA_VAN.5: high attack potential

AVA_VAN.5 (Advanced methodical vulnerability analysis) raises vulnerability assessment to the high attack potential level. The evaluator must consider an attacker with significant time, specialist expertise, deep knowledge of the TOE, and access to sophisticated equipment and bespoke tools. AVA_VAN.5 is the standard expectation for smart cards, secure elements, secure microcontrollers, payment terminals, hardware security modules, and other targets where a determined and well-funded adversary is realistic.

The EAL4 baseline of AVA_VAN.3 considers a much weaker adversary (enhanced-basic attack potential). The gap between the two is, by some margin, the most procurement-relevant difference inside the “EAL4+” envelope. If your threat model includes nation-state, organised-crime, or otherwise well-resourced attackers, an EAL4 evaluation without AVA_VAN.5 is not measuring what you need measured.

ALC_DVS.2: development security sufficiency

ALC_DVS.2 (Sufficiency of security measures) raises the bar in the Life-Cycle Support class. The developer must justify (not merely describe) that the physical, procedural, personnel, and other security measures around development and production are sufficient to protect the confidentiality and integrity of the TOE.

ALC_DVS.2 is common in integrated-circuit and smart-card evaluations, where it matters who has access to the design files, the masks, the keys, the test vectors, and the personalisation lines. If your supply chain crosses borders, jurisdictions, or contract manufacturers, ALC_DVS.2 is doing real work. If it is absent, the development environment is held only to the lighter ALC_DVS.1 baseline, which asks the developer to describe the controls rather than show that they are adequate against the assumed attacker.

ALC_FLR family: flaw remediation as a commitment

ALC_FLR.1 commits the vendor to a basic flaw remediation procedure. ALC_FLR.2 adds reporting to TOE users. ALC_FLR.3 adds systematic flaw-handling, user-registration, and tracking processes.

Crucially, ALC_FLR is not part of any EAL package by default. It has to be augmented in to appear on the certificate at all. If your operational threat model includes a steady drumbeat of CVEs (and for nearly every category of certified product, it should), an explicit ALC_FLR augmentation makes the vendor’s flaw-handling commitments part of the assurance claim rather than something the contract has to invent from scratch.

There are other augmentations you will run into (ADV_IMP.2 for the full implementation representation, ATE_DPT.2 for deeper testing, AVA_VAN.4 for moderate attack potential), but the three families above account for the bulk of procurement-material differences inside “EAL4+.” The EAL augmentations wiki entry walks the full catalogue.

Two hypothetical “EAL4+ certified” products

Consider two candidates for a high-value-target deployment, both with current certificates from a CCRA Certificate Authorizing scheme. The names and details are deliberately generic; the augmentation patterns are the procurement-relevant part.

Candidate A carries EAL4+ALC_FLR.1. Base EAL4 plus a basic flaw remediation procedure. Vulnerability assessment is at the EAL4 baseline of AVA_VAN.3 (enhanced-basic attack potential). Development security is at ALC_DVS.1. This is a perfectly respectable assurance posture for, say, a back-office network appliance evaluated in a corporate IT setting.

Candidate B carries EAL4+ALC_DVS.2+AVA_VAN.5+ALC_FLR.2. Same headline EAL, same plus sign in the marketing copy. Vulnerability assessment is now at high attack potential. Development security is justified rather than merely described. Flaw remediation includes user reporting. This is a smart-card-grade assurance posture.

For a deployment that has to resist a serious adversary (national-identity card personalisation, an EMV payment terminal, an eIDAS Qualified Signature Creation Device), Candidate A is not procurement-grade and Candidate B is. The ”+” sign on its own gives no way to see that. If your specification accepted “EAL4+ minimum,” your tender mechanically treated the two as equivalent.

This is not a hypothetical disagreement about labels. It is a real gap in assurance against the attacker you actually face.

How to write the specification so the trap does not bite

The fix is one sentence. Specify the augmented Security Assurance Requirements by name, not just the headline EAL with a plus sign.

• “EAL4 augmented by AVA_VAN.5 minimum” tells a vendor exactly what they must hold.
• “EAL4 augmented by ALC_DVS.2 and AVA_VAN.5 and ALC_FLR.2 minimum” tells them all three.
• “EAL4+ minimum” tells them nothing constraining about the augmentation.

The candidates’ Security Targets carry the answer, and the comparison is now apples to apples.

Two practical notes when drafting this language:

1. Quote the SAR component identifiers in CC Part 3 notation (AVA_VAN.5, ALC_DVS.2, ALC_FLR.2). Vendors and labs recognise the notation, and the bid evaluator who later reads the response will not have to guess what you meant.
2. Make the augmentation requirement testable. If you accept “AVA_VAN.5 or equivalent” you have re-opened the loophole. “AVA_VAN.5 minimum” closes it.

If your procurement category is one where high attack potential is a baseline expectation (smart cards, secure elements, payment terminals, HSMs, IC platforms, eIDAS QSCDs, national identity tokens), consider going further and writing the augmentation requirement at category level so it lands consistently across every tender your team issues. The Protection Profile catalogue is a good complementary lever: a PP often pins the augmentation expectation per category, and “conformant to PP X” is a tighter constraint than “EAL4+ minimum.”

For categories where the practical ceiling is genuinely higher than EAL4, the same rule applies one level up: EAL5 augmented with AVA_VAN.5 has a different procurement meaning than bare EAL5, and the specification should say which.

A note on EUCC

The EU Cybersecurity Act introduces its own assurance levels under EUCC, Substantial and High, mapped onto the AVA_VAN ladder rather than directly onto the EAL ladder. EUCC High lives broadly in the AVA_VAN.4 and AVA_VAN.5 territory; EUCC Substantial covers the lighter AVA_VAN.1 and AVA_VAN.2 zone.

The underlying SARs are the same Common Criteria components, so the procurement principle does not change. Specify the AVA_VAN level you actually need, and read the certificate at that resolution. The EUCC label gives you a regulatory hook; it does not relieve you of reading the Security Target.

Where this fits in the broader playbook

Specifying augmentations by name is one of the small, high-leverage moves that distinguishes assurance-driven procurement from box-ticking. The companion moves: verify the Target of Evaluation matches the SKU you are actually buying, check the certificate lifecycle state at the issuing scheme’s registry, read the Security Target instead of the brochure, and confirm the issuing scheme’s CCRA role if mutual recognition matters to you. The twelve procurement red flags post lists the full pattern set; how to read a CC certificate covers the document-side checks. For sector-specific category notes (smart-card chips, IC platforms, secure elements), the smart-card chip vendor comparison puts the augmentation question in context.

If a particular SAR notation is unfamiliar, the glossary carries definitions for the assurance classes, families, and components you will encounter on a CC certificate.

How NenkinTracker helps you see this

NenkinTracker indexes the augmentation string on every Common Criteria and EUCC certificate it tracks, alongside the headline EAL. The filter set lets you constrain by AVA_VAN level, by ALC_DVS level, and by ALC_FLR presence, so you can compare candidates at the augmentation resolution rather than the headline resolution. Two products both marketed as “EAL4+” stop being indistinguishable.

If you are about to issue a tender for a high-value-target category and you want a buyer-side reader to pressure-test the specification before it goes out, Nenkin’s procurement advisory covers exactly that. Founded by a former Technical Manager of the Norwegian Common Criteria certification authority, the practice sits buyer-side, does not take vendor referral fees, and writes recommendations attributable to a named advisor. The cheapest place to fix a specification of this kind is before signature.