FIPS 140-3: Impact on Cloud Security

FIPS 140-3 is the latest standard for cryptographic module security, replacing FIPS 140-2. It aligns with global standards (ISO/IEC 19790:2012) and introduces stricter requirements for encryption and key management, especially in cloud environments. Organisations must transition to FIPS 140-3 by 21 September 2026, as older FIPS 140-2 certificates will no longer be valid. Key updates include continuous self-tests, lifecycle security, and stronger protections against modern threats like post-quantum attacks.

Key Points:

• Deadline: FIPS 140-2 certificates will be archived on 21 September 2026.
• Security Levels: Covers four levels, with Level 3 widely used in regulated industries like finance and healthcare.
• Cloud Providers: Microsoft and AWS have already updated services to meet FIPS 140-3 standards.
• Compliance Risks: Non-compliance can lead to audit failures, lost contracts, and regulatory penalties.

FIPS 140-3 ensures stronger cryptographic security, but achieving compliance requires careful planning, validated modules, and updated systems. Transitioning now is crucial to avoid disruptions.

FIPS 140-2 and 140-3 Explained with Critical Insights for Cryptographic Security and Compliance

What Is FIPS 140-3?

::: @figure {FIPS 140-2 vs FIPS 140-3: Key Differences and Security Levels Comparison} :::

Definition and Purpose

FIPS 140-3 is the cryptographic standard used by the U.S. and Canadian governments to validate cryptographic modules that safeguard Sensitive But Unclassified (SBU) information. These modules, which can include hardware, software, and firmware, handle critical security functions such as encryption, key generation, and digital signatures. The standard is overseen by the Cryptographic Module Validation Program (CMVP), a collaborative effort between NIST and the Canadian Centre for Cyber Security [3].

One of the main goals of FIPS 140-3 is to align internationally. By adopting ISO/IEC 19790:2012 and ISO/IEC 24759 standards, it allows organisations to meet both U.S. and global compliance requirements through a single validation process. This approach is particularly useful for multinational companies that need to navigate varying regulatory frameworks [3]. Additionally, FIPS 140-3 places a strong emphasis on lifecycle security. Unlike its predecessor, it extends validation to cover not just the final product but also its design, implementation, and deployment phases. This is especially critical in dynamic environments like cloud computing, where maintaining security integrity throughout the module's lifecycle is essential [1].

FIPS 140-3 represents a modernization of standards and a step toward greater international alignment. - Rich DuBose, Vault Product Lead, HashiCorp [1]

This shift marks a significant update over the older FIPS 140-2 standard.

Key Differences Between FIPS 140-2 and FIPS 140-3

FIPS 140-3 introduces updates that better reflect today’s software and cloud-based environments, moving beyond the hardware-focused approach of FIPS 140-2. The newer standard applies to hardware, software, firmware, and hybrid modules across all security levels, making it particularly relevant for organisations in the UK that rely on microservices or ephemeral workloads.

One of the standout changes is the introduction of runtime and conditional self-tests, replacing the older power-on only model. These continuous tests are especially beneficial for cloud systems that operate without frequent restarts, ensuring consistent cryptographic integrity. Another important update is the requirement for detailed documentation and ongoing testing of entropy sources, which strengthens the security of cryptographic key generation [3].

FIPS 140-3 Security Levels

The Four Security Levels Explained

FIPS 140-3 defines four security levels for cryptographic modules, each offering increasing protection against physical and environmental threats, as well as stronger authentication measures.

Level 1 is the entry-level standard, requiring validated production-grade equipment and algorithms without additional physical security measures. It’s suitable for general secrets management. For example, HashiCorp's Vault 1.19.4 supports FIPS 140-3 Level 1, helping federal agencies modernise their secrets management while adhering to NIST standards [5][1].

Level 2 adds tamper-evident features, such as seals or coatings that reveal physical breaches, and requires role-based authentication. This level is commonly used in cloud-managed key services [5].

Level 3 takes security further with tamper-resistance measures to safeguard cryptographic keys. At this stage, private keys only move in encrypted form, and Environmental Failure Protection counters voltage or temperature anomalies. Cloudflare explains that Level 3 includes physical tamper-resistance to prevent unauthorised access to cryptographic keys and critical security parameters... robust enclosures, tamper-evident seals, and identity-based authentication [5]. Microsoft has upgraded Azure Managed HSM and Azure Key Vault Premium to meet Level 3 standards across all public cloud regions, enabling compliance with stringent data protection regulations [2].

Level 4 is the highest tier, incorporating tamper-active mechanisms that erase the module's contents if environmental attacks or fault injections occur. This level also requires multi-factor authentication, making it ideal for highly sensitive government and military operations [5][6].

These levels provide a framework for designing security solutions tailored to varying needs.

How Cloud Providers Use Security Levels

Cloud providers utilise these levels to create security solutions that cater to different industries and compliance requirements. For example, standard Key Management Services often meet Level 2 standards, while Managed or Dedicated Hardware Security Modules (HSMs) are designed to achieve Level 3 for industries with stricter regulations [6].

