Rise of cloud‑based HSM services and their impact on PCI PIN environments

The emergence of what we now know as Hardware Security Modules (HSMs) was not a design whim, but a response to a specific type of emerging vulnerability in particular contexts. If we go back to 1972, the appearance of Mohamed Atalla’s Atalla Box marked a turning point, shifting trust from software‑based security toward encapsulation within physically impenetrable silos. The approach focused on creating a trusted environment (Root of Trust) where entropy and the lifecycle of encryption keys were isolated from the host operating system with which they interacted.
 
From those early IBM racks in the 1980s—aimed at wholesale banking—to the standardization of FIPS 140‑1 in the 1990s, the evolution has been an arms race against the physical extraction of sensitive and confidential information: key material. We have moved from simple symmetric‑encryption boxes to devices capable of tamper‑response, even self‑destruction upon intrusion, evolving today into what are known as Cloud HSM models, which must maintain the same cryptographic rigor while offering services to clients. In parallel, this aligns with what is commonly referred to as HSM‑as‑a‑Service. All participants in the payment‑card industry must understand that when interacting with or inspecting these components in a data center, we are facing decades of refinement in the science of key management—essentially the backbone that governs all cryptographic branches within any organization concerned with data security, or required to be.

How did we move from the cold room to the cloud? How do we integrate cloud‑based HSM services within a PCI PIN compliance framework? Through simple evolution. In both cases, we start from the same premise that characterizes these components: the inviolability of their cryptographic module—their core. An HSM is not merely a server that encrypts and decrypts; it is the cornerstone upon which cryptographic security in the payments industry rests. Its value lies in its nature as a dedicated execution environment designed to protect and manage sensitive keys, isolated from the production environment containing the systems that interact with it, and shielded from adjacent threats. These characteristics must hold true both in a cold room and in a cloud environment—the only difference is the consumer’s point of view. In both cases, physical components guarantee all principles required of HSMs.

Today, module inviolability is formalized through the implementation of FIPS 140‑2 Level 3 (or higher), ensuring physical and logical isolation of Local Master Keys (LMKs), or equivalent nomenclature depending on the manufacturer, as well as rigorous lifecycle control. These keys sit at the highest level of any mature key hierarchy.


 
Within the PCI PIN standard, the HSM is considered a fundamental tool for protecting encryption keys used to secure the PIN—whether those keys encrypt the PIN directly or are otherwise related in ways that impact its security. The market’s migration toward robust formats such as ANSI X9.143 or TR‑31 Key Blocks (analyzed in other articles) further underscores the need for an impenetrable key‑management foundation. The HSM ensures that these complex data structures—encapsulating both the encrypted key and its usage attributes—are created, managed, and decrypted within a trusted cryptographic boundary.

Other basic operations within such organizations may require the use of these devices: encrypting or decrypting PINs for inter‑zone exchange, receiving keys from different parties to integrate into a business core, generating MACs to protect message integrity, or generating keys in compliance with industry standards so they can be used as working keys in other devices. Cryptographic branches extend end‑to‑end across organizations, often transparently thanks to the maturity of processes employing encryption techniques.

Now then—why would a PCI PIN‑impacted company be interested in using a cloud‑based HSM service provider instead of traditional on‑premise HSMs? Let’s analyze it.



Let’s briefly revisit the concept of a service provider. The notion of a service provider under PCI DSS differs somewhat from that under PCI PIN. Under PCI DSS, a complex ecosystem of providers may offer various services executed on behalf of merchants, enabling them to meet requirements through the provider’s activities. PCI DSS inherently accepts that a provider may perform certain activities on behalf of a merchant and certify its service through a Service Provider AOC (Attestation of Compliance). These providers may process sensitive data or manage antivirus solutions, among many other services, and their activities fit neatly into the AOC structure thanks to a dedicated section describing the certified services.


 
The standard itself explains this approach:

When the TPSP provides a service that meets PCI DSS requirements on behalf of the customer, or when that service may impact the security of the customer’s cardholder data and/or sensitive authentication data, those requirements fall within the scope of the customer’s assessment, and the TPSP’s compliance with those requirements will affect the customer’s PCI DSS compliance. The TPSP must demonstrate compliance with applicable PCI DSS requirements so that those requirements are met for their customers.

