Electronics Guide

Security Evaluation Criteria

Security evaluation criteria provide standardized frameworks for assessing and certifying the security capabilities of hardware devices, cryptographic modules, and security systems. These criteria enable independent verification that products meet specific security requirements, facilitating trust between manufacturers, customers, and regulatory bodies. Understanding these evaluation frameworks is essential for developing compliant security hardware and making informed procurement decisions.

Common Criteria (ISO/IEC 15408)

Common Criteria represents the most comprehensive international standard for security evaluation, providing a framework applicable to virtually any type of security product. Standardized as ISO/IEC 15408 (current edition published in 2022), it was originally developed through collaboration between the United States, Canada, and European nations. The Common Criteria Recognition Arrangement (CCRA) enables certificates issued by one member nation to be recognized by others, reducing the need to re-evaluate the same product in each market.

The framework defines seven Evaluation Assurance Levels (EALs) ranging from EAL1 (functionally tested) to EAL7 (formally verified design and tested). Each level requires progressively more rigorous testing and documentation. EAL1 provides minimal assurance with basic functional testing, while EAL4 represents methodically designed, tested, and reviewed products suitable for most commercial applications. Higher levels, EAL5 through EAL7, employ semiformal and formal verification methods and are typically reserved for high-security government and military applications.

An important caveat governs international recognition. Since the CCRA was revised in 2014, mutual recognition of certificates based on a custom Security Target is limited to EAL2 (optionally augmented with flaw remediation). Assurance above that threshold is recognized internationally only when the evaluation is performed against a collaborative Protection Profile developed by an international Technical Community. Higher-EAL evaluations remain valuable but may be recognized only within regional arrangements such as SOG-IS in Europe rather than across the full CCRA membership.

Protection Profiles define standardized security requirements for specific product categories. For hardware security devices, relevant profiles include those for smart cards, cryptographic modules, and trusted platform modules. Security Targets describe how specific products implement Protection Profile requirements, detailing the security functions, assurance measures, and operational environment.

The evaluation process involves independent testing laboratories accredited by national schemes. Evaluators examine design documentation, test implementation, perform vulnerability analysis, and verify that security functions operate correctly. The process can take months or years depending on the complexity and assurance level sought.

FIPS 140-3 Cryptographic Module Validation

Federal Information Processing Standard (FIPS) 140-3 specifies security requirements for cryptographic modules used within United States federal systems and by organizations handling sensitive but unclassified information. The standard is maintained by the National Institute of Standards and Technology (NIST) and represents one of the most widely recognized cryptographic certifications globally. Unlike its predecessor, FIPS 140-3 adopts the international standard ISO/IEC 19790:2012 for its requirements and ISO/IEC 24759:2017 for the associated test methods, aligning United States validation with international practice.

Validation is administered through the Cryptographic Module Validation Program (CMVP), operated jointly by NIST and the Canadian Centre for Cyber Security. FIPS 140-3 became effective in 2019, and the CMVP began accepting submissions under it in 2020, after which FIPS 140-2 was phased out for new validations. Modules already validated against FIPS 140-2 remain on the active list for a defined period; under the published transition schedule those certificates move to the historical list on September 21, 2026, after which agencies should not procure them for new deployments.

FIPS 140-3 defines four security levels, each building upon the previous level's requirements. Security Level 1 provides basic security with no specific physical security mechanisms beyond production-grade components. Security Level 2 adds tamper-evidence through seals or pick-resistant locks and role-based authentication. Security Level 3 requires tamper-detection and response mechanisms that zeroize critical security parameters when physical access is attempted. Security Level 4 demands complete protection against environmental attacks and sophisticated physical penetration attempts.

The validation process examines multiple security areas including cryptographic algorithms, random number generation, key management, electromagnetic interference/electromagnetic compatibility (EMI/EMC), self-tests, and design assurance. Modules must implement only NIST-approved or allowed cryptographic algorithms, with implementations tested through the Cryptographic Algorithm Validation Program (CAVP).

Physical security requirements vary by level but may include opaque enclosures, tamper-evident coatings, environmental failure protection, and active tamper response mechanisms. Modules at higher levels incorporate sophisticated sensors detecting voltage variations, temperature extremes, and physical intrusion attempts. Upon detection, the module must immediately zeroize all plaintext critical security parameters.

Documentation requirements are extensive, including security policies, finite state models, and detailed descriptions of all security-relevant interfaces and functions. The certification process typically requires 6-18 months and ongoing maintenance to address vulnerabilities discovered post-certification.

EMV Specifications for Payment Systems

