Security Standards and Compliance
Security hardware operates inside a dense framework of international standards, government regulations, and sector mandates. These documents turn abstract security goals into testable requirements: which algorithms a module may use, how strongly it must resist physical attack, who may evaluate it, and where it may be sold. A cryptographic design that is sound on paper still fails commercially if it cannot produce the certificates that customers, auditors, and procurement officers demand.
Compliance therefore serves two purposes at once. It provides independent evidence that a product does what its designers claim, and it grants access to markets that are closed to unvalidated equipment. United States federal agencies buy cryptographic modules validated under FIPS 140-3. Payment networks accept only hardware security modules and PIN entry devices approved by the PCI Security Standards Council. European public-sector buyers increasingly look for certificates issued under the European Union Common Criteria scheme. In each case the certificate, not the datasheet, opens the door.
The sections below survey this landscape: why compliance carries weight, how formal evaluation and certification work, which sector mandates apply to which industries, how export controls and mutual recognition shape international trade, and what it takes to keep a certificate valid once it is earned. The four subcategories that follow examine each dimension in depth.
Articles in This Category
The Importance of Standards Compliance
Standards perform several distinct jobs in the hardware security ecosystem. They establish a baseline that products must meet, so that a buyer without a cryptography team can still compare offerings. They define a common vocabulary and a common test method, which makes claims from different vendors commensurable. They enable interoperability, so that a smart card from one supplier works with a terminal from another. And they create the framework within which an independent laboratory, rather than the vendor, judges whether the security claims hold.
In regulated markets, compliance is often not optional. Under the Federal Information Security Modernization Act, United States federal agencies must protect sensitive information with cryptographic modules validated by the Cryptographic Module Validation Program (CMVP), a joint program of the National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security. FedRAMP inherits that requirement for cloud services. Payment acquirers require PCI-approved devices for PIN translation and key management. Defense programs specify equipment approved by the National Security Agency. In each case an unvalidated product is not merely less attractive; it is ineligible.
Compliance also costs real money. Laboratory fees, design changes made to satisfy a physical security level, documentation packages, algorithm testing, and the engineering time spent answering evaluator questions add up, and the schedule impact is frequently larger than the invoice. CMVP validation queues have historically stretched validation timelines to a year or more, which means the certificate may arrive well after the silicon does. Organizations therefore choose their certifications strategically, pursuing the ones their target markets require and declining those that would deliver assurance nobody is asking to see.
Security Evaluation and Certification
Formal evaluation provides independent verification that a product meets its stated security objectives. Two frameworks dominate hardware security, and they answer different questions. Common Criteria asks whether a product satisfies a security specification written for its product class. FIPS 140-3 asks whether a cryptographic module correctly and safely implements approved cryptography inside a defined boundary.
Common Criteria
Common Criteria is standardized as ISO/IEC 15408, with the companion evaluation methodology published as ISO/IEC 18045. Requirements are expressed as security functional requirements and security assurance requirements. A Protection Profile states the requirements for a class of products, such as smart cards, network devices, or database systems; a Security Target states what a specific product claims, usually by conforming to one or more Protection Profiles. Evaluation Assurance Levels EAL1 through EAL7 describe the depth and rigor of the evaluation, not the strength of the security function. A high EAL means the claims were examined thoroughly; it does not by itself mean the product is more secure than one evaluated at a lower level against a stronger specification.
Recognition matters as much as the certificate. Under the Common Criteria Recognition Arrangement, signatory nations recognize certificates issued against collaborative Protection Profiles, and otherwise recognize certificates only up to EAL2 augmented with flaw remediation. Higher-assurance recognition has historically been regional. In Europe, the SOG-IS mutual recognition agreement extended recognition further, notably for smart cards and devices with security boxes, and the European Union Common Criteria scheme (EUCC), established by Commission Implementing Regulation (EU) 2024/482 and applicable from 27 February 2025, now provides a harmonized European scheme built on that foundation. Vendors selling into multiple regions must plan for the possibility of more than one certificate.
FIPS 140-3
FIPS 140-3 specifies security requirements for cryptographic modules and adopts ISO/IEC 19790 for the requirements themselves and ISO/IEC 24759 for the associated test methods, replacing the self-contained requirement text of FIPS 140-2. It defines four security levels. Level 1 requires approved algorithms and basic correctness with no specific physical protection. Level 2 adds tamper evidence and role-based authentication. Level 3 requires tamper detection and response that zeroizes plaintext keys when the enclosure is breached, together with identity-based authentication and separated ports for plaintext key entry. Level 4 demands a protection envelope that detects penetration from any direction and defends against environmental attacks outside the module's normal operating range.
Algorithm validation is a prerequisite rather than a part of module validation. Implementations are tested through the Cryptographic Algorithm Validation Program using the Automated Cryptographic Validation Protocol, and entropy sources are assessed separately against the requirements of SP 800-90B. A module certificate lists the algorithm certificates it relies upon, so a failure at the algorithm level blocks the module.
The transition from FIPS 140-2 is nearly complete. The CMVP stopped accepting new FIPS 140-2 submissions in 2021, and the remaining active FIPS 140-2 certificates move to the historical list on 21 September 2026. A historical certificate is not revoked, and deployed equipment does not stop working, but federal agencies are directed not to acquire modules under historical certificates. Any product entering federal procurement now needs a FIPS 140-3 validation.
The Evaluation Process
Both frameworks rely on accredited third-party laboratories. Testing laboratories are accredited under national schemes, and their reports are reviewed by the certifying body before a certificate issues. Evaluation activities typically include design and architecture review, examination of source code and documentation, functional testing, vulnerability analysis, penetration testing, and, for higher physical security levels, laboratory attack work using techniques such as decapsulation, fault injection, and side-channel measurement. The evidence package—security target, design documentation, key management descriptions, life-cycle and configuration management records, and test results—is usually larger than the product's own technical documentation.
Sector-Specific Mandates
Beyond the general-purpose evaluation frameworks, most industries layer on their own requirements, and those requirements often decide the product architecture.
In payments, the PCI Security Standards Council publishes the PIN Transaction Security requirements for point-of-interaction devices and for hardware security modules, alongside PCI DSS for the systems that handle cardholder data. PCI PTS HSM v4.0 extended the standard to cloud-based, multi-tenant HSM services and remote management, reflecting the shift toward HSM-as-a-service, and v5.0, published in May 2026, restructured the modular requirements, raised the minimum strength of firmware-validation and storage keys to 128 bits while excluding Triple DES from that role, and added requirements for HSM clusters, partitioned HSMs, and post-quantum algorithms. PCI DSS v4.0.1 is the current version of the data security standard, and its previously future-dated requirements became mandatory on 31 March 2025. EMVCo maintains the chip card and terminal specifications, with its own approval process for cards, terminals, and contactless kernels.
In government and defense, FISMA drives the use of CMVP-validated modules, and the National Security Agency approves equipment for classified use through its Type 1 process, with the Commercial Solutions for Classified program offering a layered alternative built from commercial products. The NSA's Commercial National Security Algorithm Suite 2.0 sets the algorithm requirements for national security systems and mandates quantum-resistant algorithms, including hash-based signatures for firmware signing.
In automotive, ISO/SAE 21434 defines cybersecurity engineering for road vehicles across the product life cycle, and UN Regulations No. 155 and No. 156 require a certified cybersecurity management system and software update management system for vehicle type approval in the jurisdictions that apply them. Industrial and critical infrastructure systems follow the IEC 62443 series, which assigns security levels to zones and conduits and defines requirements for both product suppliers and system integrators. Healthcare systems handling protected health information in the United States fall under the HIPAA Security Rule, and systems processing personal data of individuals in the European Union must satisfy the security obligations of the General Data Protection Regulation.
Constrained embedded devices are served by lighter-weight schemes. SESIP, a GlobalPlatform methodology adopted as a European standard, provides an evaluation approach scaled to Internet of Things components and composable with Common Criteria evidence. PSA Certified applies a tiered scheme, from a questionnaire-based entry level through laboratory-tested levels, to microcontrollers and the software that runs on them. These schemes trade some depth for cost and schedule, which makes certification realistic for products that could never justify a full Common Criteria evaluation.
Export Control and the International Landscape
Cryptographic hardware is a controlled commodity. The Wassenaar Arrangement coordinates export controls on dual-use goods among its participating states, and Category 5, Part 2 of its control list covers information security. Participating states implement the list in national law. In the United States, the Export Administration Regulations classify most cryptographic products under ECCN 5A002 for hardware and 5D002 for software, with License Exception ENC and mass-market treatment available for many commercial products after classification or notification to the Bureau of Industry and Security. The European Union implements its controls through Regulation (EU) 2021/821. Requirements differ by destination, end user, and end use, and controls extend to technology transfer, which means that sharing design details with foreign nationals can itself be an export.
Some jurisdictions add import or domestic-use controls that are stricter than export rules, requiring local algorithms, local certification, or licensing before cryptographic products may be sold. A product that clears export review in its home country may still need separate national approval to enter a given market.
Mutual recognition reduces, but does not eliminate, duplicated effort. Recognizing one another's certificates lets a vendor evaluate once and sell into many markets, yet national schemes retain their own high-assurance requirements, and regional Protection Profiles may impose functionality that a global product does not otherwise need. Organizations selling internationally must track regulatory change across jurisdictions and budget for the certifications each market actually requires.
Maintaining Compliance
Compliance is a commitment, not an achievement. Standards evolve to address new attack techniques and advances in cryptanalysis, and algorithms once considered sound are deprecated as computational capability grows. NIST SP 800-131A documents the transition schedule for approved algorithms and key lengths, and its retirements—two-key Triple DES, SHA-1 for digital signature generation, and short RSA keys among them—have forced design changes across the industry. Organizations that follow standards development, and that participate in the relevant working groups, see these transitions coming rather than discovering them in an audit.
Certificates themselves expire. CMVP applies a five-year validity period to module certificates, after which the validation moves to the historical list unless the module is revalidated. Common Criteria certificates are maintained through assurance continuity, in which minor changes are accepted on the basis of an impact analysis while major changes trigger reevaluation. Configuration management is what makes this workable: the certified configuration must be identified precisely, and every change assessed against the boundary that was evaluated. A security patch that touches only non-security-relevant code may need nothing more than documentation, while a change inside the cryptographic boundary may require the module to go back to the laboratory.
The near-term agenda is unusually crowded. The FIPS 140-2 certificates that remain active move to historical status on 21 September 2026. The migration to the post-quantum standards NIST published in August 2024—FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, and FIPS 205 for SLH-DSA—requires new algorithm certificates, larger key and signature handling in existing hardware, and, in many cases, new silicon. In the European Union, the Cyber Resilience Act, Regulation (EU) 2024/2847, applies its vulnerability and incident reporting obligations from 11 September 2026 and its main obligations from 11 December 2027, extending baseline cybersecurity duties to essentially all products with digital elements placed on the Union market. A compliance program that treats these as scheduled engineering work, rather than as surprises, absorbs them at far lower cost.
Conclusion
Security standards and compliance form the connective tissue between sound security engineering and market access. Common Criteria and FIPS 140-3 translate abstract security objectives into testable requirements, sector mandates such as PCI PTS, ISO/SAE 21434, and IEC 62443 tell designers what their industry expects, and export controls determine where and to whom a product may be sold. Treating compliance as an integral part of the design process—selecting the target certifications before the architecture is frozen, and generating evaluation evidence as development proceeds—reduces cost, shortens evaluation timelines, and produces stronger products.
The landscape continues to shift. The completion of the FIPS 140-3 transition, the steady deprecation of legacy algorithms, the arrival of the post-quantum standards, and new horizontal regulation in Europe all reward forward-looking planning and crypto-agile designs. The subcategories above examine each dimension in depth—cryptographic standards, export control compliance, industry-specific requirements, and security evaluation criteria—equipping engineers and organizations to navigate this environment with confidence.