EAL Augmentations Explained: AVA_VAN, ALC_DVS, ALC_FLR, and Beyond

Summary: EAL augmentations are individual Security Assurance Requirements raised above the baseline of a pre-defined EAL package, written EAL4+ or EAL4 augmented by X. They materially change the evaluation work performed and are the single biggest reason that two EAL4-class certificates can differ in real assurance.

The headline EAL number on a Common Criteria certificate hides a deeper layer of detail. EAL1 through EAL7 are pre-defined packages of Security Assurance Requirements (SARs), but the standard also allows individual SARs to be raised above the baseline of the package. Those raised SARs are called augmentations, and a certificate that carries them is described as “EAL4 augmented” or written with a trailing plus, “EAL4+”.

For a procurement specifier or a Security Target reviewer, the augmentation list is where the real assurance picture lives. This entry walks through the most procurement-relevant SAR families, what each component means, and how to write augmentations into a tender so that two bids can actually be compared. The companion long-form post, EAL4 and EAL4+ are not the same, runs the same argument with worked smart-card and network-equipment examples.

What an augmentation is in CC terminology

A Security Assurance Requirement (SAR) is a unit of evaluator work defined in ISO/IEC 15408-3 (CC Part 3). SARs are grouped into families (for example AVA_VAN, ALC_DVS, ALC_FLR), and each family has components at increasing levels of rigor (AVA_VAN.1 through AVA_VAN.5).

A pre-defined EAL package, as catalogued in CC Part 5, bundles a fixed set of these components. EAL4 includes AVA_VAN.3, ALC_DVS.1, ATE_DPT.1 and so on. An augmented EAL keeps the package baseline and substitutes a higher-numbered component (or adds a component the baseline did not include) from CC Part 3.

There are two ways an ST author can express augmentation:

• Plus shorthand: “EAL4+”, which is widely used in marketing but does not name the augmented components.
• Explicit form: “EAL4 augmented by AVA_VAN.5 and ALC_DVS.2”, or the equivalent expression “EAL4+AVA_VAN.5+ALC_DVS.2”. This is the form used in the conformance claims section of the Security Target.

Only the explicit form is authoritative. If a certificate page or vendor brochure reads “EAL4+”, the next step is to open the ST and read the actual augmentation list.

AVA_VAN: vulnerability analysis

AVA_VAN (Vulnerability Analysis) is the single family inside the AVA class (Vulnerability Assessment). It governs how hard the evaluator has to look for exploitable weaknesses and what attacker model the analysis assumes. The component number maps to one of the CC attack-potential levels: Basic, Enhanced-Basic, Moderate, High.

AVA_VAN.2 is the EAL2 and EAL3 baseline; AVA_VAN.3 is the EAL4 baseline; AVA_VAN.4 is the EAL5 baseline; AVA_VAN.5 is the EAL6 and EAL7 baseline. Augmentation to AVA_VAN.5 from a lower EAL (most commonly EAL4 or EAL5) is the canonical smart-card pattern: the package keeps the developer-effort profile of EAL4 or EAL5, but the evaluator vulnerability analysis is raised to the High-attack-potential level that smart-card deployment requires. The BSI scheme handles a majority of those smart-card EAL4+ and EAL5+ certifications today, with ANSSI the next-largest issuer.

For back-office and enterprise software products the AVA_VAN.2 or AVA_VAN.3 default is usually correct: the attacker is assumed to be remote, working with public information and tools, not a well-funded laboratory attempting side-channel attacks against a chip in a package.

ALC_DVS: development security

ALC_DVS (Development Security) is a family inside the ALC class (Life-Cycle Support). It governs the procedural, physical, and personnel security controls the developer applies at the development site to protect the TOE’s design and implementation from unauthorised disclosure or modification.

• ALC_DVS.1: The developer has documented and applied development security measures sufficient to protect the confidentiality and integrity of the TOE design and implementation. EAL3 and above include ALC_DVS.1 as the baseline.
• ALC_DVS.2: Same as ALC_DVS.1, but the developer must also justify the sufficiency of those measures against the attacker model in the Security Target. In practice this means demonstrating that the development site is hardened against the same attacker the evaluator will assume in AVA_VAN.5.

ALC_DVS.2 is almost always paired with AVA_VAN.5 in smart-card and secure-IC evaluations. The reasoning is operational: there is little point analysing the deployed chip against a High-attack-potential attacker if the same attacker could compromise the design at the developer’s facility and insert weaknesses upstream of the evaluation. ALC_DVS.2 closes that supply-chain side of the threat model. The smart-card chip vendor comparison post on the blog walks through which IC vendors routinely deliver ALC_DVS.2 across their portfolios.