EMV specifications, developed and maintained by EMVCo (a consortium of payment card networks), define security requirements for payment cards, terminals, and backend systems. These specifications ensure global interoperability while maintaining rigorous security standards for financial transactions.

EMV security architecture relies on multiple layers of protection. Chip cards contain secure cryptographic processors implementing payment application kernels. Dynamic authentication generates unique transaction data preventing card cloning attacks that plagued magnetic stripe systems. Offline authentication capabilities enable secure transactions without real-time backend connectivity.

Certification involves multiple components. Card manufacturers must certify payment chips against EMV security requirements covering physical security, cryptographic capabilities, and application behavior. Terminal manufacturers certify that devices correctly implement EMV protocols, properly validate cards, and maintain security of cardholder data. Application providers certify that payment kernels comply with network-specific requirements.

Security features include secure key storage and management, transaction counters preventing replay attacks, cardholder verification through PINs or biometrics, and risk management deciding when to require online authorization. Advanced features like contactless payments add proximity-based security requirements to prevent unauthorized reading or relay attacks.

PCI Hardware Security Module (HSM) Requirements

The PCI Security Standards Council defines security requirements for Hardware Security Modules used in payment processing environments through the PCI PIN Transaction Security (PTS) HSM Modular Security Requirements. These requirements complement other PCI standards, ensuring that cryptographic operations protecting payment data, such as PIN translation, key management, and card personalization, occur within properly secured hardware. The standard addresses the device through manufacturing and up to its point of initial deployment, and recent revisions extend it to remote administration and HSM-as-a-Service deployment models.

Physical security requirements mandate tamper-detection and response mechanisms, secure installation procedures, and controlled access to devices. HSMs must implement zeroization of sensitive data upon detecting physical tampering. Environmental controls ensure devices operate only within specified temperature, voltage, and humidity ranges, with anomalies triggering security responses.

Logical security includes strong authentication for administrative access, separation of duties preventing single-user compromise, comprehensive audit logging, and cryptographic key management following strict hierarchies. Key generation must use NIST-approved random number generators with sufficient entropy. Key backup and recovery procedures maintain availability while preventing unauthorized access.

Certification requires third-party evaluation demonstrating compliance with requirements. Vendors must maintain certifications through regular re-evaluations and promptly address discovered vulnerabilities. Payment processors typically require PCI-certified HSMs for operations involving encryption, decryption, or generation of payment cryptographic keys.

GlobalPlatform Specifications

GlobalPlatform develops and publishes specifications for secure chip technology, enabling interoperable, remotely manageable secure elements across multiple industries. These specifications cover smart cards, embedded secure elements, and trusted execution environments in mobile and IoT devices.

The GlobalPlatform Card Specification defines a standardized framework for managing multiple applications on a single secure chip. Security Domains provide isolated environments where different organizations can independently manage their applications without compromising overall device security. This enables business models where card issuers, service providers, and application developers can coexist on shared hardware.

Secure Channel Protocols enable encrypted, authenticated communication between off-card entities and on-card applications. These protocols protect sensitive data during personalization, application installation, and operational commands. Multiple protocol versions accommodate different security requirements and computational capabilities.

Trusted Execution Environment (TEE) specifications define secure operating systems and interfaces for mobile devices. TEEs provide isolated execution environments protecting sensitive applications from potentially compromised rich operating systems. Applications like mobile payments, digital rights management, and biometric authentication leverage TEE capabilities.

Certification programs verify that implementations comply with GlobalPlatform specifications. Certification enables interoperability, allowing cards and applications from different vendors to work together while maintaining security. This reduces deployment costs and enables multi-vendor ecosystems.

SESIP (Security Evaluation Standard for IoT Platforms)

SESIP provides a streamlined security evaluation methodology specifically designed for IoT devices and platforms. Now maintained by GlobalPlatform, it reuses the assurance concepts of Common Criteria but defines IoT-specific assurance packages rather than the traditional EAL packages. Recognizing that full Common Criteria evaluation can be overly burdensome for connected products, SESIP balances security assurance with the time-to-market and cost considerations critical in IoT markets.

The framework defines five assurance levels. SESIP Level 1 is a self-assessment providing a basic, claim-based level of assurance suitable for low-risk applications. SESIP Level 2 adds independent black-box penetration testing; it is the highest level achievable for a closed-source platform without developer cooperation. SESIP Level 3 adds white-box vulnerability analysis with source-code review combined with penetration testing, offering assurance comparable to higher Common Criteria resistance levels. SESIP Levels 4 and 5 are reserved for the structured reuse of platforms (or platform components) already certified under SOG-IS by licensed evaluation laboratories, allowing high-assurance results to be inherited efficiently by composite products.

