Electronics Guide

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 standard is modular. ISO/IEC 15408 sets out the general model, the catalog of security functional requirements, the catalog of security assurance requirements, the framework for evaluation methods and activities, and the predefined packages of requirements. A companion standard, ISO/IEC 18045, defines the Common Evaluation Methodology (CEM) that laboratories follow so that two accredited laboratories reach comparable conclusions about the same product. The 2022 edition broadened the scheme beyond the traditional assurance levels by formalizing reusable requirement packages and streamlined, direct-rationale Protection Profiles.

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.

The EAL number alone is a poor description of resistance to attack. What matters for hardware is the vulnerability analysis component, AVA_VAN, which specifies the attack potential an evaluator must assume. EAL4 includes AVA_VAN.3, EAL5 includes AVA_VAN.4, and EAL6 and EAL7 include AVA_VAN.5. Smart cards and secure elements are therefore usually certified as EAL4+ or EAL5+, where the augmentation raises AVA_VAN to level 4 or 5 and adds development-environment assurance. A plain EAL5 certificate and an EAL4 augmented with AVA_VAN.5 describe very different laboratory effort.

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.

Europe is consolidating this regional practice. Under the European Union Cybersecurity Act, the European Commission adopted the EUCC scheme, a Common Criteria-based certification scheme that builds on the SOG-IS body of Protection Profiles and evaluation practice and became applicable in 2025. EUCC defines two assurance levels, substantial and high, and provides a single European framework for accrediting laboratories, issuing certificates, and handling vulnerabilities after certification. Vendors selling security hardware into Europe should track EUCC alongside their CCRA certificates.

Protection Profiles define standardized security requirements for specific product categories. For hardware security devices, the most influential examples include the Security IC Platform Protection Profile maintained under the German scheme, which underpins most certified smart card and secure element silicon, and the Trusted Computing Group's Protection Profile for TPM 2.0. Security Targets describe how specific products implement Protection Profile requirements, detailing the security functions, assurance measures, and operational environment. Composite evaluation lets an operating system or application be certified on top of an already certified chip, reusing the hardware evaluation rather than repeating it.

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, and the cost scales sharply with the assurance requirements: a low-EAL evaluation against a collaborative Protection Profile is a modest project, while a high-assurance smart card evaluation with penetration testing consumes substantial laboratory time and developer support.

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 on September 22, 2019, and the CMVP began accepting submissions under it on September 22, 2020, after which FIPS 140-2 was phased out for new validations. A FIPS 140-2 certificate remains on the active list for five years from validation or until September 21, 2026, whichever comes first; on September 22, 2026, the remaining FIPS 140-2 certificates move to the historical list. Historical status is not revocation. Federal agencies should not include historical modules in new procurements, but existing deployments may continue to operate them.

Because the requirements come from ISO/IEC 19790, the CMVP publishes its United States-specific interpretations separately in the NIST Special Publication 800-140 series, which modifies the annexes of the ISO standard for approved algorithms, security policies, authentication, and documentation. A practical consequence for vendors is that the approved algorithm list, not the module architecture, is often the first thing that must change when a design moves from FIPS 140-2 to FIPS 140-3.

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, life-cycle assurance, and mitigation of other attacks. Modules must implement only NIST-approved or allowed cryptographic algorithms, with implementations tested through the Cryptographic Algorithm Validation Program (CAVP). Entropy sources require separate justification and testing under the Entropy Source Validation program, which applies the statistical and design requirements of NIST SP 800-90B; an inadequate entropy claim is a common cause of delay. FIPS 140-3 also introduced explicit non-invasive attack mitigation requirements, giving side-channel resistance a defined place in the standard rather than leaving it to vendor assertion.

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 a public security policy, a finite state model, and detailed descriptions of all security-relevant interfaces and functions. Laboratory testing typically requires several months, but schedules are dominated by the CMVP review queue: a module sits on the Modules in Process list from laboratory submission until the certificate issues, and total elapsed time from project start to certificate frequently exceeds a year. Vendors should plan validation as a program with ongoing maintenance rather than a one-time gate, since algorithm transitions and post-certification vulnerabilities both require follow-up submissions.

