Dedicated vs Shared HSMs in PKIaaS: Security and Compliance Trade-Offs

When a PKIaaS provider says their service uses FIPS-validated HSMs, they have told you the minimum. What they have not told you is whether those HSMs are dedicated to your organization, whether your CA keys share a physical appliance with other customers’ keys, what the partition isolation model looks like at the firmware level, and whether a security incident affecting another customer’s partition could have any operational impact on yours.

These are not theoretical distinctions. The HSM architecture beneath a PKIaaS service determines your real key isolation, your blast radius exposure, your ability to meet regulated-industry compliance requirements, and the defensibility of your PKI program in an audit. Yet most PKIaaS marketing pages describe FIPS validation in a single sentence and move on.

This post explains the technical and compliance trade-offs between dedicated and shared HSM models in PKIaaS deployments, covers the controls that matter (partitioning, M-of-N, BYOK, audit log isolation), and gives security architects and compliance teams the framework to evaluate what their specific requirements actually demand.

Quick Answer: What Is the Core Difference?

A dedicated HSM means the physical appliance storing your CA private keys is allocated exclusively to your organization. No other customer’s cryptographic material or operations exist on that hardware. A shared HSM means multiple customers’ keys are stored in separate logical partitions on the same physical appliance. Partition isolation is enforced in firmware, not in separate hardware. Both can meet FIPS 140-2 or 140-3 Level 3 validation. The choice between them determines blast radius, audit log isolation, regulatory compliance posture, and certain categories of supply chain risk.

Key Takeaways

• FIPS 140-2 Level 3 and FIPS 140-3 Level 3 are the relevant validation levels for CA key storage. Both require physical tamper resistance that zeroizes keys if the enclosure is breached. FIPS 140-3 is the current standard as NIST transitions from 140-2; always verify the specific validation status through the NIST CMVP database.
• Shared HSM partitioning is cryptographically sound in well-implemented enterprise HSMs. The isolation boundary is enforced at the HSM firmware level and is the same mechanism used in cloud HSM services from major providers. The risk is not a broken isolation boundary; it is the shared physical blast radius and the compliance evidence requirements for certain regulated frameworks.
• M-of-N controls (quorum authentication) are the critical access control mechanism for root CA operations regardless of whether the HSM is dedicated or shared. They prevent any single provider administrator from performing unauthorized high-privilege operations unilaterally.
• BYOK (Bring Your Own Key) allows customers to generate CA root key material in their own controlled environment and import it into the provider’s HSM, ensuring that the provider never had custody of a key that was not already under the customer’s control.
• Regulated environments such as FedRAMP High, CMMC Level 3, certain DORA and NIS2 implementations, and ITAR/DFARS-subject defense industrial base organizations may have compliance requirements that effectively mandate dedicated HSM hardware rather than partition isolation. Legal and compliance counsel should confirm the specific requirement before accepting a shared model.

HSM Fundamentals for PKIaaS Buyers

A hardware security module is a tamper-resistant cryptographic device that generates, stores, and protects cryptographic keys. In a PKI context, HSMs protect the CA private keys that sign every certificate the PKI issues. If a CA private key is extracted from the HSM by an attacker, the attacker can issue fraudulent certificates under your CA hierarchy indefinitely until the CA is revoked and the hierarchy rebuilt. This is why key storage and key isolation are the highest-priority security properties of any PKI deployment.

FIPS 140-2 and FIPS 140-3 define four security levels for cryptographic modules. Level 3, the relevant level for CA key storage, requires physical tamper-resistance and tamper-evidence mechanisms that zeroize all plaintext CSPs (Critical Security Parameters, which include CA private keys) if the module enclosure is penetrated. Level 3 also requires identity-based authentication, meaning the HSM associates specific credentials with specific roles before permitting operations. Level 4 adds additional environmental failure protection and is rarely encountered in commercial PKI deployments.

