How to Choose a Hardware Security Module: A Vendor-by-Vendor Guide
Choosing a hardware security module is a matter of matching a device to the environment it will serve. There is no single best HSM. The appropriate choice follows from an organisation's assurance requirements, workload type, integration estate, operational model and budget, weighted against one another and then mapped to the vendors that meet them.
How to approach an HSM decision
An HSM is the root of trust for an organisation's cryptographic estate. Every certificate issued, every payment authorised, every document signed and every disk encrypted depends ultimately on key material held inside one. The selection decision therefore carries consequences well beyond the procurement itself, and an unsuitable choice can remain undetected for a considerable period.
The decision outlives the project that made it
Hardware security modules are among the longest-lived infrastructure purchases an organisation makes. A device selected today will commonly remain in service for a decade or more, outlasting the programme that justified it, the architect who specified it and, in many cases, the vendor relationship that supplied it. Few other infrastructure decisions commit an organisation over so long a period.
HSM selection therefore warrants greater rigour than a standard infrastructure procurement. The relevant comparison extends well beyond the current price list, and should account for ten years of operating cost, integration effort, compliance posture and eventual migration risk.
The consequences of an unsuitable choice emerge late
An unsuitable HSM does not fail on installation. It passes acceptance testing, supports the initial use case and operates without incident for two or three years. The consequences emerge later, and they follow four recognisable patterns.
The first is vendor lock-in. Proprietary key formats, bespoke tooling and vendor-specific integration layers mean that transferring key material to a different platform becomes a project in its own right, with key ceremony implications and an extended period of elevated risk. A competitive purchase price therefore carries a dependency cost that becomes apparent only at renewal or refresh.
The second is compliance exposure. Certification and data sovereignty requirements that were not identified during selection are difficult to retrofit. Where a device is validated to FIPS 140-2 Level 3 and a subsequent regulatory obligation requires Level 4, or a new contract requires European provenance, the remedy is replacement rather than reconfiguration.
The third is a performance ceiling. Signing throughput and partition density that comfortably supported the original workload become constraints as the estate grows, as new use cases are introduced, or as certificate lifetimes shorten and renewal volumes rise accordingly.
The fourth, and currently the most pressing, is obsolescence. Post-quantum cryptography has moved from a research topic into live procurement. Devices that cannot support the NIST-standardised algorithms, and devices marketed as PQC ready without a crypto-agile architecture beneath the claim, face forced replacement as further standards are published. Crypto-agility should now be treated as a procurement requirement rather than a desirable feature.
Fit for purpose rather than one size fits all
There is no single best HSM for all deployments. A high-assurance national infrastructure site and a payment service provider are both procuring a hardware security module, but they are in practice procuring two different products. The two weight assurance, throughput, payment validation, form factor and cost in almost opposite proportions, and a device that performs well against one requirement set will frequently perform poorly against the other.
Our role in an HSM selection is to define the requirements, weight them against the environment they will serve, and then match them to the vendors and devices that meet them. We hold no allegiance to any single vendor.
The criteria that determine HSM fit
Eight criteria account for the substantive differences between hardware security modules. Working through them in sequence produces a requirements set that can be weighted and scored.
Assurance and certification
Certification is the first filter, because it is the most difficult attribute to change subsequently. The relevant distinctions are FIPS 140-2 against the newer FIPS 140-3 validation, the Level achieved within either standard, the Common Criteria Evaluation Assurance Level and, for European and qualified signing use cases, eIDAS conformity.
Most enterprise estates settle at FIPS 140-2 or 140-3 Level 3, which is the practical norm. Level 4 exists, but it is held by a small number of devices and carries cost and operational consequences that only genuinely high-assurance environments should accept. Organisations more commonly over-specify assurance than under-specify it, and pay for the excess in flexibility and running cost across the service life of the device.
Deployment model and form factor
Network appliances, PCIe cards and modular blade architectures each imply a different high-availability design, a different data centre footprint and a different failure domain. Small form factor and USB devices are relevant where physical space is constrained, where the device must be transported, or where a root certificate authority is held offline in secure storage rather than in a rack.
Form factor also determines cost in ways that are easily underestimated. Rack units, power, cooling and the number of physical devices required to reach an acceptable availability target all follow from this decision.
Performance and scale
Signing throughput is the headline specification, but partition density and behaviour under sustained load are more significant in practice. Partition density determines how many logical tenants, applications or certificate authorities a single device can serve, which in turn determines the number of devices required and the shape of the licensing.
Performance should be tested against the actual workload profile rather than accepted from the datasheet. A device that performs well on RSA-2048 signing may behave differently on elliptic curve operations, and differently again on the larger key and signature sizes that post-quantum algorithms introduce.
Payment or general purpose
Payment HSMs and general purpose HSMs are distinct product categories with distinct validation regimes. Organisations processing card transactions require PCI PTS HSM validation, and general purpose devices are not a substitute. Organisations issuing certificates, signing code and protecting database encryption keys require a general purpose device, and payment validation represents cost without corresponding benefit.
Some organisations require both. A small number of platforms cover both workloads on a single architecture, and this should be assessed before committing to two separate estates with two sets of ceremonies, two support contracts and two skill sets.
Integration and ecosystem
An HSM delivers value only through the systems that consume it. PKCS#11 support is the baseline, but the practical questions are more specific. Does the device integrate cleanly with the certificate authority in use, whether that is Active Directory Certificate Services or EJBCA Enterprise? Does it support KMIP for key management, REST for automation, OCSP for revocation responders, and SQL Transparent Data Encryption where that is in scope?
Integration gaps are a common source of delay in HSM projects. A device that requires custom middleware to communicate with the existing estate introduces a maintenance obligation that persists for the life of the deployment.
Post-quantum readiness and crypto-agility
The relevant question is no longer whether a vendor references post-quantum cryptography. It is whether the device supports the NIST-standardised algorithms natively, ML-KEM for key encapsulation and ML-DSA for digital signatures, and whether the underlying architecture can adopt further algorithms without a hardware refresh.
The second condition is what separates the market. Adding PQC algorithm support to an existing product line is a firmware exercise. Designing a device on the assumption that algorithms will change is an architectural decision taken years earlier. Both approaches are legitimate, but they produce materially different outcomes across a ten-year service life, and vendor claims in this area should be verified rather than accepted.
Operational model
Key ceremony complexity, role separation requirements, day-to-day administrative overhead and the skills the operating team must hold are all determined at selection. A device with a demanding ceremony model may be entirely appropriate for a high-assurance root and entirely inappropriate for an estate that provisions partitions weekly.
The relevant questions are who will operate the device, whether those individuals are currently in post, and what arrangements apply when they leave. A device that meets every technical requirement but cannot be operated by the available team is not a viable selection.
Commercial terms and total cost of ownership
Licensing models vary considerably, particularly around partition pricing, which can convert a competitive headline price into an expensive estate as the number of consuming applications increases. Support tiers, firmware maintenance, backup device requirements and the cost of eventual migration all belong in the calculation.
Weighting the criteria for the environment
Scoring devices against eight criteria produces a ranking. Weighting those criteria first produces a decision.
Consider a high-assurance, high-availability site in critical national infrastructure. Assurance and certification weight high. Deployment model and high-availability design weight high, because service continuity is the primary objective. Post-quantum readiness and crypto-agility weight high, because the estate will remain in service beyond the current standardisation cycle. The operational model weights high, because ceremony discipline and role separation form part of the accreditation. Performance weights medium. Payment capability weights low, as no card transactions are processed. Commercial cost weights medium, since assurance is the governing constraint.
Now consider a payment service provider. Assurance remains high, but payment capability moves from low to high, because PCI PTS validation is mandatory. Performance and scale weight high, because transaction throughput determines the service. Commercial cost weights high, because margin per transaction is narrow and the estate is large. Post-quantum readiness and operational model both move to medium, not because they lack importance, but because they are not the criteria on which this purchase turns.
Two organisations apply the same eight criteria and arrive at different answers. Each candidate device is scored from one to three against each criterion, the weighting is applied, and the totals identify the best fit for that environment rather than the strongest device in the market as a whole.
Hardware security module vendors compared
The assessments below cover hardware appliances. Cloud HSM services represent a separate decision with a different evaluation model and are out of scope. Where Unsung holds a partnership, this is stated in the relevant profile.
Thales
Thales holds the broadest portfolio in the market and the largest share of market recognition, which makes it the default comparison point in most evaluations. The Luna range covers general purpose key protection and PKI, while payShield addresses payments as a separate, purpose-built line.
Luna 7 holds FIPS 140-3 Level 3 validation, placing it among the devices that have completed the transition to the newer standard. The range spans network appliances, PCIe cards, USB devices and backup HSMs, which allows a single vendor relationship to cover an offline root certificate authority, a high-availability issuing tier and a development environment without introducing a second platform.
The principal strengths are portfolio breadth, ecosystem maturity and integration coverage. Almost every certificate authority, key management platform and enterprise application that supports HSMs supports Luna, which removes a substantial category of integration risk. Post-quantum support is being added to the existing product line rather than designed in from the outset, which is a legitimate approach but is not equivalent to a crypto-agile architecture.
The corresponding constraint is commercial. Thales is rarely the lowest-cost option, and partition-based licensing can make estate growth expensive. Best suited to a high-assurance, high-availability environment in which proven reliability and ecosystem breadth outweigh unit cost. Unsung is a Thales partner and deploys the Luna Network HSM 7 across regulated estates.
Entrust
Entrust approaches the HSM market from an identity and PKI heritage, and the nShield 5 reflects that origin. It holds FIPS 140-3 Level 3 and Common Criteria EAL4+, a strong combined position, and it is among the few devices to have completed the transition to the newer FIPS standard.
The architectural differentiator is the container model and in-HSM code execution. Executing application code inside the secure boundary is of practical value to organisations building custom cryptographic services, sensitive business logic or bespoke signing workflows, because key material is never exposed to the host environment.
Integration with certificate authorities and key management platforms is close, and the wider Entrust portfolio allows PKI, credential management and HSM to be sourced from a single supplier where that is desirable. For organisations already operating Entrust PKI, the operational alignment is a material advantage.
That alignment also has a corresponding cost. Close integration with a single vendor's stack constrains the ability to replace individual components later, and pricing sits at the premium end alongside Thales. Best suited to identity-led enterprise PKI where in-HSM execution or close key management integration forms part of the stated requirement. Unsung is an Entrust partner.
Utimaco
Utimaco is the leading European option and the strongest response to a data sovereignty requirement. The SecurityServer and CryptoSec lines cover general purpose and payment workloads respectively, on a modular platform architecture.
The assurance position is notable. Utimaco reaches FIPS 140-2 Level 4 and Common Criteria EAL4+, placing it in the small group of vendors at the highest level of physical security currently achievable commercially. Where the certification ceiling is the governing requirement, this consideration outweighs any feature comparison.
The sovereignty position is the second reason Utimaco appears on shortlists. German engineering and manufacturing, European support and a regulatory posture aligned to EU frameworks including eIDAS suit organisations with provenance requirements written into contracts or accreditation.
Post-quantum support is progressive rather than architectural, and the integration ecosystem, while substantial, is narrower than the Thales footprint across certain enterprise applications. A USB form factor is in development but is not yet established. Best suited to environments where European data sovereignty, regulatory alignment or a Level 4 assurance ceiling is the primary driver.
Futurex
Futurex offers a converged platform, with a portfolio covering payments and enterprise key management on shared architecture. Vectera Plus and Excrypt are the established general purpose and payment lines, and CryptoHub extends the model into a consolidated cryptographic platform.
Futurex devices hold FIPS 140-2 Level 3 and PCI HSM validation, which is the combination that supports the converged proposition. Where an estate requires both payment processing and general purpose key and certificate operations, running both workloads on one platform removes a considerable degree of duplication across ceremonies, support contracts, monitoring and skills.
Deployment flexibility is a further strength. On-premises appliances, hosted models and the VirtuCrypt service provide more than one route to the same capability, which supports phased migrations and hybrid estates.
Market presence in the United Kingdom is smaller than that of Thales or Entrust, which can mean a narrower pool of experienced engineers and fewer established integration precedents. Best suited to a combined payment and general purpose environment where consolidation onto a single platform delivers a measurable operational saving. Unsung is a Futurex partner and works with the Futurex CryptoHub platform.
Crypto4A
Crypto4A is a fifth-generation platform designed to be quantum-safe from the outset rather than upgraded towards that position. The QxHSM holds FIPS 140-3 Level 3 validation, and the Container-In HSM architecture supports isolated cryptographic workloads within the device.
The architectural position is the substantive differentiator. Where established vendors are adding NIST post-quantum algorithm support to product lines designed before those standards existed, Crypto4A designed the platform on the assumption that algorithms will continue to change. For a device that will remain in service well beyond the point at which post-quantum migration becomes mandatory, that distinction has practical consequences.
The modular blade form factor is the second differentiator and is easily overlooked. Data centre footprint is a genuine cost in high-availability designs requiring multiple devices across multiple sites, and consolidating that footprint alters the rack, power and cooling calculation.
The corresponding constraints are ecosystem maturity and payment capability. Crypto4A is a more recent entrant with a smaller integration footprint than the established vendors, and it is not a payments platform. Best suited to a forward-looking root of trust, to critical national infrastructure, or to any estate where post-quantum readiness is the determining criterion rather than a future consideration. Unsung is a Crypto4A partner, and states this so that the post-quantum assessment can be judged on its own terms.
IBM
The IBM 4770 coprocessor occupies a specific and defensible position. It is a PCIe form factor device and one of the few HSMs validated to FIPS 140-2 Level 4, the highest commercially available physical security assurance.
The CCA architecture and the close coupling to IBM Z environments define both the strength and the limitation. Within a mainframe estate, particularly in financial services, the 4770 is well integrated, well understood and unmatched on assurance grounds. Outside that context, the integration model is considerably less convenient.
The PCIe form factor constrains deployment design. There is no network appliance equivalent, so the device is bound to its host, with the availability and capacity planning implications that follow. Post-quantum positioning is less prominent than that of the specialist vendors, and the operational model assumes mainframe skills that many organisations no longer retain in depth.
Best suited to highest-assurance financial services and mainframe environments, particularly where an IBM Z estate is already in place. For a general purpose enterprise PKI with no mainframe footprint, it is rarely the practical selection regardless of the assurance ceiling.
Securosys
Securosys is Swiss-manufactured, holding FIPS 140-2 Level 3 and Common Criteria EAL4+, and competes on a combination of provenance, post-quantum readiness and specific workload strength.
The Primus platform is well established in payments and has a notable presence in blockchain and digital asset custody, a workload with distinctive requirements around transaction signing, quorum approval and availability. Where those requirements apply, Securosys holds relevant deployment experience that the broader vendors do not consistently match.
On post-quantum readiness, Securosys sits closer to Crypto4A than to the incumbents, treating PQC support as a current capability rather than a roadmap commitment. Combined with Swiss provenance, this makes it a credible option for organisations seeking sovereignty outside the European Union alongside a forward-looking cryptographic posture.
The constraints are ecosystem scale and market presence. The integration footprint is smaller, and support resourcing in the United Kingdom is thinner than that of the major vendors. Best suited to payments, digital asset or Swiss-sovereignty environments where post-quantum readiness is also a live requirement.
Fortanix
Fortanix approaches the requirement from a software-defined, cloud-first direction, and the FX2200 appliance is the hardware expression of that platform rather than a standalone product. It holds FIPS 140-2 Level 3 and is backed by Intel SGX enclave technology.
The central capability is unification. Data Security Manager presents on-premises HSM keys, cloud provider keys and application secrets through a single interface under a consistent policy model. For an organisation holding keys across multiple clouds alongside an on-premises estate, that consolidation addresses an operational problem that traditional HSM vendors do not resolve as directly.
The operational model is the platform's principal strength. Administration, policy and automation carry considerably less overhead than a conventional appliance, and REST-first integration suits organisations building automated pipelines rather than operating manual ceremonies.
The corresponding constraints are the assurance ceiling and depth in traditional PKI. FIPS 140-2 Level 3 is the enterprise norm but not the high-assurance ceiling, payment capability is not the focus, and organisations with demanding root ceremony requirements may find the model less aligned to their accreditation. Best suited to cloud-first or multi-cloud estates where unified key management across environments outweighs the final increment of physical assurance. Unsung is a Fortanix partner and deploys Fortanix Data Security Manager.
Where the vendors substantively differ
Three areas account for most of the genuine separation between these platforms.
The first is the assurance ceiling. IBM and Utimaco reach FIPS 140-2 Level 4, the highest level currently achievable commercially. Thales, Entrust, Crypto4A, Futurex, Securosys and Fortanix centre on Level 3, the enterprise norm. The more current distinction is the transition to the newer standard, where Entrust nShield 5, Thales Luna 7 and Crypto4A QxHSM hold FIPS 140-3 validation while others remain on 140-2. For most organisations, Level 3 under 140-3 represents a more useful position than Level 4 under 140-2, although the requirement should derive from the applicable accreditation rather than from preference.
The second is post-quantum posture, and this is the area in which vendor language is least reliable. Crypto4A is quantum-safe by design, built for the post-quantum era at the architectural level. Securosys treats PQC as a current capability. Entrust and Thales are adding NIST PQC algorithm support to existing product lines, which is a legitimate and well-executed approach. The meaningful distinction is not whether a device supports ML-KEM and ML-DSA at present, but whether the architecture is crypto-agile or whether post-quantum support has been added to a fixed design and will require revisiting when the next algorithm is standardised.
The third is workload and form factor. Thales and Entrust both offer small form factor USB devices for deployments where physical space or mobility is a factor, and Utimaco has a USB offering in development. Thales payShield and Utimaco CryptoSec are established specifically in payments, with Futurex and Securosys also holding genuine payment credentials. The Crypto4A modular blade architecture reduces data centre footprint significantly, which affects the total cost position in multi-site high-availability designs more than unit price does.
How HSM vendors charge
The appliance price is the figure that appears in the business case. It rarely accounts for more than half of what the estate costs. The commercial model therefore merits closer examination than headline unit prices, because two devices at a comparable purchase price can differ substantially once partitions, licences, disaster recovery and support are included.
The device itself
Every vendor sells hardware in at least two form factors, and the price difference between them is significant. A network appliance is the shared enterprise option and carries the highest unit price of the three. A PCIe card is installed within a host and generally costs between a third and two thirds of the equivalent appliance. A USB or small form factor device, suited to offline roots and constrained sites, is lower again, frequently by an order of magnitude.
Within a single appliance line, price scales with performance and memory rather than with function. Vendors publish tiered models, and the difference between entry and top tiers is commonly a factor of one and a half to two. Specifying the top tier for a workload that does not require it represents one of the more significant avoidable costs at selection.
Partitions
A partition is a logically isolated key store within one physical device, and it is the primary licensing lever in this market. Devices ship with a base allocation, commonly five partitions, and additional capacity is purchased as an upgrade licence.
Partition licensing is a material cost. A five-partition field upgrade on a mainstream appliance is a mid four-figure sum at list, so expanding an appliance from five to twenty partitions can add a five-figure sum to a device already installed and paid for. Because applications are onboarded gradually, this cost arises after the business case has been approved and is frequently unbudgeted.
Not every vendor operates this model. Some price primarily on performance and partition count together, placing no licence restriction on the number of host servers, clones or backups. Securosys, for example, ships its X-Series with two partitions by default and states that host servers, clones and backups are not licence restricted. For an estate with a large number of consuming applications, that difference in model can outweigh a difference in unit price.
Client and connection licences
Several vendors licence the connection between the HSM and the systems that consume it. Each client licence permits a connection from one IP address, and licences are sold in packs. Entrust ships nShield Connect appliances with three client licences included. Thales sells client licences for Luna Network HSM in packs.
This is the line item most frequently omitted at business case stage, because it scales with the number of connecting servers rather than with the number of HSMs. An estate with ten application servers connecting to two appliances requires ten client licences, not two, and those licences also attract annual maintenance.
Feature and algorithm activation licences
Certain cryptographic capability is licensed separately. Entrust notes that while nShield HSMs support most algorithms within the standard feature set, elliptic curve and South Korean algorithms require optional activation licences. Thales delivers post-quantum capability through a Functionality Module, and the device must be ordered FM-ready at the point of purchase for that upgrade path to remain available.
That detail carries a direct consequence. Where crypto-agility forms part of the rationale for the purchase, the specific SKU should be confirmed as supporting the upgrade path at order stage, or the hardware will require replacement to obtain it.
Disaster recovery and backup devices
Disaster recovery is a separate purchase rather than a configuration option. Backup HSMs are among the lower-cost items in the range, but each attracts maintenance at the same rate as a production device.
Software-defined platforms handle this differently but not without cost. Fortanix sells a distinct DR appliance SKU, priced at a discount to the equivalent production appliance. The reduction is genuine, but a two-site resilient design still adds a material sum to the hardware line.
The wider point is that a properly resilient estate does not consist of two devices. It comprises production devices at each site, backup devices for key material, and frequently a separate offline root device held in secure storage. The design should be costed, not the individual device.
Consumables and accessories
Accessory costs accumulate more quickly than expected. Remote PED units, which provide multi-factor authentication for high-assurance devices, are charged per unit. Smart cards for administrative quorum are priced per card and are often required in larger quantities than anticipated once role separation and split custody have been designed. Rack rails and power cords are charged separately, per device.
Remote administration forms its own commercial line, and its scope varies considerably between a single administration kit and an estate-wide licence. Futurex sells the Excrypt Touch, a portable tablet incorporating a FIPS 140-2 Level 3 device for remote key loading, as a separate item.
No single item here is large. Across a multi-site estate they constitute a material line.
Maintenance and support
Maintenance is the most consistently underestimated element of HSM commercials, for two reasons.
The first is the rate. Across the quotations we have priced, enhanced maintenance runs at approximately 18 per cent of list price per year, and premier maintenance at approximately 23 per cent per year. Over a five-year term, enhanced support alone approaches 90 per cent of the hardware value. Over a ten-year service life, cumulative support cost exceeds the original hardware value.
The second is the base against which it is charged. Maintenance applies to every licensed line item, not solely to the appliance. Partition upgrade packs, client licences, remote PEDs, iKey packs and backup HSMs all attract the same percentage, which is why maintenance represents approximately a third of a large estate's list price rather than a small percentage of the hardware.
Vendors that make annual maintenance mandatory rather than optional, which is common, remove the ability to defer it in a constrained year. The applicable model should be confirmed before the ten-year forecast is built.
Training and certification
Vendor training is a discrete cost rather than an obligation absorbed by the delivery partner. Entrust, for example, runs certified systems engineer and certified system developer courses, priced per course and varying with delivery format and delegate numbers. Given that HSM skills are narrow and the available market is limited, budgeting for two or three certified individuals rather than one is a realistic provision.
Subscription and as-a-service models
Every major vendor now offers a subscription alternative, and the commercial structure differs entirely. Entrust nShield as a Service, Thales payShield Cloud and Fortanix Data Security Manager all move the cost from a capital purchase to an annual or per-node licence, with support charged alongside it.
The public cloud providers price by the hour. AWS CloudHSM charges per HSM hour, and a high-availability design requires at least two instances. Across a five-year life this is broadly comparable to purchasing and maintaining hardware, without the capital outlay and without the physical control that regulated environments frequently require.
Subscription is not automatically the lower-cost option. It converts capital expenditure into operating expenditure, removes refresh risk, and constrains ceremony design and certification claims in ways that are material to some organisations and immaterial to others.
Professional services, migration and exit
Design, key ceremony execution, integration and migration are rarely included within the product cost. A greenfield build should carry a distinct professional services line, and a migration a larger one, because non-exportable key material must be regenerated and everything depending on it reissued.
Few organisations cost the exit at the point of entry. The requirements for migrating away from a platform should be established before contract, while commercial leverage remains, and a figure attached to them.
What an estate costs in practice
Two anonymised examples from recent pricing exercises illustrate the distribution more usefully than any single unit price.
The first is a multi-site, high-availability deployment on a mainstream appliance line, priced at approximately £400,000. The appliances accounted for approximately 42 per cent of that figure. Three-to-five-year maintenance accounted for approximately 34 per cent. The remaining 23 per cent comprised partition upgrade packs, client licences, a backup HSM, remote PED units, iKey packs, rack rails and power cords. More than half the cost of the estate therefore sat outside the line item most commonly used to compare vendors.
The second is a software-defined deployment covering nine production nodes and two disaster recovery appliances, priced a little under £150,000 for the first year. Hardware accounted for approximately 78 per cent of that figure. The remaining 22 per cent was annual licensing and premium support, both of which recur in every subsequent year and neither of which appeared in the original hardware comparison.
Common errors in HSM procurement
Five patterns account for most of the HSM decisions we are subsequently asked to remediate.
- Selecting on assurance level alone. A Level 4 device that the operating team cannot administer, that does not integrate with the certificate authority in use and that costs materially more than the alternative delivers a higher cost rather than a better security outcome. Certification functions as a filter, not as a scoring system.
- Disregarding partition licensing. Organisations model the capital cost of the appliance without modelling the licensing profile as applications are onboarded. Three years into the deployment, the partition count has tripled and the running cost bears no relation to the approved business case.
- Treating post-quantum readiness as a compliance checkbox. The term PQC ready appears on a great many datasheets and carries materially different meanings. The relevant questions are which algorithms are supported in firmware today, which are on the roadmap and against what dates, and what occurs architecturally when a further algorithm is standardised. Vendor claims in this area require verification, and the difference between a crypto-agile architecture and a PQC-labelled product may represent several years of avoided replacement cost.
- Deferring key ceremony design until deployment. Ceremony complexity, role separation and quorum requirements are determined by the device and by the applicable assurance framework. Establishing at implementation that a ceremony requires five cleared individuals for two days when three are available converts a scheduling constraint into a programme delay.
- The absence of an exit plan. Few organisations establish the cost of leaving a platform at the point of entering it. The requirements for migrating away, the treatment of key material, and the ceremony implications should all be established before contract, while commercial leverage remains.
How Unsung helps
Unsung is a specialist PKI consultancy with more than twenty PKI experts across operations, technical, solution and enterprise disciplines, including security cleared consultants at SC and DV levels. We work with UK government and private sector clients, and we are vendor agnostic as a matter of principle rather than positioning.
On selection, we define and weight requirements against the environment they will serve, then recommend the device that scores highest against them. We hold partnerships with several of the vendors covered here and disclose them, so that the basis of any recommendation can be independently assessed.
On design and build, we deliver architecture, key ceremonies and high-availability deployment with specialists who have executed them in highly assured operating environments.
On integration, we connect the HSM to the certificate lifecycle management platform, the certificate authority and the wider estate, including ADCS and EJBCA.
On support and management, we provide managed services and PKI health checks that maintain the compliance and resilience of the estate after the delivery team has stood down.
For organisations considering an HSM investment or migration, our hardware security module services cover the full lifecycle, and our specialists are available to discuss specific requirements.
Frequently asked questions
What is a hardware security module?
What is the difference between FIPS 140-2 and FIPS 140-3?
What do the FIPS 140 Levels mean?
Is FIPS 140-2 Level 4 better than FIPS 140-3 Level 3?
What is Common Criteria EAL and how does it relate to FIPS?
Does an HSM need to be eIDAS conformant?
How is a vendor's certification claim verified?
Is a payment HSM or a general purpose HSM required?
Can one HSM platform cover both payment and general purpose workloads?
Is an HSM required for an internal certificate authority?
What is the difference between an HSM and a key management system?
Can an HSM be used for code signing?
What does PQC ready mean on an HSM datasheet?
Which post-quantum algorithms should an HSM support?
Will an existing HSM require replacement for post-quantum cryptography?
What is crypto-agility, and why does it affect HSM selection?
Do post-quantum algorithms affect HSM performance?
How many HSMs are required for high availability?
What HSM form factors are available?
What is a partition, and why does partition density matter?
How should an offline root certificate authority be protected?
What is a key ceremony?
What skills are required to operate an HSM?
What happens if an HSM fails?
How is an HSM backed up?
How long does an HSM remain in service?
What drives the total cost of an HSM estate?
Can key material be migrated between HSM vendors?
Should a cloud HSM service be used instead of hardware?
What should be tested during an HSM proof of concept?
How are HSM vendors compared objectively?
Who should be involved in an HSM selection?