However, under PCI PIN, the concept of a service provider is slightly different. The PCI PIN program refers to “PCI PIN service providers” as the organizations to which the standard applies. That is, there is no merchant‑like entity plus additional service providers supporting them, as in PCI DSS. Instead, organizations subject to PCI PIN are themselves considered PIN service providers. While something similar to PCI DSS could exist, it requires additional narrative and explanation of the organization’s activities within the limited fields available in official SSC documentation. If we look for a section defining the services of an entity undergoing PCI PIN assessment, the AOC provides an approximation (there is no separate Merchant and Service Provider AOC).

By default, PCI PIN recognizes two types of organizations: those that process PIN‑based transactions, and agents—specifically registration and certification entities, and organizations supporting a Key Injection Facility (KIF). These agents “support” PIN‑acquiring activities with recognized functions.

So, can we shape a “pseudo‑agent” role for companies offering cloud‑based HSM services? Yes, but we must clearly describe their activity in the “Others” section of the AOC, with sufficient detail (including a breakdown of controls they address on behalf of their clients). This allows a QPA reviewing a PIN‑acquiring organization that relies on this new actor to clearly identify the responsibilities delegated to the provider and mark the relevant controls as “In Place” thanks to the provider’s validated AOC.

Now, assuming we validate the option of using a third party similar to a PCI DSS provider—why would a PCI PIN organization be interested in using cloud‑based HSM services? This depends heavily on the type of organization.


 
For example, a certification and registration entity bases its operations on the full management of a CA (Certification Authority) and an RA (Registration Authority), whose activity can essentially be summarized as the issuance of certificates—the trust anchor in remote key‑distribution (RKL) schemes. The RA acts as the critical validation filter, responsible for verifying the identity and legitimacy of terminals in this context, while the CA is the technical engine that performs the signing operations under a strict dual‑control environment. These entities are responsible for ensuring that the root of trust remains impenetrable, guaranteeing that every certificate issued results from an audited registration process and a hardened technical execution. Realistically, there are not many organizations of this type due to their inherent nature, and the cohesion of their product makes the use of Cloud HSM services more complex. Although technically feasible, organizations that have attempted to certify their Cloud HSM services have tended to focus on supporting acquiring institutions or even KIFs.

The motivation to migrate a CA/RA to a Cloud HSM model—if it exists—would not be limited to cost savings, but rather the pursuit of elasticity: the ability to deploy a robust PKI infrastructure without the physical constraints of on‑premise hardware, while maintaining cryptographic rigor. It would allow operational scalability without physical limits, subject of course to the service availability and parameters offered by the Cloud HSM provider. Although strategically appealing, it would be necessary to validate whether the cloud provider can meet the physical‑bunker controls specifically required in Annex A2 of PCI PIN, which are far more demanding than those for other types of organizations, especially given the risk and impact associated with these entities’ role in acquiring processes or remote key distribution using asymmetric techniques.



The type of organizations where these services truly make sense are those that process PIN‑based transactions. Maintaining an HSM is highly complex on several levels. Not only in terms of cost—since these devices are inherently expensive—but also because their maintenance and the need for highly qualified personnel in key‑management operations are absolutely essential. An HSM can be considered a sort of temple where the principles of dual control and split knowledge are consolidated when handling clear‑text key‑management processes. This means that every time keys are generated, exported, rotated, or whenever key ceremonies take place, the physical presence of both device administrators and key custodians is required to ensure the integrity and confidentiality of the sensitive material being handled.