FIPS 140-3, published in 2019 and aligned to ISO/IEC 19790:2012, supersedes FIPS 140-2. NIST began accepting 140-3 submissions in September 2020 and stopped accepting 140-2 submissions in September 2021 (though modules validated under 140-2 retain their validation status). Most HSMs currently in production PKIaaS environments carry FIPS 140-2 Level 3 validation; 140-3 Level 3 certifications exist for newer models from major vendors including Thales, Utimaco, and others. Verify any vendor claim by looking up the NIST CMVP certificate number in the public database rather than relying on a marketing statement.

Dedicated HSMs: What They Are and What They Actually Provide

In a dedicated HSM deployment, a specific physical appliance (or set of appliances) is allocated exclusively to one customer. The appliance is racked in the provider’s data center, but no other customer’s keys, partitions, or cryptographic operations exist on that hardware. The customer’s CA private keys are the only keys on the device.

Security Properties of Dedicated HSMs

The primary security benefit of a dedicated HSM is physical blast radius containment. If the appliance is physically compromised (tampered with, subjected to a side-channel attack requiring physical proximity, or subject to a firmware vulnerability that allows one partition’s key material to be read by another partition’s process), the impact is limited to your organization. There is no risk that a security event affecting another customer’s partition bleeds into your key material.

A secondary benefit is auditability. With a dedicated appliance, every operation logged in the HSM’s audit trail is attributable to your CA operations. There is no noise from other customers’ operations in the same log, and there is no ambiguity about whether a logged event was caused by your system or another tenant’s. This simplifies both routine compliance reporting and incident investigation.

A third benefit is operational exclusivity. Firmware updates, HSM maintenance operations, and any provider-initiated administrative actions on the appliance can only affect your infrastructure. A firmware update required for another customer’s use case cannot be applied to your appliance without your involvement.

Cost and Availability Trade-offs of Dedicated HSMs

Dedicated HSMs are more expensive. The provider cannot amortize the hardware cost across multiple customers, so the per-customer cost is higher. Enterprise-grade FIPS 140-3 Level 3 HSM appliances from major vendors cost $20,000 to $60,000 or more per unit, and a production PKI deployment typically requires multiple units (offline root CA, online issuing CAs, high availability standby). When a customer pays for a dedicated HSM in a PKIaaS engagement, they are effectively paying for the exclusive use of hardware that the provider would otherwise share.

High availability with dedicated HSMs requires dedicated standby hardware as well. A single dedicated HSM for an issuing CA with no hot standby is a single point of failure. Well-designed dedicated HSM deployments for PKIaaS include at minimum a primary appliance and a failover appliance, both dedicated to the customer, which further increases the cost.

Shared HSMs and Partitioning: How the Isolation Actually Works

In a shared HSM deployment, a single physical appliance hosts multiple customer environments in separate logical partitions. Each partition has its own independent key store, its own access credentials, and its own audit log. The HSM firmware enforces the partition boundaries: operations performed under the credentials of one partition cannot access the key material of another partition.

How Partition Isolation Is Enforced

Modern enterprise HSMs (products from Thales, Utimaco, and similar vendors) implement partition isolation at the firmware level using a combination of separate key stores per partition and credential-gated access to each partition’s operations. The HSM operating system enforces that authentication tokens for Partition A cannot be used to access or operate on keys in Partition B. This isolation is validated as part of the FIPS 140 certification process for the module.

The partition model is the same architecture used by cloud HSM services from major cloud providers, where thousands of customers’ key material is isolated in partitions within the provider’s HSM fleet. When properly implemented, partition isolation is cryptographically sound at the software and firmware level. The risk profile differs from a dedicated HSM not because the partition boundary can be crossed by normal operations, but because of the following residual risks.

Residual Risks in Shared HSM Deployments

The residual risks in a shared HSM model that do not exist in a dedicated model are specific and worth naming precisely.