Evaluation covers the complete IoT security lifecycle including secure boot, secure firmware updates, cryptographic implementations, secure storage, and runtime protection mechanisms. Unlike some traditional schemes focusing primarily on cryptographic modules, SESIP examines the entire platform including software, hardware, and their interactions.

The methodology emphasizes practical security testing over pure documentation review. Evaluators perform actual attacks attempting to compromise devices, extract secrets, or bypass security mechanisms. This practical approach identifies real-world vulnerabilities that might not be apparent from design documentation alone.

SESIP certification provides market differentiation for IoT manufacturers, demonstrates due diligence to customers and regulators, and facilitates security-conscious procurement decisions. The framework's efficiency makes certification economically feasible even for cost-sensitive IoT applications.

PSA Certified Framework

PSA Certified, founded by Arm together with a consortium of security laboratories and now administered by GlobalPlatform, provides a security certification framework for IoT devices built around the Platform Security Architecture. While its concepts originated in the Arm ecosystem, the scheme is architecture-agnostic and certifies products on processors from multiple vendors. PSA addresses the fragmented IoT security landscape by establishing baseline security requirements and standardized evaluation processes centered on a hardware Root of Trust.

The framework defines a tiered assurance model. PSA Certified Level 1 involves a structured self-assessment against PSA security goals, providing baseline assurance for lower-risk applications. PSA Certified Level 2 requires independent laboratory evaluation demonstrating resilience against scalable software attacks. PSA Certified Level 3 adds substantial hardware attack resistance, with laboratory penetration testing against side-channel and fault-injection techniques. A higher Level 4, addressing the most demanding physical-attack resistance, has since been introduced for products that require it.

PSA Root of Trust specifications define hardware and firmware requirements establishing trusted foundations for IoT devices. This includes secure boot processes, cryptographic services, secure storage, and attestation capabilities. Implementations must provide isolation between trusted and untrusted code, protecting security-critical functions from potentially vulnerable application software.

The certification process evaluates adherence to PSA specifications through documentation review, security testing, and vulnerability analysis. Certified products demonstrate implementation of fundamental security capabilities including hardware-based root of trust, secure boot, secure firmware updates, and cryptographic operations.

PSA Certified enables silicon vendors, device manufacturers, and software providers to demonstrate security credentials, facilitating customer confidence and regulatory compliance. By chaining certifications, a device maker can build on a chip that is already PSA Certified, inheriting its assurance and reducing duplicated evaluation effort across the supply chain.

Security Levels and Classification

Security evaluation frameworks typically define multiple security levels accommodating different threat models and protection requirements. Understanding these levels enables appropriate selection of security products matching application needs without unnecessary cost or complexity.

Low security levels provide protection against casual attackers with limited resources and expertise. These levels suit applications where attack motivation is low or where additional security layers compensate for hardware limitations. Implementation costs are minimal, making these levels appropriate for consumer applications and low-value transactions.

Medium security levels protect against dedicated attackers with moderate resources and technical expertise. Evaluations include penetration testing, vulnerability analysis, and examination of common attack scenarios. These levels suit most commercial applications including payment systems, access control, and enterprise security.

High security levels defend against sophisticated attackers with substantial resources, advanced equipment, and deep technical knowledge. Evaluations involve formal methods, exhaustive testing, and analysis of subtle vulnerabilities. Implementation requires expensive protective measures including advanced tamper detection, environmental monitoring, and formal verification. Applications include government systems, critical infrastructure protection, and high-value financial transactions.

The highest security levels address nation-state threat actors with essentially unlimited resources. Evaluation involves formal mathematical proofs, covert channel analysis, and protection against cutting-edge attack techniques. Only the most critical applications justify the extensive cost and complexity these levels require.

Evaluation Methodologies

Security evaluation methodologies define systematic processes for assessing whether products meet specified security requirements. Effective methodologies balance thoroughness with practicality, identifying real vulnerabilities while remaining economically feasible.

Documentation review examines security architectures, design specifications, and implementation details. Evaluators verify that designs address relevant threats, that security functions are correctly specified, and that documentation accurately reflects implementations. This phase identifies design-level vulnerabilities before they manifest in finished products.

Functional testing verifies that security mechanisms operate correctly under normal conditions. Tests confirm that authentication succeeds for authorized users, that encryption produces correct outputs, and that access controls properly restrict operations. Automated test suites provide reproducible verification while manual testing explores edge cases and unusual scenarios.

