Hardware Security Modules in Institutional Crypto Custody: What FIPS Compliance Actually Requires in Practice

Institutions managing digital assets face a concrete question when evaluating custody infrastructure: what does FIPS compliance actually mean in practice, and how does it change the way private keys are protected? The answer matters because FIPS 140-2 and FIPS 140-3 are not marketing labels. They are technical standards published by the U.S. National Institute of Standards and Technology (NIST) that define how cryptographic modules must be built, tested, and validated [csrc.nist.gov]. For any institution handling digital assets at scale, understanding what these standards require, and where they fall short on their own, is foundational to building custody infrastructure that holds up under audit, regulatory review, and real-world operational pressure.

TL;DR

• FIPS 140-2 and 140-3 define four security levels for cryptographic hardware. Higher levels require stricter physical tamper resistance and operational controls [ezurio.com].
• Hardware Security Modules (HSMs) that meet FIPS standards are a core component of institutional crypto custody, but they are not sufficient on their own [scalablesolutions.io].
• The shift from FIPS 140-2 to FIPS 140-3 introduces updated cryptographic algorithm requirements and stronger evidence standards for validation [csrc.nist.gov].
• Institutions need to pair HSM-based key protection with complementary controls such as Multi-Party Computation (MPC) and access governance to close operational gaps [scalablesolutions.io].
• Cregis serves as the Trust Layer for institutional crypto custody, delivering secure, efficient, and compliant infrastructure that integrates FIPS 140-compatible HSMs, MPC, and Trusted Execution Environments for banks, payment providers, and enterprises globally.

About the Author: This article is written by the Cregis team, drawing on nine years of operational experience building and running enterprise-grade crypto custody infrastructure for over 3,500 institutions across 50+ countries, with zero security incidents on record.

What Is a Hardware Security Module and Why Does It Matter for Custody?

A Hardware Security Module is a physical computing device purpose-built to generate, store, and manage cryptographic keys inside a tamper-resistant boundary [chain.link]. The private key never leaves the HSM in usable form. Encryption and decryption operations happen inside the device, so even if surrounding systems are compromised, the key material itself remains protected [ripple.com].

For institutional crypto custody specifically, this matters because a private key is the only credential that authorises an on-chain transaction. Lose it, and assets are gone. Expose it, and assets can be taken. The HSM enforces a hardware-level boundary around that risk [stripe.com].

Key properties that make HSMs relevant to institutional custody:

• Key isolation: Keys are generated and stored inside the module, never exported in plaintext [cobo.com].
• Tamper evidence and response: Validated HSMs are designed to detect physical intrusion and, at higher security levels, destroy key material if tampering is detected [ezurio.com].
• Auditable operations: All cryptographic operations are logged, supporting compliance and forensic review.
• Hardware-enforced access control: Operations require authenticated requests, reducing the risk of insider misuse.

What Do FIPS 140-2 and FIPS 140-3 Actually Require?

FIPS 140-2 and FIPS 140-3 both define four progressive security levels, but they differ in important ways that matter to institutions selecting or auditing custody infrastructure [ezurio.com].

Practically, the shift from FIPS 140-2 to FIPS 140-3 means that institutions procuring new HSMs should confirm which standard their vendor's module is validated under. FIPS 140-2 validated modules remain widely deployed and operationally sound, but new procurement decisions should account for the direction of regulatory expectations [csrc.nist.gov].

The four security levels break down as follows [ezurio.com]:

• Level 1: Basic cryptographic module requirements. Software implementations can qualify.
• Level 2: Adds tamper-evident physical security. Suitable for many commercial use cases.
• Level 3: Requires tamper detection and response. Identity-based authentication for access. Relevant for institutional custody deployments.
• Level 4: Highest physical protection. Designed for physically unprotected environments. Rarely used in practice due to operational complexity.

Most institutional custody deployments target Level 3 as the practical benchmark for key protection under adversarial conditions.

Where Do HSMs Alone Fall Short for Institutional Custody?

Building on the security properties above, the harder question is not whether HSMs work, but whether they are sufficient on their own. They are not, and this gap has operational consequences.

HSMs enforce rigid, hardware-dependent governance models that can restrict multi-party approval workflows in institutional custody [scalablesolutions.io]. A single HSM creates a concentration point. If a single device holds signing authority, operational continuity depends on that device remaining available and uncompromised. That is a single point of failure for availability, even if the key material itself is protected.

