FIPS 140-2

The foundational level requiring approved algorithms and correct implementation, but no physical security mechanisms beyond basic production-grade components.

• Requires only an approved algorithm (e.g., AES-256) and a validated implementation
• No physical security mechanisms are mandated; a standard PC or server is acceptable
• Ideal for software-only cryptographic modules running on general-purpose operating systems
• Authentication is optional; if present, it requires only role-based authorization
• Example: A software library performing encryption on a standard cloud VM instance

Adds requirements for tamper-evidence and role-based authentication, making it suitable for dedicated hardware where physical access is controlled.

• Requires tamper-evident coatings or seals that show visible signs of physical intrusion
• Mandates role-based authentication where an operator must explicitly assume an authorized role
• Allows software execution on a general-purpose OS evaluated at CC EAL2 or higher
• Designed for environments where operators have controlled but not fully trusted physical access
• Example: A hardware security module (HSM) deployed in a locked data center rack

Requires tamper-resistant physical enclosures and identity-based authentication, preventing an attacker from accessing critical security parameters (CSPs) within the module.

• Enclosures must zeroize all plaintext CSPs upon detection of a physical breach
• Authentication shifts to identity-based mechanisms, verifying the specific individual, not just a role
• Physical ports for CSPs must be physically separated from other ports or logically disabled
• Software must run on an OS evaluated at CC EAL3 with additional security functional requirements
• Example: A FIPS-certified smart card or a hardened VPN appliance in a field-deployed telecom cabinet

The highest level, providing a complete envelope of protection that detects and responds to all unauthorized physical access attempts, designed for operation in physically unprotected environments.

• Enclosure must detect penetration attempts from any direction and immediately zeroize all CSPs
• Protects against environmental attacks such as extreme temperature, voltage, or pressure fluctuations
• Designed for operation in physically unprotected environments where an attacker has full access
• Software must run on an OS evaluated at CC EAL4 with stringent security functional requirements
• Example: A military-grade cryptographic module deployed in an unattended field sensor or satellite

The successor to FIPS 140-2, published in 2019, which aligns U.S. cryptographic module validation with the international ISO/IEC 19790:2012 standard. Key changes include:

• Mandatory non-invasive physical security testing for all levels
• New software/firmware security requirements replacing the old 'operational environment' model
• Stricter self-testing requirements for critical functions
• A phased transition period where FIPS 140-2 certificates remain valid until September 2026, after which new submissions must target 140-3

The Security and Privacy Controls for Information Systems and Organizations catalog that mandates the use of FIPS 140-2 validated cryptography. Specific controls include:

• SC-13: Cryptographic Protection — requires FIPS-validated modules for federal systems
• SC-28: Protection of Information at Rest — mandates encryption of stored ePHI
• SC-8: Transmission Confidentiality and Integrity — requires encrypted data in transit Healthcare organizations pursuing FedRAMP or DoD IL4/IL5 authorization must demonstrate compliance with these controls, making FIPS 140-2 a non-negotiable dependency.

A dedicated physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing at FIPS 140-2 Level 3 or higher. In healthcare cloud architectures:

• AWS CloudHSM and Azure Dedicated HSM provide single-tenant, FIPS 140-2 Level 3 validated appliances
• HSMs perform encryption, decryption, and signing operations within a tamper-resistant hardware boundary
• They are critical for protecting the root of trust in a healthcare PKI, securing the keys that encrypt ePHI at scale
• Unlike software modules, Level 3 HSMs zeroize all keys if physical tampering is detected

A HIPAA addressable implementation specification that requires covered entities to protect ePHI stored on physical media. FIPS 140-2 validated modules provide the algorithmic assurance:

• AES-256 in FIPS mode is the de facto standard for encrypting EBS volumes, S3 buckets, and database tables in healthcare clouds
• The cryptographic module, not just the algorithm, must be validated — an AES implementation without a FIPS certificate is non-compliant for federal systems
• Envelope encryption patterns use a FIPS-validated master key (stored in an HSM or KMS) to encrypt data keys that protect the actual data