EMV Specifications for Payment Systems

EMV specifications, developed and maintained by EMVCo, define security requirements for payment cards, terminals, and backend systems. EMVCo is owned by the major payment networks, and its specifications ensure global interoperability while maintaining rigorous security standards for financial transactions. EMVCo does not itself set the commercial rules for accepting a certificate; individual payment networks decide what they require, so a product usually needs both an EMVCo approval and network-specific type approval.

EMV security architecture relies on multiple layers of protection. Chip cards contain secure cryptographic processors implementing payment application kernels. Each transaction produces an application cryptogram computed with a card-unique symmetric key, so the data captured from one transaction cannot authorize another. This is the structural defense against the card cloning that plagued magnetic stripe systems, where the authenticating data was static and replayable.

Offline data authentication lets a terminal verify a card without contacting the issuer, which matters for transit gates, in-flight sales, and regions with unreliable connectivity. The original static scheme, in which the card presents a fixed issuer signature, is obsolete because a copied signature remains valid. Dynamic and combined dynamic schemes require the card to sign a terminal-supplied unpredictable number with a private key held in the chip, and combined authentication binds that signature to the transaction cryptogram itself, so the authentication cannot be separated from the payment it authorizes.

Certification involves multiple components. Silicon and platform vendors submit secure chips to the EMVCo security evaluation process, run by accredited laboratories that perform physical and side-channel attack testing, and the resulting approvals carry defined expiry dates that reflect advancing attack capability. 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. Level 1 approval covers electrical and transport-layer behavior, while Level 2 approval covers the payment application kernel.

Security features include secure key storage and management, application transaction counters preventing replay, cardholder verification through PINs or biometrics, and terminal and issuer risk management that decides when a transaction must go online for authorization. Contactless payment adds proximity-based requirements, and relay attacks, in which an attacker extends the radio link between a genuine card and a distant terminal, are addressed with strict timing constraints on the exchange rather than with cryptography alone.

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 is modular: separate modules cover physical and logical security, device management through manufacturing and delivery, and the specific functions a device is approved to perform.

The Council published version 5.0 in May 2026, replacing the 2021 version 4.0. The revision reflects how HSMs are actually deployed today. Device-security keys, such as those protecting firmware authentication and internal storage, must now provide an effective key strength of at least 128 bits, and Triple DES is no longer permitted for device security purposes. New modules address key-transfer functionality, remote administration, and overall HSM solution security, and the standard adds explicit controls for cloud and multi-tenant deployments, including isolation between tenants and reliable erasure of a departing tenant's keys. Vulnerability management moved into the life-cycle security modules, and laboratories are expected to perform deeper validation, including source-code review for selected requirements. The revision also anticipates the migration to post-quantum algorithms.

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 evaluation by a PCI-recognized laboratory, and approved devices are listed publicly with an expiry date, so procurement teams can confirm that a specific hardware and firmware version is still approved. Vendors must maintain approvals through re-evaluation and promptly address discovered vulnerabilities. Payment processors typically require PCI-approved HSMs for operations involving PIN translation, key generation, and card personalization. Note that PCI PTS HSM approval and FIPS 140-3 validation answer different questions, and many payment HSMs hold both: FIPS validates the cryptographic module in general terms, while PCI PTS HSM adds payment-specific functional and key-management constraints.

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. The older SCP02 is built on Triple DES, while SCP03 uses AES with CMAC-based integrity and is the protocol chosen for new deployments; SCP11 adds elliptic-curve key establishment for cases where a shared static master key is undesirable. Version choice is a real security decision, not a compatibility detail, because a channel protocol determines how personalization keys are protected in transit.

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. Functional qualification confirms interoperability, allowing cards and applications from different vendors to work together, while the TEE security evaluation scheme applies Common Criteria-style laboratory testing against a published TEE Protection Profile. GlobalPlatform also maintains SESIP, described below, which broadens this work from secure elements to IoT platforms generally. Certification reduces deployment cost and enables multi-vendor ecosystems, but buyers should confirm which kind of certificate a product actually holds, since functional qualification alone makes no claim about attack resistance.

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 is built for composition. A security certificate for a platform, such as a microcontroller with its secure boot and cryptographic services, states the security functional requirements the platform provides so that a product built on it can claim those properties without re-evaluating them. This makes SESIP a natural mapping layer: a single platform evaluation can be mapped against the requirements of several downstream regimes rather than repeated once per regime. Other IoT schemes reuse the format directly, and PSA Certified defines its highest level through SESIP Protection Profiles.

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, which matters increasingly as regulations such as the European Union Cyber Resilience Act extend baseline security obligations to essentially all products with digital elements.