The first is physical blast radius. If an attacker achieves physical access to the HSM appliance (defeating data center physical security controls), all partitions on that appliance are at risk simultaneously. A successful physical attack that triggers tamper-response zeroization wipes all customers’ keys on that appliance, not just one. A successful physical attack that somehow bypasses zeroization (an extremely difficult but theoretically relevant attack vector for highly sophisticated threat actors) could expose all partition holders’ key material simultaneously.

The second is firmware vulnerability blast radius. A zero-day vulnerability in the HSM firmware that allows cross-partition key access, if one were discovered and exploited, would affect all partition holders on the appliance simultaneously. No such vulnerability is known in currently validated enterprise HSMs, but the theoretical risk exists and is the reason some high-assurance environments require dedicated hardware.

The third is audit log commingling. In a shared HSM without proper per-partition log isolation, a provider’s operational audit log may contain events from multiple customers’ partitions in a single stream. This does not affect key security but can complicate audit evidence production and incident investigation. Well-designed shared deployments maintain per-partition audit logs that are customer-accessible independently.

The fourth is supply chain and maintenance coupling. A firmware update applied to a shared appliance for one customer’s operational requirement is applied to all partitions on that appliance. This creates a dependency relationship between customers who share an appliance that does not exist with dedicated hardware.

M-of-N Controls: The Critical Mechanism Regardless of HSM Model

Whether an HSM is dedicated or shared, M-of-N control (also called quorum authentication or secret sharing) is the access control mechanism that prevents a single administrator from performing unauthorized high-privilege operations. It is required for root CA key ceremonies and should be required for any operation that could compromise the CA hierarchy: root CA key generation, key export, partition initialization, and certain firmware-level operations.

In an M-of-N configuration, the HSM requires that at least M out of N designated keyholders authenticate before the operation can proceed. A common configuration for root CA ceremonies is 3-of-5: any 3 of 5 designated custodians must present their authentication tokens (typically smart cards or cryptographic tokens) before the HSM permits the operation. A 3-of-5 configuration means:

• No single administrator can perform a root CA ceremony unilaterally, eliminating insider threat risk for the highest-privilege operations.
• The ceremony can proceed as long as at least 3 of the 5 custodians are available, providing operational resilience even if 2 custodians are unavailable.
• The ceremony is documented, witnessed, and logged with the identities of the specific custodians who authenticated, creating an audit trail that satisfies CP/CPS requirements.

When evaluating PKIaaS providers, confirm whether M-of-N controls are applied to all high-privilege HSM operations, who the designated custodians are (provider staff only, or customer-nominated custodians as well), and whether the ceremony evidence package is available to your auditors. A provider that cannot describe their M-of-N configuration or that applies quorum controls only to root CA generation but not to other high-privilege operations is not operating to the standard required for an enterprise-grade PKI.

BYOK: When Key Origin Matters

Bring Your Own Key (BYOK) is a deployment model where the customer generates CA key material in their own hardware or controlled environment and then imports it into the provider’s HSM infrastructure. This gives the customer assurance about key origin: the root CA private key was generated by the customer, under the customer’s control, before it was ever loaded into a system they do not physically operate.

Key origin matters for two reasons. The first is regulatory and contractual. Some regulatory frameworks, particularly those in the defense and financial sectors, require that cryptographic key generation occur in equipment that the regulated entity controls directly. If the PKIaaS provider generates the root CA key pair inside their HSM infrastructure, there is a period (however brief) during which the key exists in hardware the customer does not control and the customer cannot independently verify the generation procedure. BYOK eliminates this window.

The second reason is organizational trust. Some organizations’ security policies require that private keys never be generated in third-party hardware, regardless of that hardware’s technical security properties. This is a policy choice rather than a technical necessity, but it is a legitimate one for high-assurance environments. BYOK satisfies it.