Therefore, a protected physical space is needed to host these critical components that support an organization’s cryptographic architecture—equivalent to a data center—with surveillance, restricted access, and a substantial budget to acquire and maintain these devices, not to mention highly trained personnel and their periodic availability for key ceremonies. What if all this “dirty work” could be delegated to a third party? Let’s take a “basic” acquiring organization as an example. This organization has an HSM that stores an LMK and a transaction‑processing host that stores operational encryption keys in a database, encrypted under the HSM’s LMK. Every encryption or decryption operation requires a call to the HSM, sending both the cryptogram and the encrypted key. If this company can rely on a third party that owns the HSM, provides key custodians, and can orchestrate key exchanges with other acquirers or third parties on its behalf, its PCI PIN compliance impact would be significantly reduced (not to mention the operational workload involved).

Once this provider is integrated, every time an encryption or decryption operation is needed, the information must be redirected to the cloud instead of the on‑premise installation. The response will be equivalent, with the possible addition of some latency.

Is it worthwhile? Absolutely—at least from a PCI PIN perspective—provided that the organization works with a certified Cloud HSM partner whose services are clearly defined in their compliance AOC, as mentioned earlier, and ideally with a detailed breakdown of the controls they cover in their service portfolio. The other side of the coin is the cost of the service, whether based on transaction volume or on the pricing model used by the HSM‑as‑a‑Service provider. Spoiler: the cost will be significant and may vary depending on the service level designed. For example, one might find an all‑in‑one model including custodians, or a model offering only remote HSM services requiring the organization’s own custodians to attend ceremonies. The variations can be numerous.

 
What about key‑injection facilities? Does it make sense to use a Cloud HSM service in this context? Depending on the specific activity of the KIF itself, it may be more or less relevant. There are KIFs—an increasingly common model—that use key‑loading devices to prepare the fleet of terminals that must be deployed for each client. This means that the key material has been injected into the terminals either by the manufacturer or through components handled by the organization’s custodians, depending on the encryption scheme used, and therefore the presence of an HSM is not required. However, it may also be the case that the KIF itself has an HSM involved in the injection of unique keys, managed through an intermediate loading software. Or that TMKs corresponding to a Master/Session scheme are generated through components, and operators then load those components into each terminal. By analyzing each scenario individually, one could assess the benefit and feasibility of using a cloud‑based HSM provider. In other words, although the scenario with the highest apparent viability for this type of partner is organizations that process PIN‑based transactions, it is still possible that a KIF could make use of such a service, provided a cost‑benefit and return‑on‑investment analysis supports it.

If anything, a particularly interesting case—perhaps even “ideal”—for a KIF to use this type of provider would be a KIF responsible for remotely rotating terminal keys. In this context, which could also be handled by acquirers or processors (as is more common in the real world), it could be viable to have an interface with the Cloud HSM provider so that on one end, key‑rotation requests are handled, and on the other end, the system connects to the N terminals of client M of a KIF that need to rotate their working keys according to a specific scheme. In this scenario—also applicable to acquiring organizations—the entity using the service would save on all the recurring factors we have mentioned throughout this analysis (the device itself, licenses, physical space to host the device, etc.)

Having reviewed the types of organizations that may benefit from these services, we can now move on to catalog a sample of specific controls that could be inherently met when using such a provider—for example, for a basic organization that processes PIN‑based transactions:

▪️1-3 All hardware security modules (HSMs) shall be either FIPS140-2 or FIPS 140-3 Level 3 or higher certified, or PCI approved.
             ✅ Dado que los HSM son propiedad del partner del servicio Cloud HSM, es algo que
             habría sido revisado en su evaluación y cumple en nombre de las organizaciones que
             empleen su servicio. 
▪️6-1.4 Key-generation equipment used for generation of clear-text key components must not show any signs of tampering (for example, unknown cables) and must be inspected prior to the initialization of key-generation activities. Ensure there isn’t any mechanism that might disclose a clear-text key or key component (e.g., a tapping device) between the key-generation device and the device or medium receiving the key or key component.
             ✅ Por el mismo motivo que el ejemplo anterior, los equipos de generación de claves, en
             una organización que procesa transacciones con PIN, si únicamente son aquellos que se
             alojan en el proveedor, dará lugar a que este control será asignado a este último y
             marcado como compliant en su cliente. Otra cosa será cómo se gestionen los
             componentes generados. En función del servicio dispuesto, podría ser necesaria la
             asistencia de custodios cliente al emplazamiento del proveedor, o que se incluya en el
             servicio custodios de la organización que luego interactúen con las interfaces necesarias
             para el intercambio de claves. Alineando esta práctica, eso sí, a que los custodios del
             partner se consideran personal contratado tal y como indica el 25-1.1 (“Assigned key
             custodians are employees or contracted personnel”)