PSA Certified Framework

PSA Certified, founded by Arm together with independent security laboratories and a certification body, provides a security certification framework for IoT devices built around the Platform Security Architecture. TrustCB acts as the scheme's certification body and scheme manager, issuing the certificates and maintaining the scheme rules. 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, reviewed by a laboratory, 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. Level 4, introduced in 2024, targets the most demanding physical-attack resistance: it recognizes a robust integrated Secure Enclave or discrete Secure Element acting as a trusted subsystem to the PSA Root of Trust, and it is specified through SESIP Protection Profiles. A companion Root of Trust component scheme certifies parts that supply only a subset of the required security functions, so silicon and firmware suppliers can be evaluated separately from the finished device.

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. The levels of different schemes are not directly comparable, because each measures something slightly different: Common Criteria measures assurance and assumed attacker capability, FIPS 140-3 measures physical and operational protection of a cryptographic module, and the IoT schemes measure resistance to defined classes of attack.

Underneath the level numbers sits a more useful concept: attack potential. Evaluation communities, particularly the smart card laboratories working under the Joint Interpretation Library methodology, score a demonstrated attack by the elapsed time it required, the expertise of the attacker, the knowledge of the design needed, the access to the sample required, and the cost and availability of the equipment. The total score places the attack on a scale running from basic through enhanced-basic and moderate to high. A product resists a given level when no attack at or below that score succeeds. This scoring is what makes a certificate meaningful across vendors, because it constrains the effort an evaluator must expend before concluding that a device is resistant.

Low levels provide protection against casual attackers with limited resources and expertise, typically working with published techniques and inexpensive equipment. These levels suit applications where attack motivation is low or where additional security layers compensate for hardware limitations. Implementation cost is minimal, making them appropriate for consumer applications and low-value transactions. Software-only protections and self-assessment schemes generally sit here.

Middle levels protect against dedicated attackers with moderate resources and technical expertise, including those able to mount non-invasive attacks such as power analysis on equipment costing a few thousand dollars. Evaluations at these levels include laboratory penetration testing, vulnerability analysis, and examination of known attack scenarios. These levels suit most commercial applications, including payment terminals, access control, and enterprise authentication.

High levels defend against sophisticated attackers with substantial resources, advanced equipment, and deep technical knowledge, including invasive attacks that require decapsulating a chip and probing or editing it with a focused ion beam. Meeting them requires expensive countermeasures: active shields over sensitive layers, glitch and light sensors, randomized execution, memory encryption, and redundant computation. Certified smart cards, secure elements, and high-grade HSMs occupy this range, and applications include national identity documents, payment card silicon, and critical infrastructure protection.

The highest levels address adversaries with essentially unlimited resources, including state actors. Evaluation involves formal mathematical proofs, covert channel analysis, and protection against techniques at the edge of published research. Very few products pursue this range, because the cost and schedule are justified only for classified systems and comparable applications. A practical caution applies at every level: a certificate describes resistance measured at a point in time against then-known techniques, which is why certificates carry expiry dates and why schemes require surveillance and recertification.

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. Side-channel analysis recovers keys from power consumption, electromagnetic emission, or timing, using statistical methods such as differential and correlation power analysis over many traces. Fault injection deliberately pushes a device outside its operating envelope, through voltage and clock glitching, laser pulses aimed at a decapsulated die, or electromagnetic pulses, in order to skip an instruction or corrupt a comparison at a security-critical moment. Invasive analysis goes further, removing packaging and layers to probe internal buses or to modify circuitry. Successful attacks demonstrate concrete vulnerabilities requiring remediation, and the depth of testing scales with the level sought. Standardized test methods, such as the ISO/IEC test methodology for non-invasive attack mitigation referenced by cryptographic module validation, make these results repeatable across laboratories rather than dependent on a single evaluator's ingenuity.

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.