The mechanics of BYOK in an HSM context typically involve: the customer generating the key pair in their own HSM using a documented ceremony; wrapping the key for secure transport (using the provider HSM’s public key or a transport key established in a key wrapping ceremony); transferring the wrapped key to the provider; and the provider’s HSM unwrapping and storing the key in the customer’s partition. The provider HSM’s wrapping key ensures that the key material is protected in transit and can only be unwrapped by the correct destination HSM.

Not all PKIaaS providers support BYOK. For organizations where key origin is a requirement, this is a non-negotiable evaluation criterion. Ask whether BYOK is supported, what the documented procedure is, and whether a key wrapping ceremony can be conducted with your team’s designated custodians present as witnesses.

Audit Log Isolation: What You Should Be Able to See

CA audit logs are one of the primary evidence sources for compliance frameworks including SOC 2, CMMC, FedRAMP, PCI DSS, and ISO/IEC 27001. A CA audit log must capture: every certificate issuance, renewal, and revocation event; every administrative action on the CA configuration and certificate profiles; every HSM operation (key generation, signing operations, key export attempts); and every access event by provider operations staff to your partition or CA environment.

In a shared HSM environment, the questions to ask are: are your partition’s HSM events logged separately from other customers’ partitions; who at the provider has access to your partition’s audit log; can you access your audit log independently through a self-service interface or API export; and what is the log retention period. A provider that commingles multiple customers’ HSM events in a single operations log, or that makes audit log access a support ticket process, is creating compliance friction at exactly the point where you need maximum visibility.

In a dedicated HSM environment, the audit log questions simplify: every event in the HSM’s log is attributable to your CA operations, and there is no ambiguity about event attribution. The questions become simpler: can you access the log directly, how long is it retained, and can it be forwarded to your SIEM in real time.

For both models, confirm whether provider operations staff access to your partition or CA environment is itself logged and auditable. The strongest implementations require that any provider administrative access to a customer’s partition generates an event in the customer-accessible audit log, providing complete visibility over provider actions affecting your CA infrastructure.

The Offline Root CA Requirement and HSM Model Interaction

Regardless of whether the issuing CA HSMs are dedicated or shared, the root CA should be stored on an HSM that is air-gapped (physically disconnected from networks) and brought online only for the specific, documented operations that require root CA signing (issuing or renewing subordinate CA certificates). This is a PKI architecture requirement that exists independently of the shared vs. dedicated question.

In a PKIaaS context, the root CA HSM being air-gapped means the provider maintains a physically isolated HSM in a secure facility, with documented procedures for bringing it online, conducting operations under M-of-N control, and returning it to offline storage. Some providers implement this with a dedicated physical appliance that is never networked; others use a cloud HSM’s offline key feature. The critical questions are whether the root CA is genuinely air-gapped (not just “offline by policy” but actually disconnected), what the documented procedure for root CA operations is, and whether the ceremony evidence package is available to your auditors.

A well-designed PKIaaS service separates the root CA HSM (always offline, accessed only for CA ceremonies) from the issuing CA HSMs (online, serving certificate requests). The shared vs. dedicated question applies primarily to the issuing CA HSMs. The root CA HSM is most defensible as a dedicated offline appliance regardless of the issuing CA model.

Bring Your Own HSM: A Third Architecture Option

Some PKIaaS platforms support a Bring Your Own HSM (BYOH) model, where the customer supplies and maintains the HSM hardware while the provider’s PKI software and management layer operates on top of it. In this model, the customer controls the physical appliance, the HSM credentials, and the partition configuration, while the provider handles CA software, certificate issuance automation, CLM integration, and operational support.

BYOH is not the same as BYOK. BYOH means the customer owns and controls the physical hardware; BYOK means the customer generates the key material but the hardware may still be provider-operated. BYOH satisfies the most demanding key control requirements because the customer retains physical custody of the device storing the keys.

