AWS History and Timeline regarding AWS CloudHSM - Overview, Functions, Features, Summary of Updates, and Introduction

First Published: 2026-09-27
Last Updated: 2026-09-27

Design documents and audit materials for AWS CloudHSM contain several names that are no longer in active use: CloudHSM Classic, hsm1.medium, and Client SDK 3. These names all refer to specific periods in the history of AWS CloudHSM, but understanding precisely what each one represents and the timeframe it covers is difficult from a single document.

AWS CloudHSM was initially launched on March 26, 2013, as a service that provided dedicated HSM appliances within a customer's VPC. On August 14, 2017, it was redesigned as a cluster-based service where AWS assumed responsibility for hardware provisioning, software patching, high availability, and backups. The original configuration was then designated as CloudHSM Classic. The Classic HSM service was announced to end on April 1, 2020. In 2024, the FIPS 140-3 Level 3 hsm2m.medium HSM type was added. The previous hsm1.medium went through a stop to new cluster creation and automatic migration, and headed toward end of support.

This article presents a timeline of events spanning these 13 and a half years, using the names that were in use at the time. The central question it aims to answer is: how has the scope of AWS's responsibility for HSM operations evolved over time, and what responsibilities have remained with the customer?

Based on the available primary documentation, the answer is as follows: AWS has always held credentials related to the HSM, regardless of the era. In 2013, AWS used these credentials to manage the appliances. In the cluster era, according to the FAQ from 2018 onwards, AWS holds a limited credential for the HSM's health and availability, encrypted backups, and audit logs. AWS's operational responsibilities expanded after 2017 to include firmware management and backups. While key durability was solely the customer's responsibility during the Classic era, the current FAQ limits the customer's sole responsibility to the 24-hour period between backups. Conversely, both the 2016 FAQ and the current FAQ state that AWS has no access to customer keys or credentials, as the same answer to a question of the same intent.

This article focuses solely on dates, order, and names, as well as the operational boundary between AWS and its customers. The following articles cover related topics as their main subject: the history and timeline regarding AWS Key Management Service (referenced as AWS History and Timeline regarding AWS Key Management Service), the definitions of terms related to CloudHSM and FIPS 140-2/FIPS 140-3 (referenced as Cryptography Glossary for Engineers), and an overview of post-quantum cryptography on AWS (referenced as Post-Quantum Cryptography Standardization Timeline and Migration on AWS).

Background and Method of Creating AWS CloudHSM Historical Timeline

This section first outlines the sources used for each entry in the timeline, explaining how names and dates were determined, and how the operational boundary was tabulated. All sources were accessed on September 26, 2026. For entries that utilized versions archived on the Internet Archive, the date the version was archived is noted.

Three Names That Remain in Design Documents

Reviewing the CloudHSM documentation, you encounter three names:

CloudHSM Classic — Refers to CloudHSM, which began in 2013 and took the form of a dedicated appliance. This designation has been used since August 14, 2017, when the new CloudHSM was announced. The Classic HSM was announced to end on April 1, 2020.
hsm1.medium — A type of HSM used in clusters from 2017 onwards. In 2024, hsm2m.medium arrived, and announcements followed regarding the stop to creating new hsm1.medium clusters, along with automatic migration and end-of-support notifications. The end-of-support dates are listed differently in various documents.
Client SDK 3 — Represents a generation of client software used to connect to the HSM. The first version of Client SDK 5 came out on March 12, 2021. The current User Guide states that versions 3.4.4 and earlier have reached their end of support.

Each of these names, on their own, doesn't immediately reveal when they were used or their current status. Furthermore, the scope of operations managed by AWS varies across the different eras associated with these three names. The purpose of this article is to provide a timeline that clearly illustrates these operational boundaries.

The Primary Sources This Article Used, and What It Made into Entries

This article utilized the following primary sources to create the timeline:

What's New: As of September 26, 2026, there were 17 announcements tagged with aws-cloudhsm. The oldest announcement dates back to August 14, 2017, and the most recent to August 20, 2024. Announcements from 2013 to 2016 did not have this tag, so this article found them through a full-text search of What's New. No announcements regarding CloudHSM newer than August 20, 2024, were found in What's New.

AWS News Blog and AWS Security Blog: These include articles from the News Blog dated March 26, 2013, November 5, 2013, and August 14, 2017, as well as articles from the Security Blog dated September 25, 2019, and May 9, 2025.

User Guide: This includes pages related to Document history, Deprecation Notifications, Client SDK end-of-life, HSM types and cluster modes, and migration from hsm1.medium. ⚠ The Document history begins with the August 14, 2017, entry, This release introduces AWS CloudHSM. Out of the 38 entries from March 2021 onwards, 35 relate to new releases of the Client SDK. The end of hsm1.medium and ML-DSA are not mentioned in the Document history but are only described on individual pages in the User Guide.

FAQ: The FAQ section does not include dates. Current FAQs are quoted with their verification dates. FAQs from the Classic era, and those for CloudHSM Classic that are no longer accessible, were consulted using archived versions from the Internet Archive.