Additional gaps to consider:

• Governance rigidity: HSMs do not natively support flexible approval policies across distributed teams or geographies without additional orchestration [scalablesolutions.io].
• Scalability limits: Physical HSMs require hardware procurement cycles that do not match the pace of institutional growth.
• Insider risk: HSMs protect against external key exposure but do not independently prevent authorised operators from abusing legitimate access.
• Disaster recovery complexity: Recovering HSM-protected key material after hardware failure requires careful pre-planning and backup architecture.

This is why institutions building custody at scale pair HSMs with Multi-Party Computation. MPC distributes key shards across multiple parties so that no single device, operator, or system ever holds a complete key [cobo.com]. The two controls address different threat surfaces and are stronger together than either is alone.

How Does a Layered Architecture Address These Gaps?

Stepping back from the technical detail, a separate concern is how institutions actually implement these controls in production without creating operational complexity that undermines the security model.

The answer is a layered architecture that integrates HSM, MPC, and Trusted Execution Environments into a single operational framework. This approach means:

• HSMs protect key material at the hardware level during storage and signing operations [stripe.com].
• MPC distributes key shards so no single compromise event exposes a complete key.
• TEEs provide isolated execution environments for sensitive operations at the software layer.
• Governance policies sit above all three layers, enforcing approval workflows, transaction limits, and access controls.

Cregis serves as the Trust Layer, combining secure key protection through FIPS 140-compatible HSM infrastructure, efficient operations through MPC based on the GG18 protocol and TEE architecture, and compliant governance through multi-signature and access control policies. The framework supports distributed signing configurations, giving institutions the flexibility to design governance workflows that match their operational structure while maintaining the highest levels of key protection. This is what the company means by "first tier of security standard of the industry." It is not a single feature. It is the combination of validated hardware, distributed key management, and auditable governance that regulators and enterprise risk teams can examine and rely on.

Frequently Asked Questions

What is the difference between FIPS 140-2 and FIPS 140-3 in plain terms? FIPS 140-2 is the older standard. FIPS 140-3 is the current standard, aligned with international ISO specifications and updated cryptographic algorithm requirements. New HSM validations are now submitted under FIPS 140-3 [csrc.nist.gov].

Does FIPS certification make an HSM suitable for crypto custody on its own? FIPS validation confirms the cryptographic module meets specific security requirements. It does not address broader custody needs such as governance workflows, disaster recovery, or insider risk controls. Those require additional architecture [scalablesolutions.io].

What security level should institutional custody deployments target? Level 3 is the practical standard for institutional custody. It requires tamper detection and response, plus identity-based authentication for module access [ezurio.com].

Can cloud-based HSMs be FIPS compliant? Yes. Cloud HSM services can hold FIPS 140-2 or 140-3 validation. Institutions should verify the specific validation status of the cloud module they use rather than assuming compliance based on vendor marketing [ripple.com].

How does MPC complement HSM-based custody? HSMs protect key material at the hardware boundary. MPC eliminates the single point of failure by distributing key shards across multiple parties. Neither approach replaces the other [cobo.com].

What certifications should institutions look for beyond FIPS? SOC 2 Type II, ISO 27001, and PCI DSS address broader operational security controls. Together with FIPS-validated hardware, these certifications give a more complete picture of custody infrastructure quality.

Is FIPS compliance required outside the United States? FIPS is a U.S. federal standard, but it is widely adopted as a de facto benchmark globally because it provides a clear, independently validated measure of cryptographic module security [csrc.nist.gov].

About Cregis

Cregis is an enterprise-grade crypto financial infrastructure provider with nine years of operation and zero security incidents. The company serves over 3,500 businesses across 50+ countries, securing more than $300 billion in yearly transactions through a platform that integrates FIPS 140-compatible HSMs, MPC key management, and a zero-trust architecture. Cregis holds SOC 2 Type II, ISO 27001, and PCI DSS certifications, and its infrastructure supports banks, payment service providers, exchanges, and corporate treasury teams that require custody infrastructure they can stand behind in front of regulators and auditors.

If you are evaluating custody infrastructure for your institution and want to understand how FIPS-compatible HSMs fit into a complete security architecture, visit https://www.cregis.com/ to speak with the Cregis team.