The trade-off with BYOH is operational complexity. The customer now has hardware to procure, maintain, and eventually refresh. HSM firmware updates become the customer’s responsibility. HA failover between customer-owned HSMs requires the customer to provision redundant hardware. BYOH is appropriate for organizations where physical key custody is non-negotiable and where the operational overhead of managing the hardware is acceptable given the compliance or risk posture it satisfies.

Encryption Consulting’s HSM as a Service offering provides FIPS 140-3 certified HSM capacity for organizations that need dedicated, customer-aligned HSM infrastructure without managing the hardware procurement, data center, and maintenance cycle themselves.

Regulated Industry Requirements: What Frameworks Actually Demand

The compliance question most security architects ask is whether their specific regulatory framework requires a dedicated HSM or whether a shared model with FIPS-validated partition isolation is sufficient. The answer is framework-specific, and the nuance matters.

FedRAMP High

FedRAMP High requires FIPS 140-2 Level 3 (or 140-3 Level 3) validated cryptographic modules for key storage. It does not explicitly mandate dedicated physical HSMs vs. partitioned shared HSMs. However, the boundary and isolation controls required under FedRAMP High, combined with the requirement to demonstrate control effectiveness to a Third Party Assessment Organization (3PAO), create a practical preference for dedicated hardware in many FedRAMP High implementations. Multi-tenant infrastructure serving both FedRAMP and non-FedRAMP workloads from the same appliance creates authorization boundary complications that dedicated hardware eliminates. If your PKIaaS deployment must be within a FedRAMP-authorized authorization boundary, confirm with your 3PAO whether the provider’s shared HSM model is within scope and whether partition isolation meets the specific control requirements for SC-28 (Protection of Information at Rest) and IA-7 (Cryptographic Module Authentication).

CMMC Level 2 and Level 3

CMMC Level 2, based on NIST SP 800-171 revision 3, requires protection of Controlled Unclassified Information (CUI) using FIPS-validated cryptographic modules. The relevant controls (3.13.10 for cryptographic key establishment and management, 3.13.11 for employment of FIPS-validated cryptography) reference FIPS 140-2/3 validation without specifying dedicated vs. shared hardware. CMMC Level 3 adds requirements drawn from NIST SP 800-172 for enhanced protection against advanced persistent threats (APTs), which introduces stricter boundary controls. For CUI-handling PKI infrastructure at Level 3, the stronger isolation argument favors dedicated appliances, but the specific control language does not explicitly mandate them. Confirm with a CMMC Third-Party Assessor Organization (C3PAO) for your specific assessment boundary.

DORA and NIS2

The EU’s Digital Operational Resilience Act (DORA), effective January 2025, and the Network and Information Security Directive (NIS2), effective October 2024, both impose requirements on ICT risk management and third-party ICT dependencies for regulated financial entities and critical infrastructure operators respectively. DORA Article 9 requires use of encryption standards appropriate to the risk, which includes key protection in hardware security modules, but does not mandate dedicated vs. shared architecture. NIS2 similarly references appropriate technical security measures without specifying HSM tenancy model. However, some member states’ national implementations of NIS2 include data localization requirements that, combined with the need to demonstrate control over cryptographic key material, create practical requirements for dedicated or BYOH HSM configurations. Review the specific national implementation applicable to your operations.

ITAR and DFARS

Organizations subject to ITAR (International Traffic in Arms Regulations) or DFARS (Defense Federal Acquisition Regulation Supplement) for defense-related contract work face the strictest practical constraints on multi-tenant key storage. ITAR prohibits unauthorized disclosure of defense articles and technical data to foreign nationals. A PKIaaS provider operating a multi-tenant HSM where provider operations staff (who might be foreign nationals) have administrative access to the physical appliance hosting your CA keys creates a potential ITAR exposure that dedicated hardware (with documented access controls restricting physical access to cleared US nationals) can address. Organizations subject to ITAR should have export control counsel review any PKIaaS deployment, shared or dedicated, before implementation.