For non-smart-card products, ALC_DVS.1 is usually adequate and ALC_DVS.2 is rare.

ALC_FLR: flaw remediation

ALC_FLR (Flaw Remediation) is the family that commits the developer to a documented process for handling security flaws discovered after the TOE has been issued. No EAL package includes ALC_FLR as a baseline. It only appears as an explicit augmentation, which is why “EAL2 augmented by ALC_FLR” is so common on CCRA-recognised certificates: it is the threshold the CCRA recognition arrangement extends to for non-cPP evaluations.

• ALC_FLR.1 (Basic flaw remediation): the developer has procedures for receiving and tracking reported flaws, distributing corrective actions to TOE users, and acting on flaws relevant to security.
• ALC_FLR.2 (Flaw reporting procedures): adds documented procedures, defined flaw-handling timing, and a means for TOE users to report flaws to the developer. Vendors offering ALC_FLR.2 typically maintain a published security-advisory channel.
• ALC_FLR.3 (Systematic flaw remediation): adds systematic procedures, automatic flaw notifications to registered TOE users, and corrective-action timing requirements. ALC_FLR.3 is the strongest commitment and the closest CC analogue to a contractual SLA.

ALC_FLR is the augmentation that most directly binds the vendor to post-certification behaviour. For a buyer who plans to deploy the product over multiple years, ALC_FLR.2 or ALC_FLR.3 is materially different from a bare EAL certificate that says nothing about the developer’s flaw-handling process. Procurement contracts should still write patching SLAs in explicit terms (see the procurement guide), but ALC_FLR backs the contract with an evaluator-checked commitment.

ATE family: test rigor

The ATE class (Tests) covers developer functional testing, test coverage, test depth, and independent evaluator testing. Three families show up in EAL packages:

• ATE_FUN (Functional tests): the developer’s own test suite. ATE_FUN.1 is the baseline at EAL2 and above and requires documented functional tests with traceable results.
• ATE_COV (Test coverage): how thoroughly the developer’s tests cover the TOE Security Functionality. ATE_COV.1 (evidence of coverage) is the EAL2 baseline; ATE_COV.2 (analysis of coverage) is the EAL3 baseline; ATE_COV.3 (rigorous analysis) appears at EAL5 and above.
• ATE_DPT (Test depth): how deep into the TOE design the tests go. ATE_DPT.1 (testing of basic design) is the EAL3 baseline; ATE_DPT.2 (testing of security enforcing modules) is the EAL4 baseline; ATE_DPT.3 (testing of modular design) is the EAL5 baseline; ATE_DPT.4 is the EAL6 and EAL7 baseline.
• ATE_IND (Independent testing): the evaluator’s own testing. ATE_IND.1 at EAL1 is a basic confirmation; ATE_IND.2 (testing a sample) is the EAL2 and above baseline; ATE_IND.3 (complete independent testing) is reserved for EAL6 and EAL7.

ATE augmentations are unusual in commercial procurement; the test-rigor profile of a given EAL is usually accepted as is. They become relevant for evaluations that need to demonstrate exceptional test coverage independent of the wider EAL choice.

AGD family: guidance documentation

The AGD class (Guidance Documents) covers two families that ensure administrators and users can deploy and operate the TOE securely.

• AGD_OPE.1 (Operational user guidance): the user-facing documentation required for secure operation. Included as baseline from EAL1.
• AGD_PRE.1 (Preparative procedures): documentation for secure delivery, installation, and configuration. Included as baseline from EAL1.

Both families have only one component, so AGD augmentation in the strict sense does not occur. AGD shows up in procurement conversations when a buyer needs to confirm that the certified guidance documents match the actual administrative interface, especially for products where the marketing literature and the AGD-conformant manual describe different feature sets.

Other augmentations buyers occasionally see

The CC Part 3 catalogue is large; most procurement teams will only see the families above, but a few others appear in specific markets.