Vulnerability assessment systematically searches for security weaknesses. Evaluators examine implementations for common vulnerability patterns, analyze attack surfaces, and attempt to bypass security mechanisms. This includes both automated scanning tools and manual expert analysis. Discovered vulnerabilities must be resolved or explicitly accepted before certification.

Penetration testing simulates real-world attacks attempting to compromise devices. Testers use sophisticated equipment and techniques including side-channel analysis, fault injection, and reverse engineering. Successful attacks demonstrate concrete vulnerabilities requiring remediation. The depth and sophistication of penetration testing scales with the security level sought.

Formal methods apply mathematical techniques proving that implementations satisfy security properties. While expensive and time-consuming, formal verification provides the highest assurance level, demonstrating that specific classes of vulnerabilities cannot exist. High-security applications increasingly employ formal methods for critical security components.

Maintenance and Recertification

Security certification is not a one-time achievement but an ongoing process. Maintaining certification requires addressing newly discovered vulnerabilities, updating documentation, and periodically re-evaluating products as threats and evaluation criteria evolve.

Vulnerability management processes monitor for security issues affecting certified products. When vulnerabilities are discovered through internal testing, external research, or operational experience, vendors must assess impact and develop appropriate responses. Significant vulnerabilities may require recertification after remediation, while minor issues might be addressed through standard update procedures.

Configuration management maintains correspondence between evaluated versions and deployed products. Changes to hardware, firmware, or software may affect security properties, potentially invalidating certifications. Strict change control ensures that only evaluated configurations are deployed, or that modifications undergo appropriate re-evaluation before deployment.

Periodic recertification accounts for evolving threats and improved evaluation techniques. Certifications typically have defined validity periods, after which products must undergo re-evaluation. This ensures that products maintain security against contemporary threats and comply with updated evaluation criteria.

Update procedures balance security maintenance with certification requirements. Security patches must be deployable promptly to address critical vulnerabilities, yet changes risk invalidating certifications. Evaluation schemes increasingly provide expedited processes for security updates, enabling rapid response while maintaining certification integrity.

End-of-life planning addresses certification implications when products are discontinued. Vendors should maintain certification through products' operational lifetimes and clearly communicate when certification will end. This enables customers to plan transitions to newer certified products before existing certifications expire.

Choosing Appropriate Evaluation Criteria

Selecting appropriate security evaluation criteria requires balancing security requirements, regulatory obligations, customer expectations, and economic constraints. Different criteria suit different applications, and multiple certifications may be necessary for products serving diverse markets.

Regulatory requirements often mandate specific certifications. Government systems may require Common Criteria evaluation at specified levels. Payment applications need EMV and PCI certifications. Understanding applicable regulations guides certification selection and prevents costly late-stage compliance discoveries.

Market expectations influence certification needs even without regulatory mandates. Customers increasingly expect security certifications demonstrating due diligence. Industry-specific frameworks like SESIP for IoT or PSA Certified for Arm-based devices provide relevant assurance for target markets.

Cost considerations include both initial certification expenses and ongoing maintenance costs. Common Criteria evaluations at high EALs can cost millions of dollars and take years, while streamlined frameworks like SESIP offer faster, more economical alternatives. Certification costs must be weighed against market access benefits and risk mitigation value.

International recognition affects certification utility. Common Criteria benefits from broad mutual recognition agreements enabling single evaluations accepted across many countries. Other frameworks have more limited geographic acceptance, potentially requiring multiple certifications for global markets.

Future Trends in Security Evaluation

Security evaluation frameworks continue evolving to address emerging technologies and threats. Quantum computing threatens current cryptographic implementations, driving development of quantum-resistant algorithm certifications. Artificial intelligence and machine learning introduce new security challenges requiring evaluation methodologies addressing adversarial AI and model extraction attacks.

Evaluation automation increasingly supplements manual testing. Formal verification tools, automated vulnerability scanners, and continuous security testing reduce costs while improving coverage. However, sophisticated attacks still require expert human evaluators, ensuring ongoing roles for manual assessment.

Agile certification processes accommodate rapid development cycles increasingly common in hardware and firmware development. Traditional evaluation models assuming static products conflict with continuous update practices. New approaches enable ongoing certification through incremental testing and modular evaluation of components.

Transparency and public scrutiny grow more important as security awareness increases. Open evaluation criteria, published test results, and vulnerability disclosure processes build trust while enabling security research communities to contribute to product improvement. Balancing transparency benefits with protecting proprietary information and preventing attack enablement remains challenging.

As security hardware becomes increasingly critical to global infrastructure, robust evaluation criteria provide essential assurance that products deliver promised protection. Understanding these criteria enables informed development, procurement, and deployment decisions supporting secure electronic systems.

Related Topics