Evaluation Framework: Matching HSM Model to Your Requirements

The table below summarizes the key factors and their implications for choosing between dedicated and shared HSM models in a PKIaaS deployment.

Factor	Shared HSM with Partitioning	Dedicated HSM
Physical blast radius	Shared with other partition holders on same appliance	Limited to your organization only
Firmware vulnerability blast radius	Shared across all partitions on appliance	Limited to your organization only
Cryptographic key isolation	Firmware-enforced partition boundaries (validated in FIPS certification)	Physical hardware boundary; no other keys present
Audit log isolation	Per-partition logs available in well-designed deployments; verify explicitly	All log events attributable to your CA operations only
Firmware update dependency	Shared; updates applied to appliance affect all partitions	Independent; updates applied only with your involvement
M-of-N control applicability	Required regardless; applies at partition level	Required regardless; applies at appliance level
BYOK support	Possible; depends on provider implementation	Possible; depends on provider implementation
BYOH option	Not applicable (provider owns the hardware)	Possible; customer owns and operates the appliance
Cost in PKIaaS	Lower; hardware cost amortized across customers	Higher; full hardware cost allocated to one customer
High availability	Provider manages HA across fleet; your partition benefits	Requires dedicated standby hardware for same customer
FedRAMP High compliance	Possible with proper boundary controls; confirm with 3PAO	Cleaner authorization boundary; generally preferred
CMMC Level 3	Possible; confirm with C3PAO for specific boundary	Stronger posture for APT-relevant boundaries
ITAR/DFARS-subject organizations	Requires careful analysis; multi-tenant physical access is a risk factor	Preferred with documented physical access controls

Questions to Ask Any PKIaaS Provider About Their HSM Model

When evaluating a PKIaaS provider, these are the specific questions to ask about their HSM architecture rather than accepting a general statement about FIPS compliance.

• Dedicated or shared? Are my CA keys stored in a dedicated physical HSM appliance or in a logical partition within a shared appliance? If shared, how many other customers share the appliance?
• FIPS validation details: What is the NIST CMVP certificate number for the HSM model used? Is the validation FIPS 140-2 or 140-3? What is the specific validation level (Level 3 or Level 4)? Is the current module on the NIST active validation list?
• M-of-N configuration: What is the M-of-N configuration for root CA operations? Who are the designated custodians (provider staff, customer staff, or a mix)? Can customer-nominated custodians be part of the quorum? What operations require M-of-N authentication?
• BYOK support: Is BYOK supported? What is the documented key import procedure? Can a key wrapping ceremony be conducted with customer witnesses present?
• BYOH support: Can I supply my own HSM hardware for the CA key storage layer? What integration requirements apply?
• Audit log isolation: Is my partition’s HSM audit log isolated from other customers’ logs? Who at the provider has access to my partition’s log? Can I access it independently through a dashboard or API? How long are logs retained? Can logs be forwarded to my SIEM?
• Provider administrative access: When provider operations staff access my partition or CA environment for support or maintenance, is that access itself logged in my audit trail?
• Root CA offline status: Is the root CA HSM genuinely air-gapped (physically disconnected), not just logically offline? What is the documented procedure for root CA ceremonies?
• Firmware update process: How are HSM firmware updates managed? Am I notified before updates are applied? Is approval required?

How Encryption Consulting Can Help

Encryption Consulting designs and operates PKI infrastructure across dedicated and shared HSM models, and provides independent advisory engagements to help security architects and compliance teams evaluate HSM architecture against their specific regulatory and risk requirements.