Schemes provide graduated routes for handling change rather than forcing a full re-evaluation for every modification. Common Criteria assurance continuity distinguishes minor changes, which the developer documents in an impact analysis and the scheme accepts through a maintenance report that extends the existing certificate, from major changes affecting security functionality, which require re-evaluation. Cryptographic module validation offers similar tiers, ranging from administrative updates through scenarios in which only the modified portions are retested to full revalidation. Correctly classifying a change is a commercially significant judgment, since the difference between a maintenance report and a re-evaluation can be months of schedule.

Periodic recertification accounts for evolving threats and improved evaluation techniques. Certificates typically carry defined validity or sunset dates, after which products must be re-evaluated to remain listed as current. This reflects the reality that attack capability improves: a device certified as resistant a decade ago faces laboratory equipment and analysis techniques that did not then exist, so an unexpired certificate, not merely a certificate, is what procurement should require.

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 such as SESIP and PSA Certified provide relevant assurance for connected-product markets at a cost that suits them, and both are designed so that a chip-level certificate can be reused by the device built on it.

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, though, as noted above, that recognition is bounded above EAL2 unless a collaborative Protection Profile is used. Other frameworks have more limited geographic acceptance, potentially requiring multiple certifications for global markets. The practical strategy is to identify the one evaluation with the deepest technical requirements, usually the hardware evaluation, and to structure it so its evidence can be reused when addressing the remaining schemes.

Future Trends in Security Evaluation

Security evaluation frameworks continue evolving to address emerging technologies and threats. The migration to post-quantum cryptography is the most immediate driver. NIST published its first post-quantum standards in 2024, covering a lattice-based key encapsulation mechanism and two digital signature schemes, and validation programs have extended algorithm testing to cover them. Certification bodies must now assess not only whether a module implements these algorithms correctly, but whether it does so without leaking through side channels, which is a harder problem for lattice-based schemes than for the elliptic-curve implementations laboratories have spent two decades learning to attack. Artificial intelligence introduces a second front, both as an asset worth protecting, since a model held in a device is valuable intellectual property vulnerable to extraction, and as a tool that accelerates side-channel analysis in the laboratory.

Regulation is expanding the population of products that require some form of assessment. The European Union Cyber Resilience Act imposes baseline cybersecurity obligations, vulnerability handling duties, and reporting requirements on products with digital elements, phased in over the second half of this decade, and the EUCC scheme supplies a corresponding certification route. The effect is to push structured security evaluation outward from smart cards and HSMs into ordinary connected equipment, which increases demand for lightweight, composable schemes.

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 certificate listings, coordinated vulnerability disclosure, and software bills of materials that identify the components inside a product all build trust while enabling research communities to contribute to product improvement. Balancing transparency against the protection of proprietary information and the risk of enabling attacks remains challenging, and schemes differ considerably in how much of an evaluation report they publish.

Conclusion

Security evaluation criteria translate a vague claim that a device is secure into a bounded, testable statement: this configuration of this product resisted attacks up to a defined attack potential, assessed by an accredited laboratory against published requirements. That framing explains both the value and the limits of certification. A certificate covers a specific hardware and firmware version in a stated operating environment, and it reflects the attack techniques known when the work was done.

Choosing well means matching the scheme to the threat and the market rather than pursuing the highest number available. Common Criteria and FIPS 140-3 remain the anchors for government and cryptographic module procurement, EMV and PCI PTS govern payment hardware, and SESIP and PSA Certified provide proportionate, reusable assurance for connected products now falling under broader regulation. Designing for evaluation from the start, keeping evidence current, and planning for recertification cost far less than retrofitting assurance onto a finished product.

Related Topics