▪️12-5 Hardware security module (HSM) Master File Keys, including those generated internal to the HSM and never exported, must be at least double-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits.
▪️23-2 An MFK used by host processing systems for encipherment of keys for local storage—and variants of the MFK—must not be used external to the (logical) configuration that houses the MFK itself. For example, MFKs and their variants used by host processing systems for encipherment of keys for local storage shall not be used for other purposes, such as key conveyance between platforms that are not part of the same logical configuration.
▪️29-4 Dual-control mechanisms must exist to prevent substitution or tampering of HSMs—both deployed and spare or back-up devices—throughout their life cycle. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted HSMs but must not supplant the implementation of dual-control mechanisms.
               ✅ De nuevo en todos ellos, dado que los HSMs son propiedad
                del partner del servicio Cloud HSM, es algo que habría sido
               revisado en su evaluación y cumple en nombre de las
              organizaciones que empleen su servicio. 

And what will be the real scope and impact of integrating this type of partner into the organization? This is a point that requires a detailed analysis of the organization’s context and of the services contracted with the Cloud HSM provider, in order to identify which controls remain the responsibility of the organization and which are actually covered by the provider. As a recommended strategy, this can be managed with the support of the QPA firm that will conduct the assessment, engaging them in advance of the evaluation.

Another factor to consider regarding this type of provider is that the PCI SSC itself has acknowledged the reality of cloud environments through its Technical FAQs, which are mandatory for PCI PIN and carry the same weight as the standard itself. Let’s look at a specific sample of Cloud‑HSM‑related topics included in the latest version of the available FAQs:

It is worth noting, as we have seen in this section, that Cloud HSM providers would also be considered multi‑tenant HSM providers. In the market, we also find the concept of HSMaaS (HSM as a Service) providers. Ultimately, including the term “cloud” in the service name may simply reflect industry trends or commercial positioning, since it is still an HSM service managed by a third party that physically owns a variable number of HSMs used to perform cryptographic operations for their clients—a service that also has a direct impact on PCI PIN compliance for the organizations that rely on it.

In the end, what should any organization consider when evaluating whether to use Cloud HSM services (or HSMs as a Service) versus not using them?

✔️ Elasticity and scalability: Scale cryptographic capacity without capital expenditure or hardware lead times.

✔️ Reduced operational burden: Hardware management shifts to the provider; key‑management tasks may also be included.

✔️ High availability and resilience: Providers may offer geographically redundant SLAs that would be extremely costly on‑premise. 

✔️ Regulatory compliance: Providers’ certifications can significantly simplify assessments.

❌ Loss of direct physical control: Even if certified, the organization loses immediate visibility and response capability.

❌ Vendor dependency: Migrating LMKs, rotating keys, or exchanging key material across providers can be complex.

❌ Shared responsibility model: Clients must clearly understand where provider obligations end and theirs begin.

❌ Latency or outages: Cloud operations may introduce latency; outages must be covered by SLAs.

Referencias
🔗 https://www.pcisecuritystandards.org/about_us/
🔗 https://www.pcisecuritystandards.org/document_library/
🔗 https://docs-prv.pcisecuritystandards.org/PIN/Reporting%20Template%20or%20Form/PCI_PIN_v3.1_ROC_Reporting_Template_1d.pdf
🔗 https://docs-prv.pcisecuritystandards.org/Programs%20and%20Certification/Qualified%20PIN%20Assessor%20(QPA)/Qualified_PIN_Assessor_(QPA)_Program_Guide_v1.2.pdf
🔗 https://docs-prv.pcisecuritystandards.org/PIN/Frequently%20Asked%20Questions%20(FAQ)/PCI_PIN_Technical_FAQs_v3_August_2025.pdf