• PKI as a Service: Encryption Consulting’s PKIaaS offering uses FIPS 140-3 Level 3 HSM-backed CA keys in dedicated partitions per customer, with an always-offline root CA, M-of-N key ceremony with full evidence documentation, and customer-controlled key escrow. Contact us at Encryption Consulting to discuss your HSM requirements and how they map to our service architecture.
• HSM as a Service: For organizations that need dedicated FIPS 140-3 certified HSM capacity without managing hardware procurement, data center, and maintenance cycles, Encryption Consulting’s HSM as a Service provides dedicated hardware with full customer control over partition configuration, credentials, and audit log access.
• PKI Assessment Service: For organizations with an existing PKIaaS deployment that need to validate whether their provider’s HSM model meets their compliance requirements, Encryption Consulting’s PKI Assessment Service evaluates the HSM architecture, partition configuration, M-of-N controls, audit log isolation, and compliance posture against the specific frameworks applicable to your organization.
• PKI Services: For organizations building or modernizing a self-managed PKI and needing expert guidance on HSM selection, root CA ceremony design, CP/CPS development, and ongoing operational governance, Encryption Consulting’s PKI Services cover the full engagement from initial architecture through go-live.
• PQC Readiness: The post-quantum transition affects HSM infrastructure directly: HSMs must support the NIST-finalized algorithms (ML-KEM from FIPS 203, ML-DSA from FIPS 204, SLH-DSA from FIPS 205, all finalized August 2024) either through firmware updates or hardware replacement. Encryption Consulting’s PQC Readiness service assesses your current HSM infrastructure’s quantum exposure and produces a migration roadmap aligned to the NIST IR 8547 timeline.

Conclusion

The choice between dedicated and shared HSMs in a PKIaaS deployment is not a binary question of secure vs. insecure. Both models can be implemented securely. The practical differences are in physical blast radius, audit log isolation, regulatory compliance posture, and cost. For most enterprise PKIaaS deployments outside of the most demanding regulated environments, FIPS 140-2 or 140-3 Level 3 validated shared HSMs with proper partition isolation, per-customer audit logs, M-of-N controls on high-privilege operations, and customer-accessible key escrow provide a sound security posture.

The cases that genuinely require dedicated hardware are specific: FedRAMP High authorization boundaries where multi-tenant physical infrastructure complicates the ATO boundary, CMMC Level 3 deployments protecting CUI in high-threat environments, ITAR/DFARS-subject organizations where multi-tenant administrative access creates regulatory exposure, and organizations whose security policy requires physical key custody regardless of cryptographic isolation strength.

The questions that always apply, regardless of model: what is the NIST CMVP certificate number for the HSM, what is the M-of-N configuration for root CA operations, how is the root CA offline status maintained and verified, what is the audit log isolation model, and what does the BYOK or key escrow procedure look like. Any provider who cannot answer these questions specifically and in writing is not operating the level of HSM governance that enterprise CA key storage requires.

If you are evaluating PKIaaS providers and need help mapping their HSM architecture against your specific compliance requirements, reach out to Encryption Consulting. We have assessed HSM implementations across FedRAMP, CMMC, DORA, PCI DSS, and HIPAA environments and can help you get to a documented, defensible answer faster than working through it from scratch.

This post is reviewed on a six-month cadence and immediately when NIST updates FIPS 140-3 transition guidance, the CMVP updates validation status for relevant HSM models, or new regulatory guidance from FedRAMP, CMMC, DORA, or NIS2 addresses HSM tenancy requirements directly.

Frequently Asked Questions

What is the difference between a dedicated HSM and a shared HSM in PKIaaS?

In a dedicated HSM deployment, the physical HSM appliance is allocated exclusively to one customer. No other customer’s keys or cryptographic operations are processed on that hardware. In a shared HSM deployment, multiple customers’ key material is stored within separate logical partitions on the same physical appliance. The cryptographic boundaries between partitions are enforced by the HSM firmware, but the hardware itself is shared. Dedicated HSMs eliminate hardware-level blast radius entirely; shared HSMs rely on the correctness of partition enforcement at the firmware level.

What FIPS validation level should a PKIaaS HSM meet?