The timeline entries focus on names, the operational boundary, HSM types, FIPS levels, Client SDK generations, and events related to end-of-life. The addition of new regions has not been included, except in the launch entry. Changes in pricing have also been excluded. These criteria produced 27 entries. In other words, please note that the items on this timeline are not all updates to AWS CloudHSM features, but are representative updates that I have picked out.

Names Are Taken from the Sources of That Day

In their versions at the time, the announcements from 2013 to 2016 that this article read call this service simply AWS CloudHSM. The FAQ archived by the Internet Archive on 2017-07-17 does not mention the term Classic at all.

The term CloudHSM Classic appears in an AWS News Blog post dated 2017-08-14. The article describes the new CloudHSM as a major update based on lessons learned from the first-generation product, and refers to the original version as follows. The same text appears in the version archived by the Internet Archive on the same day.

CloudHSM Classic (the original model) supports the generation and use of keys that comply with FIPS 140-2 Level 2.

⚠ AWS has retroactively applied this name to announcements prior to 2017. For example, the What's New announcement from 2015-01-08, Amazon RDS integrates Oracle Transparent Data Encryption with AWS CloudHSM is now written as follows.

Using AWS CloudHSM Classic, you can now maintain sole and exclusive control of the encryption keys

However, in the versions archived by the Internet Archive on 2015-01-13 and 2016-10-13, the same text reads as follows.

Using AWS CloudHSM, you can now maintain sole and exclusive control of the encryption keys

By 2021-04-15, the archived version already uses the name AWS CloudHSM Classic. The archived versions do not narrow down the date of the rewrite. Another announcement released on the same date, 2015-01-08, still uses the name AWS CloudHSM.

Therefore, this article refers to the names used in announcements from 2013 to 2016 as AWS CloudHSM and includes the later-applied names at the end of each entry. Even in the AWS CLI reference documents, the descriptions for the aws cloudhsm commands begin with This is documentation for AWS CloudHSM Classic while the commands for managing the current clusters are aws cloudhsmv2.

Conflicting Dates for the Same Events

This article does not consolidate events with differing dates as documented in various sources. It also does not attempt to determine which dates are correct. Instead, it records the date that each source gives, and for the events central to this article, it gives each source its own entry. Where the AWS Primary Sources Disagree About Launch Dates discusses the types of date discrepancies and the approach to selecting which date to record.

In this timeline, the following three events are split into separate entries:

End of Triple DES and other operations in FIPS mode — The User Guide's Deprecation Notifications give 2024-01-01 in the versions archived by the Internet Archive on 2023-08-09 and 2025-04-14 and in the version on the verification date, and 2025-01-01 in the version archived on 2023-12-20. This article was unable to find any announcement of a change to this date.
Addition of hsm2m.medium — The User Guide's Document history lists an entry indicating the addition of the new HSM type hsm2m.medium and the new cluster mode non-FIPS on 2024-06-10, and another entry indicating the ability to create hsm2m.medium in FIPS mode clusters on 2024-08-20. The What's New announcement and the Security Blog article from 2025-05-09 both state that 2024-08-20 was the announcement date.
End of support for hsm1.medium — In the User Guide's Deprecation Notifications, the version archived by the Internet Archive on 2025-04-14 lists the end of support date as 2025-12-01, while the version archived on 2026-04-16 and the version on the verification date list it as 2026-03-31. The timing for the start of automatic migration also changes, from April 2025 to January 2026. The Security Blog article from 2025-05-09 lists the same dates as the earlier version: 2025-12-01 and April 2025. This article was unable to find any announcements that indicated a change to the end-of-support date. Therefore, it only notes that the page's date has changed, without stating that the date was extended.

