Skip to content
Nenkin
Sign inStart free trial

EAL3: Methodically Tested and Checked

EAL3 is a Common Criteria assurance level (ISO/IEC 15408-3) that builds on EAL2 with development-environment security controls, a defined product life-cycle, and testing at a deeper level than the functional interface.

Explore NenkinTracker to find certified products and compare their assurance levels, including EAL3.

Key facts

  • Assurance families covered: adds ADV_FSP.3 (functional specification with complete summary), ADV_TDS.2 (architectural design), ALC_CMC.3 (authorisation controls), ALC_CMS.3 (CM coverage including implementation representation), ALC_DVS.1 (development security), ALC_LCD.1 (life-cycle definition), ATE_COV.2 (analysis of coverage), and ATE_DPT.1 (testing: basic design) over EAL2.
  • Typical product categories: smart card operating system components in some national schemes, telecom equipment in markets that require EAL3 specifically, legacy certificates maintained for historical reasons.
  • Relative cost/time: moderately expensive; the ALC increment materially affects how the vendor documents and audits its development environment.
  • Attack potential resisted: Basic.

What this level tests

Evaluators confirm the developer applies procedural, physical, and personnel security controls to its development site (ALC_DVS.1) and maintains a documented life-cycle model (ALC_LCD.1). Configuration management scope expands to cover the implementation representation (ALC_CMS.3) under stronger authorisation controls (ALC_CMC.3). The TOE design moves from a basic description to an architectural one (ADV_TDS.2), and evaluator testing (ATE_DPT.1) now exercises that design, not just external interfaces.

AVA_VAN.2 still governs vulnerability analysis, so the attacker model remains Basic, the same attack potential as EAL2. AVA_VAN.3, which is the first component to raise the bar to Enhanced-Basic, is the EAL4 baseline. The substantive change at EAL3 is therefore about the developer’s process and the evaluator’s visibility into it, not about attacker strength.

Typical product categories

EAL3 is a middle-ground level. In global CCRA practice it is less common than EAL2 or EAL4, because many vendors that invest in ALC_DVS.1 and ALC_LCD.1 also go on to meet EAL4 requirements. EAL3 persists in specific markets and for legacy product families where a customer has historically required it.

Common misconceptions

EAL is an assurance level, not a security-strength rating. EAL3 tells you the evaluator reviewed more about the development environment and tested the design more deeply than at EAL2. It does not say the product has “higher security” in any absolute sense. Product strength is determined by the Security Target’s objectives and the operational environment.

EAL3 is not a CCRA-recognized level for arbitrary TOEs. CCRA mutual recognition for non-cPP evaluations caps at EAL2 plus the ALC_FLR family. EAL3 certificates are valid within their issuing scheme but recognition by other CCRA members is limited.

Comparison to adjacent levels

  • vs. EAL2: EAL3 adds ADV_TDS.2 (architectural design, up from basic), ADV_FSP.3, ALC_CMC.3, ALC_CMS.3, ALC_DVS.1, ALC_LCD.1, ATE_COV.2, and ATE_DPT.1; the bulk of the increment is about process and design visibility, not attacker strength (AVA_VAN.2 still applies).
  • vs. EAL4: EAL4 introduces source-code review (ADV_IMP.1), modular design documentation (ADV_TDS.3), automated CM (ALC_CMC.4), tool and technique controls (ALC_TAT.1, baseline at EAL4), and AVA_VAN.3 vulnerability analysis at Enhanced-Basic with design knowledge. ALC_FLR is not part of any baseline EAL and requires explicit augmentation when needed.

See the EAL Levels overview, or explore the glossary for the SAR vocabulary.

Frequently asked questions

What is EAL3?
EAL3 is a Common Criteria assurance level (ISO/IEC 15408-3) that builds on EAL2 by adding development-environment security controls (ALC_DVS.1), a documented life-cycle model (ALC_LCD.1), broader configuration management coverage (ALC_CMS.3), and testing against the basic TOE design (ATE_DPT.1). The attacker model stays at Basic potential because vulnerability analysis remains AVA_VAN.2. Most of the increment is about the developer's process, not the product.
Why is EAL3 often skipped in practice?
Vendors who invest in the development-environment controls and life-cycle documentation that EAL3 demands typically also invest the additional effort to reach EAL4, where source-code review and AVA_VAN.3 vulnerability analysis at Enhanced-Basic attack potential add meaningful product assurance. The result is a market split between EAL2 (broad commercial baseline with CCRA recognition) and EAL4 (the high-assurance commercial target), with EAL3 occupying a narrow middle that few products choose.
What product categories use EAL3?
EAL3 is a middle-ground level seen mainly in legacy certificates maintained for historical reasons, in some smart card OS components evaluated under specific national schemes, and in telecom equipment for markets that explicitly require EAL3. It is less common than EAL2 or EAL4 in current global practice. Vendors entering the CC market today rarely pick EAL3 as a fresh target.
How does EAL3 differ from EAL4?
EAL4 introduces source-code-level review (ADV_IMP.1, a subset of the implementation representation), modular design documentation (ADV_TDS.3), automated configuration management (ALC_CMC.4), tool and technique controls (ALC_TAT.1), and AVA_VAN.3 vulnerability analysis at Enhanced-Basic attack potential with access to design. EAL3 examines an architectural design of the TOE (ADV_TDS.2) with no source review, and stays at Basic attack potential.
Is EAL3 recognised internationally under CCRA?
Only partially. CCRA mutual recognition for non-cPP evaluations caps at EAL2 plus ALC_FLR augmentation. EAL3 certificates are valid within their issuing scheme, and individual CCRA members may choose to accept them, but automatic mutual recognition does not extend that far. For higher levels with international recognition, evaluation against a collaborative Protection Profile is the standard route.
Does EAL3 require source-code review?
No. Source-code or implementation-representation review enters at EAL4 via ADV_IMP.1. EAL3 evaluators look at an architectural design of the TOE (ADV_TDS.2) and test the design at a basic level (ATE_DPT.1), but they do not inspect the implementation itself. If your procurement requires evidence that the actual code was reviewed, EAL3 does not provide it; EAL4 is the first level where it appears.
  • EAL1: Functionally TestedEAL1 is the lowest Common Criteria assurance level: independent confirmation that a product behaves as documented. Suitable when threats are low and trust in the vendor is adequate.
  • EAL2: Structurally TestedEAL2 is the workhorse Common Criteria assurance level: a high-level design review with independent vulnerability analysis, and the CCRA mutual-recognition cap for non-cPP evaluations.
  • EAL4: Methodically Designed, Tested, and ReviewedEAL4 is the highest assurance level generally achievable on commercial products without re-engineering for assurance. Standard for smart cards, HSMs, and many government-used products.
  • EAL5: Semiformally Designed and TestedEAL5 introduces semiformal design notation, well-structured internals, and modular-design test depth. Typical for smart card ICs and high-assurance OS kernels.