FIPS 140-2 Level 3 is the minimum acceptable standard for CA key storage in a PKIaaS environment. It requires physical tamper resistance that zeroizes keys if the enclosure is opened. FIPS 140-3 Level 3 is the current standard, published in 2019 and aligned with ISO/IEC 19790:2012. NIST began accepting FIPS 140-3 submissions in September 2020. Most enterprise HSMs currently in production carry FIPS 140-2 Level 3 validation; 140-3 certifications are available for newer models. Always verify validation status through the NIST CMVP database rather than trusting marketing claims.

What is HSM partitioning in a PKIaaS context?

HSM partitioning creates isolated logical boundaries within a single physical HSM appliance. Each partition has its own key store, access credentials, and audit log. Keys in one partition are not accessible to processes operating under a different partition’s credentials, and the HSM enforces this boundary in firmware. In a shared PKIaaS deployment, each customer typically receives one or more dedicated partitions on a shared appliance. The isolation is cryptographically enforced at the hardware level, but the blast radius from a physical compromise of the appliance is shared across all partition holders.

What is M-of-N control for HSMs?

M-of-N control (also called secret sharing or quorum authentication) requires that at least M out of N designated keyholders must be present and authenticate before certain high-privilege HSM operations can proceed. For example, a 3-of-5 configuration requires any 3 of 5 designated custodians to provide their authentication tokens before the HSM will permit a root CA key ceremony, key export, or partition initialization. M-of-N controls are a standard requirement for root CA operations and are documented in CP/CPS governance frameworks. They prevent any single administrator from performing unauthorized high-privilege operations unilaterally.

What is BYOK (Bring Your Own Key) in a PKIaaS HSM context?

Bring Your Own Key (BYOK) allows the customer to generate their CA root key material in their own hardware or controlled environment and then import it into the provider’s HSM infrastructure. This gives the customer assurance that the root key was never generated inside a system they do not control. In PKIaaS, BYOK is typically combined with customer-controlled key escrow so the customer retains an independent copy of the root key outside the provider’s infrastructure. Not all PKIaaS providers support BYOK; for organizations with strict key origin requirements, this is a non-negotiable evaluation criterion.

Which regulated industries require dedicated HSMs for PKIaaS?

No single global regulation universally mandates dedicated (non-partitioned) HSMs for PKIaaS, but several frameworks create strong practical requirements for physical key isolation. FedRAMP High requires FIPS 140-2 Level 3 HSMs and imposes strict boundary controls that in practice favor dedicated appliances. CMMC Level 3 requirements for CUI protection create similar pressure. Some EU member state implementations of NIS2 and DORA include data residency and physical control requirements that effectively require dedicated infrastructure. Defense industrial base requirements under DFARS and ITAR may prohibit multi-tenant key storage environments entirely. Organizations subject to these frameworks should have legal counsel confirm whether logical partition isolation is sufficient or whether physical dedication is required.

Can audit logs from a shared HSM be isolated per customer?

Most enterprise-grade HSMs support per-partition audit logs that record cryptographic operations, access events, and administrative actions for that partition independently. In a well-designed shared PKIaaS deployment, each customer’s partition audit log should be accessible only to that customer and their designated auditors, not to other partition holders or to general provider operations staff. Ask any PKIaaS provider specifically whether your partition’s audit log is accessible to their operations staff beyond what is required for support, how long audit logs are retained, and whether logs can be exported to your SIEM in real time.

Does Encryption Consulting’s PKIaaS use dedicated or shared HSMs?

Encryption Consulting’s PKIaaS uses dedicated HSM partitions per customer engagement, with FIPS 140-3 Level 3 HSM-backed CA keys, always-offline root CA with a documented M-of-N key ceremony, and customer-controlled key escrow. Customers retain access to their partition’s audit logs. For organizations with requirements that exceed standard partition isolation, Encryption Consulting can discuss dedicated appliance configurations as part of the engagement scoping. Contact us to discuss your specific HSM and compliance requirements.