The automatic deletion of old backups (Document history: November 18, 2020; What's New: November 25, 2020) is not split into separate entries: the What's New date is used for the entry, and the Document history date is given within it.

How to Read the Operational Boundary Table

This article presents a table alongside a timeline, outlining the operational responsibilities assumed by AWS and those remaining with the customer, organized by period. The table can be found in the "Current Overview" section. The columns are as follows:

Era — Period. This column lists the name of the period, along with its start and end dates.
What AWS operates — This column includes only what AWS itself says AWS does, manages, or holds. This also includes the credentials that AWS holds for HSMs.
What you control — This column includes only what AWS itself says the customer holds, does, or is responsible for.
Where AWS says so — This indicates the document where the information is found. For Internet Archive versions, it specifies the date the version was archived.

For cells where the primary source material provides no information, the text "The source does not say." is used. Before adding this text, it is essential to thoroughly search the full text of the referenced material using the five search terms operate, manage, control, access, and responsib, to ensure that there is no statement contradicting the claim. Information is not filled in based on inferences from other rows or other periods. In the table presented in this article, every cell contains a reference to a statement from a primary source. Using the same four columns, tables of the operational boundary are also available in AWS History and Timeline regarding AWS Directory Service and AWS History and Timeline regarding Amazon Verified Permissions and Cedar.

Topics Covered in Other Articles

This article omits the following topics:

The history of AWS KMS custom key stores and External Key Stores: The custom key store mentioned on 2018-11-26 has only one entry, and AWS History and Timeline regarding AWS Key Management Service details the broader history. This article does not discuss the design considerations regarding where to store the key material.
Definitions of terms related to CloudHSM and FIPS 140: This information is available in Cryptography Glossary for Engineers.
The overall picture of post-quantum cryptography standardization and AWS's response: Post-Quantum Cryptography Standardization Timeline and Migration on AWS covers this. For CloudHSM's ML-DSA, this article holds only what the sources said on the verification date.
Terminology related to service lifecycle stages: AWS Service Lifecycle States addresses terms such as "Maintenance," "Sunset," and "Full Shutdown." Since hsm1.medium refers to an HSM type rather than a service, this article uses the term "end of support" as used by AWS.
Launch dates for all AWS services: This information is available in AWS History and Timeline. The date for CloudHSM in that article, like this one, is 2013-03-26.

This article does not cover topics such as the usage of PKCS #11, JCE, KSP; procedures for migrating keys to a different HSM; or pricing.

AWS CloudHSM Historical Timeline (Updates from March 26, 2013)

The tables for the following four eras present the historical timeline. Each table has the following columns. All references were accessed on September 26, 2026.

Date — For announcements listed under What's New, the date refers to the Posted on date. For events without a specific announcement, the date refers to the date of the relevant documentation. If documentation only specifies a month, the month is listed.
Name on That Date — This column lists the name used in the documentation for that date. The original terminology is reproduced as it appears in the documentation.
What Happened — This describes the event that occurred. If a name was subsequently changed, the current name is noted at the end.
Source — This indicates the documentation used as the basis for the entry. For Internet Archive versions, the date the content was archived is listed.

Index:

2013–2016 – Period when it was offered as a dedicated appliance.
2017–2019 – Period when it was rebuilt as a cluster, and the original form began to be called "Classic."
2020–2023 – Period when "Classic" was discontinued and the Client SDK 5 was introduced.
2024–2026 – Period when hsm2m.medium was added and hsm1.medium was being phased out.

* You can sort the table by clicking on the column name.

2013–2016 — Dedicated Appliances

During the period from 2013 to 2016, AWS CloudHSM provided a service that allocated dedicated HSM appliances – specifically, the SafeNet Luna SA – each used by a single customer. All three entries taken from this period concern the operational boundary. AWS managed the appliances, while customers held partitions and keys within those appliances.

Date	Name on That Date	What Happened	Source
2013-03-26	`AWS CloudHSM`	Launched. The announcement described the service as providing access to dedicated HSM appliances within AWS, emphasizing that `customers maintain full ownership, control and access to keys and sensitive data while Amazon manages the HSM appliances`. According to a News Blog article, the appliances are SafeNet Luna SA devices, and they have IP addresses within the customer's VPC. The same article details credential management, stating, `In Luna SA terminology, we have Admin credentials and you have both HSM Admin and HSM Partition Owner credentials.` The initial regions for launch were US East (Northern Virginia) and EU West (Ireland). Current Name: CloudHSM Classic (as of 2017-08-14).	Announcing AWS CloudHSM / AWS News Blog
2013-11-05	`AWS CloudHSM`	A CloudFormation template for getting started was released. According to a News Blog article, the resources created by the template include IAM credentials to notify the CloudHSM team of the stack configuration. The article continues, `The team will use this information to connect your CloudHSM to the proper VPC subnet and IAM role.` ⇒ During this period, AWS teams were involved in connecting the HSM to the customer's VPC. Current Name: CloudHSM Classic.	AWS CloudHSM Now Available in US West (Oregon) and Asia Pacific (Sydney), and Simple Deployment / AWS News Blog
2015-01-08	`AWS CloudHSM`	New APIs, SDKs, and CLI tools were added to manage HSMs. The announcement stated, `You can also now provision and manage CloudHSM deployments with our new API, SDK, and CLI Tools, which let you launch, terminate, and describe CloudHSM instances from within programs or by executing commands.` Regarding high availability configurations, the announcement explained that in the event of hardware failure, `you can launch a new CloudHSM instance and replicate the keys to the new HSM with a few commands`, indicating that key replication is performed by the customer. On the same day, integration with Amazon RDS for Oracle's Transparent Data Encryption (TDE) was also announced. ⚠ The announcement regarding RDS integration currently refers to `AWS CloudHSM Classic` but the version archived by Internet Archive on 2015-01-13 refers to `AWS CloudHSM`. Current Name: CloudHSM Classic.	AWS CloudHSM and Amazon RDS for Oracle Integration; New API, SDK, and CLI Tools / Amazon RDS integrates Oracle Transparent Data Encryption with AWS CloudHSM / Internet Archive, 2015-01-13

2017–2019 — Rebuilt as Clusters, and the Name CloudHSM Classic

On August 14, 2017, CloudHSM was rebuilt in a cluster configuration. AWS announced that it would be responsible for hardware provisioning, patching, high availability, and backups. The original version was then designated as CloudHSM Classic. In 2019, AWS announced the end-of-life for the Classic HSM.

Date	Name on That Date	What Happened	Source
2017-08-14	`AWS CloudHSM` (the original form: `CloudHSM Classic`)	The new AWS CloudHSM was announced. The announcement stated that `CloudHSM is a fully-managed service that automates time-consuming administrative tasks for you, such as hardware provisioning, software patching, high-availability, and backups.` It also noted that the HSMs are FIPS 140-2 Level 3 validated. A News Blog article explained scheduled backups as `Scheduled backups extract an encrypted image of your HSM from the hardware (using keys that only the HSM hardware itself knows) that can be restored only to identical HSM hardware owned by AWS.` and referred to the original form as `CloudHSM Classic (the original model)`. The User Guide's Document history begins with the entry `This release introduces AWS CloudHSM`	Announcing the new AWS CloudHSM / AWS News Blog / Document history
2018-07-30	`AWS CloudHSM`	It became possible to copy backups to a different region. The announcement stated, `AWS CloudHSM now allows you to copy backups of your CloudHSM Cluster from one region to another for disaster recovery purposes.` AWS handles the backup process, while customers initiate the copy to a different region.	AWS CloudHSM Backups Can Now Be Copied Across Regions
2018-08-13	`AWS CloudHSM`	HSM audit logs began being delivered to Amazon CloudWatch. The announcement stated, `These audit logs are generated on each of your HSM instances, and then delivered by CloudHSM to Amazon CloudWatch on your behalf.` It also clarified, `Please note this feature is for the new CloudHSM only, and does not apply to CloudHSM Classic.`	AWS CloudHSM Audit Logs are Now Available in Amazon CloudWatch

Date	Name on That Date	What Happened	Source
2018-09-10	`AWS CloudHSM`	It is now possible to delete backups when needed. Backups marked for deletion are held for seven days and can be restored during that time. The announcement states the customer's responsibility as `If customers want to irrevocably delete a key or remove a user's access to the cluster for security or compliance reasons, they must also delete any backups that contain those keys or users.`	AWS CloudHSM Now Supports On-Demand Delete Backup
2018-11-26	`AWS Key Management Service (KMS) Custom Key Store`	AWS KMS Custom Key Stores were launched, built on top of AWS CloudHSM clusters. The announcement states, `Each custom key store is backed by an AWS CloudHSM cluster`. The history, and the External Key Store of 2022, are covered in AWS History and Timeline regarding AWS Key Management Service.	Announcing AWS Key Management Service (KMS) Custom Key Store
2019-07-01	`CloudHSM Classic`	This date was announced as the point at which new capacity would no longer be available for Classic. The CloudHSM Classic FAQ, archived by the Internet Archive on 2019-08-20, states the reason as `Gemalto has announced end of life for Luna 5 HSMs.` It specifies the cutoff date as `1-July 2019: You will be unable to provision new CloudHSM Classic capacity after this date.` An earlier FAQ, archived by the Internet Archive on 2018-07-19, still stated that `we will maintain AWS CloudHSM Classic for existing customers`.	CloudHSM Classic FAQ (Internet Archive, 2019-08-20) / FAQ (Internet Archive, 2018-07-19)
2019-09-25	`CloudHSM Classic` / `New CloudHSM`	A method for migrating keys from Classic to the new CloudHSM was described in the Security Blog. The article states, `The Luna 5 HSMs used for CloudHSM Classic are reaching end of life, and the CloudHSM Classic service is being subsequently decommissioned`. It uses the terms `New CloudHSM` and `CloudHSM Classic` to differentiate between the two. ⚠ A note has been added to the beginning of the article, dated 2025-02-17, indicating that Client SDK 3, mentioned in the article, is no longer a recommended version.	AWS Security Blog
2019-10-22	`AWS CloudHSM client version 3.0.0`	The first version of Client SDK 3 was released. The Document history states, `Released AWS CloudHSM client version 3.0.0 for all platforms, except Windows.`	Document history

2020–2023 — The End of Classic, and Client SDK 5

The Classic HSMs had been announced to end on April 1, 2020. In the same year, AWS added a feature that automatically deletes expired backups. Previously, it had been the customer's responsibility to delete older backups. In 2021, Client SDK 5 was launched, and the final version of Client SDK 3 was released on January 3, 2022.

Date	Name on That Date	What Happened	Source
2020-04-01	`CloudHSM Classic`	This date was announced as the day when all running CloudHSM Classic HSM instances would be terminated. The CloudHSM Classic FAQ, archived by the Internet Archive on August 20, 2019, stated, `1-April 2020: All running CloudHSM Classic HSMs instances will be terminated on this date.` A later FAQ, archived by the Internet Archive on September 30, 2019, stated, `You must upgrade to the new CloudHSM by April 2020.` This question is absent from the version archived on June 6, 2020. No announcement confirming the termination was found. The URL for the CloudHSM Classic FAQ redirects to the current FAQ when accessed.	CloudHSM Classic FAQ (Internet Archive, 2019-08-20) / FAQ (Internet Archive, 2019-09-30)
2020-11-25	`AWS CloudHSM`	Old backups began to be automatically deleted according to the retention period. The announcement stated that previously `Until today, however, customers were responsible for deleting old backups.` and that now `Expired backups are automatically purged for you`. The User Guide's Document history includes this functionality in an entry dated November 18, 2020.	Managed Backup Retention for AWS CloudHSM / Document history
2021-03-12	`AWS CloudHSM client version 5.0.0`	The first version of Client SDK 5 was released. The Document history states, `Released AWS CloudHSM client version 5.0.0.` According to the "Migrating from Client SDK 3 to Client SDK 5" page in the User Guide, Client SDK 5 combines the user management and key management tools from Client SDK 3 into a single tool called CloudHSM CLI.	Document history / Migrating from Client SDK 3 to Client SDK 5
2022-01-03	`AWS CloudHSM client version 3.4.4`	This was the final version of Client SDK 3. The User Guide's "End-of-life Client SDK releases" page states `SDK versions 3.4.4 and earlier have reached the end of support.` The page does not give the date.	Document history / End-of-life Client SDK releases
2023-05-23	`AWS CloudHSM client version 5.9.0`	This version of the Client SDK was later identified as the oldest version compatible with `hsm2m.medium`. The User Guide's "HSM types" page states that `hsm2m.medium` is `Compatible with Client SDK version 5.9.0 and later.` The end-of-life page lists 5.8.0 (released on March 16, 2023) and earlier as having reached the end of support.	Document history / HSM types / End-of-life Client SDK releases

2024–2026 — `hsm2m.medium` and the End of `hsm1.medium`

In 2024, the FIPS 140-3 Level 3 hsm2m.medium was added, along with non-FIPS mode, which allows all keys and algorithms supported by CloudHSM regardless of FIPS approval. For hsm1.medium, a stop to new cluster creation, automatic migration, and end of support followed. Because the materials give two different dates both for the end of Triple DES and other operations and for the end of support of hsm1.medium, this article gives each date its own entry.

Date	Name on That Date	What Happened	Source
2024-01-01	`AWS CloudHSM`	This is the date on which, according to the versions of the Deprecation Notifications archived by the Internet Archive on 2023-08-09 and 2025-04-14 and the version on the verification date, the generation and encryption of Triple DES keys, as well as RSA wrapping, unwrapping, encryption, and decryption with PKCS #1 v1.5 padding, end in FIPS mode clusters. Decryption using Triple DES keys remains functional. The page cites NIST's guidance that their use is disallowed after 2023-12-31, and the version on the verification date states that `support for these end on January 1, 2024 in our Federal Information Processing Standard (FIPS) mode clusters`. The version archived on 2023-08-09 gives the same date: `support for these end on January 1, 2024 in our Federal Information Processing Standard (FIPS) compliant instances`.	Deprecation Notifications / Deprecation Notifications (Internet Archive, 2023-08-09) / Deprecation Notifications (Internet Archive, 2025-04-14)
2024-06-10	`hsm2m.medium` / `non-FIPS`	The User Guide's Document history indicates that a new HSM type and a new cluster mode were added on this date. The entry reads: `Launched a new HSM type (hsm2m.medium) and a new cluster mode (non-FIPS).` The Cluster modes page states: `All clusters created before June 10, 2024 are in FIPS mode and have HSM type hsm1.medium.`	Document history / Cluster modes
2024-08-20	`hsm2m.medium`	What's New announced the availability of `hsm2m.medium` on this date. The announcement states that `AWS CloudHSM launched hsm2m.medium with support for Federal Information Processing Standard (FIPS) 140-3 Level 3 and non-FIPS CloudHSM clusters.` It highlights that `hsm2m.medium` can utilize backups from `hsm1.medium` and supports mTLS for communication between the Client SDK and the cluster. The corresponding entry in the Document history indicates that it became possible to create `hsm2m.medium` instances in FIPS mode clusters on this date.	AWS CloudHSM launches new hsm2m.medium instance type / Document history
2025-01-01	`AWS CloudHSM`	This is the date on which, according to the version of the Deprecation Notifications archived by the Internet Archive on 2023-12-20, the same operations end. Citing updated guidance from NIST, that version stated `extend support until Dec 31, 2024. Starting January 1, 2025, AWS CloudHSM will no longer support the following cryptographic operations`. The version archived on 2025-04-14 and the version on the verification date give 2024-01-01. This article was unable to find any announcement of a change to this date.	Deprecation Notifications (Internet Archive, 2023-12-20)
2025-04	`hsm1.medium`	It is no longer possible to create new `hsm1.medium` clusters. The Deprecation Notifications, in the version archived by the Internet Archive on April 14, 2025, and in the version on the verification date, state: `Starting April 2025, you won't be able to create new hsm1.medium clusters.` The HSM types page states regarding `hsm1.medium`: `CloudHSM no longer supports creating new clusters in any AWS Region.`	Deprecation Notifications (Internet Archive, 2025-04-14) / Deprecation Notifications / HSM types
2025-05-09	`hsm1.medium` / `hsm2m.medium`	An article detailing migration procedures was published on the AWS Security Blog. The article states: `The hsm1 instance type is reaching end-of-life and will be unavailable for service on December 1, 2025.` It also mentions that `starting April 2025, AWS will attempt to automatically migrate existing hsm1 clusters to hsm2`.	AWS Security Blog

Date	Name on That Date	What Happened	Source
2025-12-01	`hsm1.medium`	This is the end-of-support date in the version of Deprecation Notifications archived by the Internet Archive on April 14, 2025, and in the Security Blog article of May 9, 2025. That version stated, `The AWS CloudHSM hsm1.medium instance type will reach its end of support on December 1, 2025.`	Deprecation Notifications (Internet Archive, 2025-04-14) / AWS Security Blog
2026-01-20	`hsm1.medium` → `hsm2m.medium`	Automatic migration had begun by this date. The migration page stated, `As of January 20, 2026, automatic migrations to hsm2m.medium have begun.` The Deprecation Notifications on the verification date give the start of automatic migration as `Starting January 2026`.	Migrating from hsm1.medium to hsm2m.medium / Deprecation Notifications
2026-03-31	`hsm1.medium`	This is the end-of-support date in the version archived by the Internet Archive on April 16, 2026, and in the Deprecation Notifications on the verification date. The page stated, `The AWS CloudHSM hsm1.medium instance type will reach its end of support on March 31st, 2026.` ⚠ As of September 26, 2026, this wording still used "will reach."	Deprecation Notifications / Deprecation Notifications (Internet Archive, 2026-04-16)
2026-08-18	`AWS CloudHSM client version 5.18.0`	A Client SDK supporting ML-DSA signatures was released. The release page for the User Guide stated, `Client SDK 5.18.0 introduces new features and improvements across multiple components, including post-quantum ML-DSA signatures and EdDSA support.`	Document history / Latest releases
2026-09-01	`hsm2m.medium`	ML-DSA became available in FIPS mode for `hsm2m.medium` clusters. The ML-DSA page for the CloudHSM CLI stated, `Starting September 1, 2026, ML-DSA is available in FIPS mode for hsm2m.medium clusters.` ⚠ On the verification date, the AWS page regarding migration to post-quantum cryptography listed CloudHSM's ML-DSA as `in preview`.	Generate a signature with the ML-DSA mechanism / Migrating to post-quantum cryptography

Current Overview, Functions, Features of AWS CloudHSM

This section outlines AWS CloudHSM on the verification date, the operational boundary by era, and the old names and statements that remain on the verification date.

AWS CloudHSM on the Verification Date

According to the User Guide and FAQ on the verification date, AWS CloudHSM takes the following form:

Cluster: HSMs run in clusters. The FAQ strongly recommends placing at least two HSMs in two different Availability Zones for production workloads.
HSM Type: There are two types: hsm1.medium and hsm2m.medium. A cluster can contain only one type of HSM. It is not possible to create new hsm1.medium clusters.
FIPS Level: This varies depending on the HSM type. The User Guide's HSM type page states that hsm1.medium is compliant with FIPS 140-2, while hsm2m.medium is compliant with FIPS 140-3. The overview page indicates that HSMs in FIPS mode clusters have undergone validation according to either FIPS 140-2 Level 3 or FIPS 140-3 Level 3. The FAQ specifies that hsm2m.medium is certified according to FIPS 140-3 Level 3.
Cluster Mode: There are two modes: FIPS mode and non-FIPS mode. In FIPS mode, only keys and algorithms that have undergone FIPS validation can be used. Non-FIPS mode is only available with hsm2m.medium. The mode cannot be changed after the cluster is created.
Client SDK: The latest version is 5.18.0. With Client SDK 5, a single tool, the CloudHSM CLI, handles user management and key management.
HSM Users: The types of HSM users in the CloudHSM CLI are: unactivated admin, admin, crypto user (CU), and appliance user (AU). HSM users are distinct from IAM users.

As of the verification date, AWS CloudHSM key stores, one type of AWS KMS custom key store, are also built upon CloudHSM clusters. Details on their usage and history can be found at AWS History and Timeline regarding AWS Key Management Service.

The Operational Boundary — What AWS Operates and What Remains with You, by Era

This section presents the operational boundary, organized by era, using a figure and a table. The column structure of the table follows the conventions outlined in the "Background and Method" section.

Era	What AWS operates	What you control	Where AWS says so
`AWS CloudHSM` dedicated appliances (from 2013-03-26; known as `CloudHSM Classic` from 2017-08-14; scheduled to end on 2020-04-01)	Holds "Admin" credentials in Luna SA terminology, but does not hold "Security Officer" or partition credentials. The FAQ states that these credentials are only used to manage the appliance and cannot be used for HSM partitions. AWS uses these credentials to monitor and maintain the appliance's health and availability, and said it would usually attempt to notify the customer in advance of management operations that could disrupt service, such as installing a security patch or rebooting. The same FAQ states that AWS controls the appliance's availability, providing an example: `For instance, AWS can remove your network access to the appliance, or can re-initialize the appliance, which will result in destruction of your keys.` The same section also states that AWS cannot extract the keys or perform cryptographic operations with them.	Holds "HSM Admin" and "HSM Partition Owner" credentials in Luna SA terminology. Responsible for initializing and managing HSM partitions, as well as creating and managing keys. The customer is responsible for maintaining the appliance's firmware and software. The customer is solely responsible for the durability of the keys. The FAQ cites AWS's lack of "Security Officer" and "Cloning Domain" credentials, required for backup and high availability configurations, as a reason for this.	AWS News Blog (2013-03-26) / FAQ (Internet Archive, 2016-06-11)
`AWS CloudHSM` clusters (from 2017-08-14)	Holds a limited credential to the HSM. The FAQ describes it as a credential used for monitoring and maintaining the HSM's health and availability, taking encrypted backups, and extracting and delivering audit logs to CloudWatch Logs. AWS provisions hardware, applies software patches, provides high availability, and performs backups. AWS manages the firmware; only firmware signed with the FIPS key can be installed, and AWS does not hold that key. AWS backs up the cluster daily and automatically replaces failed HSMs. The User Guide states that the appliance user is used to synchronize HSMs within the cluster.	The customer holds the HSM users and keys. The User Guide states that user management is outside of IAM. For the 24-hour period between backups, the customer alone is responsible for key durability. The customer is also responsible for designing the cluster's high availability. When deleting keys or users in a way that prevents recovery, the customer must also delete any backups containing them.	What's New (2017-08-14) / FAQ (Internet Archive, 2018-07-19) / FAQ / HSM user types / Update management / What is AWS CloudHSM? / What's New (2018-09-10)
`hsm2m.medium`, and migration from `hsm1.medium` (from 2024-06-10)	Migrates the cluster on the customer's behalf. The migration replaces HSMs one at a time, taking a full cluster backup before migrating each HSM. If errors increase or validation fails, the migration will stop and the cluster will be rolled back to its original type.	Selects the cluster's mode, which cannot be changed after creation. The customer can choose to let AWS handle the migration or create a new cluster from a backup of the `hsm1.medium` cluster and redirect the application. The migration page lists the conditions for migration, one of which is that all client connections in the last 7 days have used Client SDK 5.9 or higher (5.13 or higher if performing ECDSA signature verification). The conditions also include that an SDK has connected to at least one HSM in the cluster in the last 7 days, and clusters with no client connections in the last 14 days are exempt from this condition. Within 24 hours of starting the migration, the customer can manually roll back to the original type.	Migrating from hsm1.medium to hsm2m.medium / Cluster modes / Deprecation Notifications
Consistent across all eras	Has no access to the customer's keys or HSM credentials. Therefore, even if a customer loses their credentials, AWS cannot recover the keys.	HSM credentials and the keys they protect.	FAQ (Internet Archive, 2016-06-11) / FAQ

The table shows where the boundary moved and where it did not.

First, there's the firmware. The FAQ archived by the Internet Archive on 2016-06-11 states that maintaining the firmware is the customer's responsibility. The FAQ archived by the Internet Archive on 2018-07-19, and the FAQ on the verification date, answer the question of whether customers need to manage the firmware, stating that AWS manages it.

Maintaining the appliance firmware and software is the responsibility of the customer.
No. AWS manages the firmware on the hardware.

Second, there's the key durability. The 2016 version stated that the customer is solely responsible. The version on the verification date states that AWS takes daily encrypted backups, and that the customer alone is responsible only for the 24-hour period between backups. Since 2020-11-25, AWS also deletes old backups according to the retention period.

Third, there are the credentials held by AWS. The 2016 version stated that AWS holds credentials for managing the appliance. The version on the verification date states that AWS holds a limited credential for health and availability, backups, and audit logs. In both eras, AWS holds credentials for the HSM. Saying that AWS holds no credential to the HSM does not match the documentation of any era.

The keys and credentials did not move. The FAQs, when asked whether Amazon can recover the keys if a customer loses their credentials, provide the same answer in both the 2016 version and the version on the verification date.

No. Amazon does not have access to your keys or credentials
and therefore has no way to recover your keys if you lose your credentials.

However, the FAQ archived by the Internet Archive on 2016-06-11 also stated that AWS could reinitialize the appliance, which would destroy the keys. Having no access to the keys is different from having no way to destroy them. The FAQ archived by the Internet Archive on 2018-07-19 and the FAQ on the verification date did not contain similar descriptions regarding clusters.

The User Guide on the verification date states the same boundary in other words. On the page describing the types of HSM users, it states what AWS cannot do.

AWS cannot view or modify your users or keys and cannot perform any cryptographic operations using those keys.

The same page also states, just before that sentence, AWS cannot perform any operations on your HSMs. However, the same page states that AWS CloudHSM uses the appliance user to synchronize the HSMs, and the FAQ states that AWS holds a limited credential for health and availability, encrypted backups, and audit logs. This one sentence conflicts with both the rest of the page and the FAQ.

On the overview page of the same User Guide, it states the trade-off for this level of control: The trade off for this control is you have more responsibility than if you used a managed AWS service.

Old Names and Statements That Remain on the Verification Date

On the verification date of 2026-09-26, the following names and descriptions remained in AWS documentation. Each of them is a clue that leads back to the name of an older era when you check them against your own documents.

What	On the verification date	Where
AWS CLI `aws cloudhsm`	The description for the command group begins with `This is documentation for AWS CloudHSM Classic`. Currently, `aws cloudhsmv2` is used to manage clusters.	AWS CLI Command Reference
CloudHSM Classic FAQ	The URL redirects to the current FAQ.	`https://aws.amazon.com/cloudhsm/faqs-classic/`
`hsm1.medium` End of Support	On the verification date, after 2026-03-31 has passed, the Deprecation Notifications still state `will reach its end of support on March 31st, 2026`.	Deprecation Notifications
Client SDK End of Support	The end-of-life page states that versions 3.4.4 and earlier and 5.8.0 and earlier have reached their end of support, but does not specify dates. The same page also states that AWS CloudHSM may refuse connections from versions that have reached their end of support.	End-of-life Client SDK releases
`hsm1.medium` and Client SDK 3 compatibility	The HSM types page describes `hsm1.medium` as `Compatible with SDK version 3.1.0 and later.`, and the page on HSM compatibility for Client SDK 3 also states `Compatible with Client version SDK 3.1.0 and later.` The end-of-life page states that versions 3.4.4 and earlier are no longer compatible with the service.	HSM types / HSM compatibility for AWS CloudHSM Client SDK 3 / End-of-life Client SDK releases
CloudHSM ML-DSA	The User Guide states that ML-DSA is available in FIPS mode for `hsm2m.medium` clusters from 2026-09-01. The AWS post-quantum cryptography migration page states `in preview`.	Generate a signature with the ML-DSA mechanism / Migrating to post-quantum cryptography

Frequently Asked Questions about AWS CloudHSM History

This section answers common questions about the history of AWS CloudHSM.

What was CloudHSM Classic?

CloudHSM Classic was the original version of AWS CloudHSM, introduced on March 26, 2013. It placed SafeNet Luna SA HSM appliances in the customer's VPC, each used by a single customer. The name "CloudHSM Classic" was adopted on August 14, 2017, following the announcement of a new CloudHSM. AWS announced that no new capacity would be available from July 1, 2019, and that running HSMs would be terminated on April 1, 2020.

When did hsm1.medium reach end of support?

According to various sources, there are two dates regarding the end of support for hsm1.medium. The User Guide's Deprecation Notifications archived by the Internet Archive on 2025-04-14 and a Security Blog post dated 2025-05-09 give 2025-12-01. The version archived on 2026-04-16 and the Deprecation Notifications on the verification date give 2026-03-31. This article found no announcements regarding changes to these dates. From April 2025, customers could not create new hsm1.medium clusters, and automatic migration had begun by 2026-01-20.

Can AWS access the keys in an AWS CloudHSM cluster?

No. The FAQ states that Amazon cannot access either the keys or the credentials. This response is consistent between the version archived by the Internet Archive on June 11, 2016, and the version on the verification date. However, the 2016 version also stated that AWS could reinitialize the appliance, which would destroy the keys. AWS does possess credentials for the HSMs in both eras. During the Classic era, AWS used these credentials to manage the appliances. In the cluster era, according to the FAQ from 2018 onwards, AWS holds a limited credential for the HSM's health and availability, encrypted backups, and audit logs.

Can Client SDK 3 still be used with AWS CloudHSM?

No. According to the end-of-life page in the User Guide on the verification date, versions 3.4.4 and earlier have reached their end of support. These versions are no longer compatible with the service and will not receive updates. AWS CloudHSM may refuse connections from versions that have reached their end of support. The final version of Client SDK 3, 3.4.4, came out on January 3, 2022. The hsm2m.medium HSM type is only supported by Client SDK versions 5.9.0 and later.

Why does a 2015 What's New post say CloudHSM Classic?

The post from 2015 refers to "CloudHSM Classic" because it was later updated. The announcement from January 8, 2015, Amazon RDS integrates Oracle Transparent Data Encryption with AWS CloudHSM, was written as AWS CloudHSM in versions archived by the Internet Archive on January 13, 2015, and October 13, 2016. By April 15, 2021, it had already been updated to "AWS CloudHSM Classic." The name "CloudHSM Classic" has been used since August 14, 2017, when the new CloudHSM was announced.

Summary

AWS CloudHSM began as a service that allowed customers to deploy dedicated HSM appliances within their VPCs, launching on March 26, 2013. On August 14, 2017, it was redesigned as a cluster-based service where AWS manages the hardware, patching, high availability, and backups. The original configuration became known as CloudHSM Classic. AWS announced that CloudHSM Classic would end on April 1, 2020. The Client SDK 5 was introduced in 2021, and in 2024, the FIPS 140-3 Level 3 hsm2m.medium and non-FIPS mode were added. Creating new hsm1.medium clusters stopped in April 2025, and automatic migration had begun by January 20, 2026. According to the User Guide, ML-DSA is available in FIPS mode on the hsm2m.medium HSM type from September 1, 2026 (the AWS post-quantum cryptography migration page states in preview).

⇒ AWS's operational responsibilities have expanded. The firmware moved from customer maintenance to AWS management. The period for which customers are solely responsible for key durability has narrowed to the 24 hours between backups. AWS holds a credential to the HSM in every era, but what that credential is for differs by era.

⇒ The boundary around keys and credentials has not moved. The answer that Amazon cannot access either keys or credentials is the same in the 2016 FAQ and in the FAQ on the verification date.

⚠ Names and dates need to be checked source by source. AWS retroactively applied the name "CloudHSM Classic" to an announcement from 2015, and there are two different dates listed in various documents regarding the end of support for hsm1.medium. All information is current as of September 26, 2026.

This timeline will be updated as AWS CloudHSM continues to evolve.

References:
Tech Blog with curated related content

Written by Hidekazu Konishi