For sectors like finance, healthcare, and government, FIPS 140-3 Level 3 HSMs are recommended to ensure private keys remain encrypted and never leave the hardware in plaintext [5][2]. Cloudflare’s Keyless SSL architecture is an example of this in action, offering improved cloud performance while keeping private keys secure in on-premises HSMs compliant with FIPS 140-3 Level 3 [5]. As discussed earlier, the choice of security level depends on specific industry needs: Level 1 works for general secrets management, Level 2 is suitable for commercial compliance, and Level 3 is crucial for industries governed by regulations like HIPAA, PCI DSS, or FedRAMP [5][1].

Effects on Cloud Encryption and Key Management

The updated protocols bring a sharper focus on cloud security and compliance, which is critical for UK organisations managing sensitive data in the cloud.

Updated Encryption Requirements

FIPS 140-3 has redefined the landscape of cloud encryption by introducing stricter controls over cryptographic algorithms. Features that were previously optional, such as weak JWT signing algorithms and outdated TLS configurations, are now automatically disabled under this standard [4]. As Andrios Robert from hoop.dev puts it:

FIPS 140-3 forces your cryptographic modules into government-approved algorithms, modes, and configurations [4].

The standard aligns with ISO/IEC 19790:2012, ensuring compatibility with global security frameworks while addressing modern threats like side-channel attacks. These attacks exploit indirect data leaks, such as power consumption or electromagnetic emissions, to compromise systems. Unlike its predecessor, FIPS 140-3 specifically counters these advanced threats, requiring cloud providers to meet tougher software security criteria. This includes improved isolation and enhanced protections for cloud-native applications [6][7].

A practical example of this shift came in March 2026, when Red Hat released RHEL 9, the first major operating system to include FIPS 140-3 validated cryptographic modules. The system-wide fips-mode-setup tool was introduced, which configures OpenSSL, GnuTLS, and SSH to use only approved algorithms like AES-XTS for disk encryption and RSA 2048+ for signatures. This move forced organisations to retire outdated algorithms such as 3DES and SHA-1 for digital signatures [8].

Key Management Standards

FIPS 140-3 doesn’t stop at encryption - it also raises the bar for key management. The standard enforces stricter rules around key generation, storage, and management within cloud environments. For instance, cryptographic modules are required to perform comprehensive self-tests at start-up to ensure key management functions and integrity are uncompromised before operations begin [7].

At Level 3 validation, the standard introduces zeroisation, a feature that ensures cryptographic keys are immediately destroyed if a security breach is detected [6]. Additionally, FIPS 140-3 mandates a clearer definition of the cryptographic boundary, specifying where keys can be handled and stored, whether in software or hardware. Achieving Level 3 compliance often requires the use of Hardware Security Modules (HSMs), which provide the necessary tamper resistance for secure key storage [6].

In June 2025, Microsoft upgraded the HSM firmware for Azure Managed HSM and Azure Key Vault Premium to meet FIPS 140-3 Level 3 standards across all public cloud regions. Karen Chen from Microsoft highlighted this achievement:

This transition from FIPS 140-2 to FIPS 140-3 demonstrates our dedication to adhering to the highest security standards and industry best practices, giving you peace of mind knowing that your data is handled with the utmost care and security [2].

With FIPS 140-2 validations set to move to the Historical List in 2026, organisations relying on these older modules risk failing audits for new federal or highly regulated contracts [6]. The stricter key management protocols emphasise the urgency for compliance, as delays in upgrading could lead to regulatory issues.

Compliance Requirements for Cloud Environments

FIPS 140-3 compliance is a must for organisations dealing with U.S. or Canadian government agencies. Cloud environments are required to use FIPS 140-3 validated modules to align with mandates like FedRAMP, HIPAA, and NIST SP 800-53. For instance, the FedRAMP High baseline includes 421 specific security controls, highlighting the extensive measures involved [11].

Industry Standards and Mandates

Regulated industries face strict compliance demands shaped by standards such as FIPS 140-3. This standard forms the backbone of several regulatory frameworks. In the healthcare sector, HIPAA compliance necessitates the use of validated cryptographic modules, with violations potentially leading to penalties of up to £1.5 million [11]. Similarly, financial institutions and defence contractors face stringent requirements, where non-compliance can result in disqualification from lucrative contracts.

From 1st April 2021, AWS FIPS endpoints began requiring at least TLS 1.2 to meet FedRAMP standards [10]. To address this, major cloud providers like Amazon Web Services have introduced FIPS-validated endpoints. AWS offers these endpoints across regions like US East/West, GovCloud (US), and Canada, using the AWS LibCrypto (AWS-LC) FIPS Module, certified under Certificate #4631 [10]. However, customers need to manually configure their applications to use these endpoints - examples include ec2-fips.us-east-1.amazonaws.com and s3-fips.us-east-1.amazonaws.com - to maintain compliance [10].

The shift to FIPS 140-3 represents a major change, with ongoing validation requirements. Unlike the static validation of FIPS 140-2, any significant updates or configuration changes under FIPS 140-3 can invalidate compliance. As Chainguard explains:

FIPS 140-3 doesn't patch or extend 140-2; significant parts of the standard have been rewritten [3].

Consequences of Non-Compliance