• ADV_IMP (Implementation representation): EAL4 introduces ADV_IMP.1 (source-code review of selected modules); EAL5 keeps ADV_IMP.1 with broader coverage; EAL6 requires the complete implementation representation (ADV_IMP.2). ADV_IMP augmentation from EAL4 toward EAL5-class coverage is rare outside government high-assurance programmes.
• ADV_TDS (TOE design): the design-documentation depth that the evaluator reviews. Baseline progression is ADV_TDS.1 (EAL2) through ADV_TDS.6 (EAL7).
• ALC_CMC / ALC_CMS (Configuration management): the developer’s CM rigor and scope. Baseline progression runs from ALC_CMC.1 (EAL1) through ALC_CMC.5 (EAL6, EAL7).
• ALC_TAT (Tools and techniques): development tool discipline. ALC_TAT.1 is the EAL4 baseline; ALC_TAT.2 is the EAL5 baseline; ALC_TAT.3 is the EAL6 and EAL7 baseline.
• ACO (Composition): used when evaluating a TOE built from already-certified components, such as a smart-card applet on top of a separately certified platform on top of a separately certified integrated circuit. ACO is a class rather than a single family and does not map onto the EAL ladder.

EAL baselines and the augmentations seen in real certificates

The two columns below name the AVA_VAN baseline of each EAL package (the most procurement-relevant single fact) and the augmentations that typically appear on top of that package in real certificates.

A smart-card EAL4+ certificate almost always means EAL4 augmented by AVA_VAN.5 and ALC_DVS.2. A network-equipment EAL4+ certificate often means EAL4 augmented by ALC_FLR.2, normally conformant to a collaborative Protection Profile. These are not the same assurance picture, and a procurement matrix that flattens them to “EAL4+” loses the distinction. The Guide to EAL Levels covers the same territory at a higher altitude for readers who want the EAL ladder in context.

Writing augmentations into a procurement specification

If a tender specification reads “EAL4+ minimum”, a vendor can satisfy it with EAL4+ALC_FLR.1, EAL4+ALC_DVS.2, EAL4+AVA_VAN.5, or a richer combination. Three bids can come in at headline-equivalent EAL4+ and represent very different real assurance.

A specification that names the augmentations explicitly avoids the EAL4-versus-EAL4+ trap. Useful patterns:

• For smart cards, secure elements, and secure ICs: “EAL4 augmented by AVA_VAN.5 and ALC_DVS.2 minimum, certified under a SOG-IS legacy or EUCC successor scheme.”
• For network equipment, firewalls, and routers: “EAL4 augmented by ALC_FLR.2 minimum, conformant to the relevant collaborative Protection Profile, issued by a CCRA Certificate Authorizing member.”
• For mass-market software where mutual recognition is the priority: “EAL2 augmented by ALC_FLR.2 minimum, CCRA-recognised certificate.”
• For HSMs and high-assurance cryptographic modules: “EAL4 augmented by AVA_VAN.5 minimum, with a matching FIPS 140-3 cryptographic-module validation.”

Three further drafting tips:

1. Name the components, not the plus sign. “EAL4 augmented by AVA_VAN.5” is biddable; “EAL4+” is not.
2. Cross-check the augmentation against the threat model. AVA_VAN.5 is appropriate when the deployment threat includes a well-funded attacker with specialist equipment. AVA_VAN.2 or AVA_VAN.3 is appropriate when the attacker is assumed to be remote with public tooling. Asking for AVA_VAN.5 on a product that does not face that threat raises cost without raising assurance for the buyer.
3. Match ALC_FLR to the deployment horizon. A multi-year deployment benefits from ALC_FLR.2 or ALC_FLR.3 because the vendor commits to a flaw-handling process. A short-deployment commodity purchase often does not need ALC_FLR at all.

Tracking augmentations across the certified-product landscape

NenkinTracker indexes every CC, EUCC, SESIP, PSA Certified, EMVCo, and MIFARE certificate, surfacing the augmentation list alongside the headline EAL number. Filtering by augmentation (for example, all EAL4 certificates that include AVA_VAN.5) makes it possible to build a candidate shortlist that actually matches the procurement specification, rather than a shortlist that flatters the marketing claim. See the glossary for the class identifiers (ADV, AGD, ALC, ATE, AVA, ACO) used throughout this entry.

Getting an independent read on a vendor claim

For high-value or high-assurance procurements where the augmentation choices materially change the comparison, an independent advisor can pressure-test both the specification and the vendor responses against the actual Security Target before signature. Nenkin Technologies AS offers procurement advisory on this basis, sitting buyer-side and not taking vendor referral fees. The work is the same regardless of scheme: read the ST, walk the augmentation list against the threat model, confirm the certificate state with the issuing scheme, and write the augmentation set into the contract so it survives the next renewal cycle.