Common Criteria (CC)

A vendor-provided document that specifies the security properties of a specific, identified product (the Target of Evaluation or TOE). The ST can claim conformance to one or more Protection Profiles and details the exact Security Functional Requirements (SFRs) and Security Assurance Requirements (SARs) the product meets.

• Key Distinction: A PP is a generic wishlist; an ST is a product's specific promise.
• Content: Includes the TOE boundary, operational environment assumptions, and a rationale for how the SFRs counter identified threats.

The specific product or system—including its documentation, guidance, and supporting hardware/software—that is the subject of a Common Criteria evaluation. Defining a clear TOE boundary is critical, as it separates the security-relevant components from the rest of the operational environment.

• Example: A TOE could be a complete operating system, a hardware security module, or a specific application's cryptographic module.
• Context: The evaluation only validates the security claims made about the components inside the TOE boundary.

A numerical grade from EAL1 (functionally tested) to EAL7 (formally verified design and tested) that represents the depth and rigor of the evaluation. A higher EAL does not mean 'more secure'; it means the security claims were verified to a higher degree of assurance.

• EAL1-EAL4: Focus on commercial-grade development practices and testing.
• EAL5-EAL7: Require semi-formal to formal design specifications and rigorous vulnerability analysis, often for high-risk government or critical infrastructure use.

The specific, auditable security behaviors that the TOE must exhibit. These are selected from a standardized catalog in Part 2 of ISO/IEC 15408. SFRs define functions like identification and authentication (FIA), audit (FAU), and cryptographic support (FCS).

• Structure: Each SFR is a verbatim requirement from the standard, with vendor-defined assignments and selections.
• Example: FIA_UAU.5.1 requires the TOE to provide a specific set of authentication mechanisms to verify a user's claimed identity.

The criteria that specify the measures taken during the product's development, engineering, and delivery to ensure it meets its SFRs. SARs are defined in Part 3 of ISO/IEC 15408 and cover the rigor of life-cycle management (ALC), testing depth (ATE), and vulnerability assessment (AVA).

• Focus: SARs validate the process and evidence, not just the final product's features.
• Example: ALC_CMC.4 requires a documented configuration management system to track all implementation representation changes.

The immutable cryptographic foundation upon which Common Criteria evaluations for silicon are built. An HRoT provides the initial trust anchor—typically a ROM or eFuse—that validates the first firmware stage. For AI accelerators seeking CC certification, the HRoT must resist physical tampering and provide secure key storage that persists through the entire boot chain. Without a properly implemented HRoT, higher-level security functions like secure boot and remote attestation lack a verifiable starting point.

The U.S. government standard for cryptographic module validation, now aligned with ISO/IEC 19790, that complements Common Criteria evaluations. While CC assesses a product's overall security functionality, FIPS 140-3 focuses specifically on cryptographic algorithm implementation and key management. For AI infrastructure components, a module may hold both certifications: CC for the system-level security target and FIPS 140-3 for the embedded cryptographic library. The standard defines four security levels, from basic software cryptography to tamper-resistant hardware with environmental failure protection.

A platform integrity mechanism that Common Criteria evaluations verify as part of the Trusted Computing Base. Secure boot ensures that only cryptographically signed firmware and bootloaders execute during system startup. Each stage verifies the signature of the next before passing control, creating an unbroken chain of trust anchored in the HRoT. For AI inference servers, secure boot prevents the injection of malicious firmware that could exfiltrate model weights or manipulate inference results. CC evaluations examine the signature verification algorithms, key storage, and anti-rollback mechanisms.

A critical capability evaluated under Common Criteria that allows a remote verifier to cryptographically confirm a platform's integrity. The process involves:

• Quote Generation: A TPM signs PCR values with an Attestation Identity Key
• Verification Service: Validates the quote against known-good PCR measurements
• Freshness Proof: Nonce inclusion prevents replay attacks In sovereign AI contexts, remote attestation enables a central orchestrator to verify that edge inference nodes are running authorized firmware before dispatching sensitive model workloads.

The end-to-end verification of component provenance that Common Criteria evaluations increasingly require for high-assurance products. Traceability ensures that every silicon component—from the foundry to the deployment site—has not been substituted or tampered with. Techniques include cryptographic die-level identity, secure provisioning during manufacturing, and hardware bills of materials (HBOMs). For AI infrastructure, this prevents the insertion of compromised accelerators or memory modules that could create covert exfiltration channels for training data.