Failing to meet these standards can lead to serious operational and contractual risks. On 21st September 2026, all FIPS 140-2 certificates will be moved to the Historical List and archived, meaning organisations relying on these modules may fail audits for new federal or regulated contracts [6]. Arva Pranaya Simha Reddy warns:

In 2026, FIPS 140-2 modules begin moving to 'Historical.' Meaning: Not recognised, not certifiable, not compliant [6].

The stakes are high. A FinTech company reportedly lost a £7.8 million (around $10 million) contract because it lacked FIPS 140-2 validated modules, and the client required FIPS 140-3 compliance for new agreements [6]. The U.S. Department of Defense has also been clear in its requirements:

Your cryptographic modules are not FIPS 140-2 validated. We require FIPS 140-3 compliance for all new contracts [6].

Non-validated cryptographic modules can result in regulatory fines, lost contracts, and operational disruptions. Enabling FIPS mode in improperly set-up environments might cause systems to crash or fail when encountering non-approved algorithms. Even one non-validated component can jeopardise the compliance of an entire cloud application [4][6]. This creates what experts describe as a SolarWinds-style risk for cryptography, where systems appear compliant but are fundamentally flawed beneath the surface [6]. Such lapses can undermine the entire security framework of a cloud environment.

Implementation Challenges and Solutions

Common Implementation Obstacles

Adopting FIPS 140-3 in cloud environments can be a tricky process, requiring every layer of the technology stack to align perfectly. This includes everything from the operating system kernel and OpenSSL libraries to the JVM and individual application configurations. A single misconfiguration can lead to complete system failures, leaving you scrambling to identify the issue [4].

The standard introduces stricter algorithm restrictions compared to FIPS 140-2. Algorithms that were previously acceptable for JWT signing or TLS configurations may now be rejected outright [4]. These rejections often result in vague error logs and system startup failures, making troubleshooting a frustrating experience [4]. To achieve compliance, cryptographic boundaries must be controlled from the very beginning of the Infrastructure as Code (IaC) process - such as in Terraform scripts - right through to the deployed runtime environment [9]. This can be particularly challenging when developers unintentionally bypass FIPS requirements by using non-compliant Docker images or libraries. Such practices may create an illusion of compliance but ultimately lead to deeper configuration issues and audit failures [6].

Practical Approaches for Adoption

To navigate these challenges, there are practical steps you can take to ensure compliance. Begin by using FIPS-validated OS images that come pre-configured with approved cryptographic libraries like OpenSSL operating in FIPS mode [9]. Major cloud providers offer these images, which can significantly reduce the manual configuration workload. For example, in AWS environments, you can configure your Terraform provider to use FIPS endpoints by setting use_fips_endpoint = true. This ensures that all API calls are routed through validated URLs [9].

For Java applications, consider specialised cryptographic providers such as Bouncy Castle FIPS or SunPKCS11 paired with a Hardware Security Module (HSM) [4]. Additionally, locking infrastructure provider versions helps maintain immutable builds that support FIPS-compliant authentication flows [9]. As Andrios Robert explains:

Meeting FIPS 140-3 in Terraform is not just about flipping a switch. It is about enforcing cryptographic discipline across infrastructure, deployment pipelines, and runtime environments [9].

For organisations dealing with complex cloud migrations or undergoing DevOps transformations, seeking expert guidance can make a significant difference. Hokstad Consulting, for instance, specialises in cloud infrastructure optimisation and custom automation. Their expertise can help businesses establish strong security frameworks while simplifying operational processes. Their disciplined approach aligns with the stringent, repeatable processes required to implement FIPS 140-3 across your entire infrastructure stack.

Conclusion

FIPS 140-3 raises the bar for cloud security with stricter requirements for cryptographic methods and key management. For organisations in regulated industries like finance, healthcare, or government, meeting these standards isn't optional - it directly impacts contract opportunities and audit results [6].

The shift to FIPS 140-3 brings tangible security improvements. For instance, in June 2025, Microsoft updated the firmware for Azure Managed HSM and Azure Key Vault Premium to achieve FIPS 140-3 Level 3 validation across all public cloud regions. This move highlights the industry's dedication to adopting modern cryptographic standards [2]. Achieving this validation ensures data protection using government-approved algorithms and configurations, removing vulnerabilities such as weak ciphers [4].

However, compliance isn't just about ticking boxes - it requires a thorough implementation strategy. As Andrios Robert explains:

Meeting FIPS 140-3... is about enforcing cryptographic discipline across infrastructure, deployment pipelines, and runtime environments [9].

This means using FIPS-validated operating system images, configuring cloud services to utilise FIPS endpoints, and ensuring that cryptographic libraries operate in compliance mode. Such an approach ensures organisations maintain compliance even as cloud environments evolve.

Operational certainty is crucial. Every encryption process must adhere to rigorous security standards, reducing audit challenges and strengthening defences against advanced threats [4]. With older validations being phased out, the time to transition is limited.

For organisations seeking expert assistance, specialists like Hokstad Consulting (https://hokstadconsulting.com) can provide tailored support to ensure a smooth path to FIPS 140-3 compliance.

FAQs