HSM-as-a-Service vs HSM on-prem : une matrice de décision pour 2026

Ce qui n'a pas changé sur les HSM depuis 2019

Les fondamentaux d'un module matériel de sécurité n'ont pas bougé en sept ans. Un équipement qui génère, stocke et opère sur des clés privées à l'intérieur d'un silicium tamper-evident et tamper-responsive reste la seule racine de confiance crédible sous PCI DSS 4.0 exigence 3.6, les obligations de service de confiance qualifié eIDAS 2.0, le provisionnement de signatures FIPS 186-5 et les profils de protection Common Criteria EAL4+ pour les modules cryptographiques.

L'HSM est l'ancre où les maths des clés publiques et privées rencontrent la physique d'une frontière scellée, et cette ancre est encore porteuse pour chaque déploiement PKI qu'un CISO signera en 2026.

Ce qui a bougé est la baseline de certification. Le programme de validation FIPS 140-2 s'est fermé aux nouvelles soumissions le 1er avril 2022 et a cessé d'accepter les mises à jour le 21 septembre 2026, avec tous les certificats 140-2 passant sur la liste historique d'ici 2027. Chaque achat greenfield en 2026 doit spécifier FIPS 140-3 Level 3 au minimum, aligné avec ISO/IEC 19790:2012 et ISO/IEC 24759:2017.

Le Level 3 impose une authentification basée sur l'identité, une réponse physique au tampering qui zéroïse activement le matériel de clé en clair, et une enveloppe de protection contre les défaillances environnementales. Le Level 4 ajoute la détection d'attaques de tension et de température sur toute l'enveloppe opérationnelle, ce qui compte pour les ambassades, les programmes de défense et les commutateurs de paiement tier-1 mais est excessif pour un service de signature SaaS. CC EAL4+ avec le profil de protection EN 419 221-5 reste la référence européenne pour les signatures électroniques qualifiées sous eIDAS 2.0 Article 29a.

Les interfaces n'ont pas bougé non plus. PKCS#11 v3.0 reste la lingua franca pour les applications natives, avec KMIP 2.1 couvrant la gestion de clé à distance entre HSM et plan d'orchestration. JCE/JCA, Microsoft CNG, les engines et providers OpenSSL et les URI PKCS#11 couvrent encore 95 % des chemins d'intégration.

Si un fournisseur propose une interface REST-uniquement propriétaire sans fallback PKCS#11, c'est un piège de lock-in de 10 ans, pas une histoire de modernisation. Le but de l'achat 2026 n'est plus quelle interface standardiser — c'est qui exploite la boîte derrière cette interface, et où la boîte vit physiquement.

La catégorie HSMaaS en 2026

HSM-as-a-Service, ou HSMaaS, n'est plus une catégorie de produit unique. Ce sont au moins quatre modèles de livraison distincts, et les confondre est l'erreur la plus commune sur la première matrice d'achat d'un CISO.

Le premier est l'HSM cloud dédié single-tenant. AWS CloudHSM (basé sur cluster, FIPS 140-3 Level 3, matériel Marvell LiquidSecurity 2, 1,45 $ par HSM-heure en eu-west-1), Azure Dedicated HSM (Thales Luna Network HSM 7, FIPS 140-2 Level 3 à environ 4,85 $ par heure avec migration 140-3 Level 3 suivie jusqu'en 2026), et Google Cloud HSM (basé sur Marvell, FIPS 140-3 Level 3, facturé par version-de-clé et par opération) donnent tous au client un accès exclusif à une partition physique. Le fournisseur racke l'appliance, fournit l'alimentation et le réseau, et le client détient les identifiants de crypto-officer de la partition.

AWS et Google ne peuvent explicitement pas récupérer les clés ; Azure opère de la même manière pour les SKU Dedicated HSM.

Le deuxième modèle est les services de clés managés multi-tenants. AWS KMS, Azure Key Vault Premium et Google Cloud KMS exposent les opérations de clé via une API tandis que les clés restent à l'intérieur de clusters HSM FIPS 140-2 Level 3 (en transition vers 140-3) exploités par le fournisseur et partagés entre clients. C'est le tier le moins cher — fractions de centime par opération — et la bonne réponse pour le chiffrement d'enveloppe au niveau applicatif. C'est la mauvaise réponse pour une racine d'autorité de certification régulée.

Le troisième modèle est l'HSM cloud souverain. Thales Luna Cloud HSM, Atos Trustway DataProtect sur Bull Sequana, Utimaco u.trust 360 hébergé par des opérateurs souverains, et Yubico YubiHSM 2 dans un contrat de colocation managée adressent les juridictions où la résidence des données est une loi dure : SecNumCloud en France, BSI C5 en Allemagne, secteurs NIS2 Annexe I, règles tiers ICT DORA Article 28. Le fournisseur est contractuellement local, le substrat est auditable, et le régime légal n'inclut pas le US CLOUD Act.

Le pricing se situe entre l'HSM cloud dédié et le capex on-prem.

Le quatrième modèle est la garde hybride : les clés racines restent on-prem dans un HSM exploité par le client, les clés émettrices ou subordonnées sont projetées dans un HSM cloud pour la signature élastique, et un protocole d'enveloppement de clé (typiquement PKCS#11 C_WrapKey avec KEK AES-256 ou un wrap padded RFC 5649) déplace le matériel sous contrôle cryptographique. C'est là qu'atterrissent la plupart des CA régulées en 2026 — la racine hors-ligne ne bouge jamais, la CA émettrice en ligne passe à l'échelle horizontalement sur HSM cloud, et la piste d'audit est unifiée.

Dimensions de décision

Un achat HSM 2026 se réduit à six dimensions. Traiter l'une d'elles comme une case à cocher garantit une mauvaise décision, parce que chaque dimension est un arbitrage continu contre les cinq autres.

La latence est le premier filtre. Un nShield Connect XC ou Luna Network HSM 7 on-prem sur un fabric 10 GbE renvoie une signature ECDSA P-256 en 0,8 à 1,4 ms avec l'application à un saut. La même opération contre AWS CloudHSM depuis une instance EC2 dans le même VPC et la même zone de disponibilité tourne en 2 à 4 ms ; à travers les régions, 40 à 90 ms. Azure Key Vault Premium avec des clés protégées par HSM revient typiquement en 8 à 25 ms parce que l'appel traverse un plan de contrôle régional.

Pour un terminator TLS face à 200 000 handshakes par seconde, la différence entre 1 ms et 8 ms est la différence entre deux appliances et vingt. Pour un pipeline de code-signing qui signe un binaire par minute, la latence est sans importance. Mesurez votre profil opérationnel réel avant le diagramme d'architecture.

Le niveau FIPS et la profondeur de certification est le deuxième filtre. FIPS 140-2 Level 3 était acceptable jusqu'en 2025 et reste valide jusqu'à ce que le certificat passe sur la liste historique, mais les nouveaux builds doivent spécifier 140-3 Level 3. Le Level 4 est requis pour certains workloads de défense sous CNSSP-15 et pour un petit nombre de systèmes de règlement de banque centrale. CC EAL4+ avec EN 419 221-5 est obligatoire pour les prestataires de services de confiance qualifiés sous eIDAS 2.0. Les HSM PIN PCI ajoutent PCI PTS HSM v4 sur FIPS.

Si vous exploitez une autorité de certification destinée à la confiance des navigateurs sous les Baseline Requirements du CA/Browser Forum, la cérémonie de génération de clé racine doit avoir lieu dans un équipement 140-3 Level 3 avec une transcription de génération de clé documentée et témoignée.

La garde de clé est la troisième dimension et la plus politique. On-prem, les crypto-officers du client détiennent le seul quorum qui peut exporter, cloner ou détruire une clé — typiquement un ensemble de smartcards m-parmi-n 3-de-5 avec une procédure d'escrow documentée. L'HSM cloud dédié donne au client le même quorum mais l'appliance vit dans le data center de quelqu'un d'autre. Le KMS multi-tenant donne au fournisseur la garde opérationnelle avec séparation cryptographique ; le fournisseur ne peut pas lire la clé, mais le fournisseur peut refuser de vous laisser l'utiliser si une sanction, une assignation ou un différend de facturation survient.

Pour les workloads sensibles à la souveraineté, la garde est la question. Les schémas BYOK et HYOK existent précisément parce que les équipes juridiques ne peuvent pas s'accommoder de la garde côté fournisseur.

Le coût opérationnel est le quatrième. Un Thales Luna Network HSM 7 est listé entre 35 000 $ et 55 000 $ par appliance, avec une paire HA typique de deux nœuds et une troisième unité pour la racine hors-ligne arrivant à 130 000 $ à 180 000 $ en matériel. Le support annuel tourne à 18 à 22 %. Ajoutez le rack, l'alimentation, le refroidissement, deux ETP crypto-officer, les coûts d'audit et un amortissement sur 5 ans, et le coût total de possession atterrit entre 90 000 $ et 140 000 $ par an pour une petite CA.

AWS CloudHSM à 1,45 $/heure pour deux nœuds représente environ 25 400 $/an avant transfert de données et temps opérateur. Le chiffre cloud semble meilleur jusqu'à ce que vous comptiez la réplication inter-régions, les tiers de support premium et le fait que le client a toujours besoin d'un crypto-officer qui comprend la boîte.

Au-delà de 20 millions d'opérations par mois, l'HSM cloud dédié et l'on-prem convergent ; au-delà de 100 millions, l'on-prem est moins cher si l'équipe existe déjà.

La conformité et la résidence des données est la cinquième. Les entités essentielles NIS2 Annexe I doivent démontrer le contrôle opérateur sur le matériel cryptographique. DORA Article 28 fait du fournisseur d'HSM cloud un tiers ICT critique avec déclaration de risque de concentration. Les équipements de création de signature qualifiée eIDAS 2.0 doivent être certifiés EN 419 221-5. Le Cyber Resilience Act de l'UE exige un inventaire d'actifs cryptographiques alimentant le processus PSIRT.

SecNumCloud, BSI C5, ENS High et les catalogues IT-Grundschutz allemands définissent chacun des contraintes géographiques et de nationalité d'opérateur qui disqualifient silencieusement la plupart des offres HSM des hyperscalers en dehors de leurs SKU cloud souverain. Voyez le guide de conformité réglementaire PKI pour la carte d'obligation complète.

La reprise après sinistre et la haute disponibilité est la sixième. La HA on-prem est un problème résolu avec le clustering fournisseur — Luna HA groups, nShield Security World, Utimaco cluster mode — typiquement deux unités de production plus une unité DR dans une zone coupe-feu séparée, avec un test de failover trimestriel documenté.

La HA HSM cloud est le problème du CSP jusqu'à ce qu'elle ne le soit plus : le mode cluster AWS CloudHSM réplique à travers les AZ mais pas à travers les régions sans réplication de clé orchestrée par le client. La DR inter-régions pour CloudHSM nécessite un cluster supplémentaire, un workflow d'export de clé sous une KEK d'enveloppement et un runbook de restauration hors-bande. Les fournisseurs d'HSM cloud souverain offrent typiquement une réplication dual-site dans le pays avec un RPO contractuellement engagé à 0 et un RTO de 15 minutes.

Walkthroughs de scénarios

Les matrices de décision abstraites s'effondrent à la première réunion d'achat. Quatre scénarios concrets couvrent la majeure partie de l'espace de décision 2026.

Scénario A — Banque tier-1 émettant 50 millions de certificats de paiement par an. La banque exploite une EMV-CA et une infrastructure d'émission 3-D Secure avec un débit constant de 1 600 opérations d'émission par seconde culminant à 4 500 pendant les événements de réémission de carte. PCI PTS HSM v4 est obligatoire, FIPS 140-3 Level 3 est obligatoire, et la frontière cryptographique doit supporter à la fois RSA-2048 (EMV hérité) et ML-DSA-65 (planifié pour le refresh EMV 2028).

L'on-prem gagne. Un cluster Thales payShield 10K à quatre nœuds à travers deux data centers, avec une racine hors-ligne documentée dans un coffre de Classe III, coûte environ 1,4 million $ en amont et 280 000 $/an opérationnellement, mais il supprime le risque de concentration CSP sous DORA Article 28 et maintient le flux de traduction de PIN à l'intérieur du périmètre régulé de la banque. L'économie de l'HSM cloud dédié ne fonctionne à cette échelle que si la banque exploite déjà les paiements core dans le cloud, ce que la plupart des titulaires tier-1 ne font pas.

Scénario B — Fabricant IoT signant 200 millions de certificats d'équipement sur 10 ans. Un constructeur automobile ou OEM industriel provisionne des certificats d'équipement IoT au burn-in d'usine. Le débit est en rafales : 80 000 certs/heure pendant une série de production, près de zéro entre les séries. Clés ECDSA P-256, validité de cert de 20 ans, pas de gestion de PIN, pas de mandat réglementaire au-delà du Cyber Resilience Act CRA Article 13 de l'UE.

L'HSM cloud gagne décisivement. AWS CloudHSM ou Azure Dedicated HSM passe à l'échelle de la rafale, ne coûte rien pendant les périodes inactives, et le schéma BYOK permet au client de garder la racine de la CA émettrice on-prem tout en déléguant l'émission subordonnée à de la capacité cloud élastique. Le TCO total sur 10 ans est d'environ 450 000 $ contre 2,1 millions $ pour un déploiement on-prem équivalent avec sept appliances dimensionnées pour le pic.

Scénario C — Entreprise SaaS hébergeant des clés clients. Un SaaS multi-tenant fournissant signature de documents ou chiffrement d'enveloppe doit isoler les clés par client et prouver cette isolation aux achats entreprise. Le KMS managé multi-tenant avec CMK par client couvre la baseline à des fractions de centime par opération. Les clients entreprise qui insistent sur des clés contrôlées par opérateur obtiennent une option HYOK — le SaaS rappelle l'HSM on-prem ou souverain du client pour les opérations à haute sensibilité, acceptant la pénalité de latence en échange de l'isolation légale.

L'architecture se sépare : 95 % du trafic sur KMS multi-tenant, 5 % sur HSM contrôlé par client, modèle de facturation unique, piste d'audit unique. Mélanger les modèles est opérationnellement dur mais commercialement nécessaire parce que les 50 premiers prospects entreprise exigeront HYOK dans leur questionnaire de sécurité.

Scénario D — Gouvernement souverain traitant des données classifiées. Un ministère de la défense ou une agence de renseignement exploitant des certificats de code signing pour des chaînes d'approvisionnement logicielles classifiées, des signatures électroniques qualifiées sous eIDAS 2.0 et le chiffrement de télémétrie d'armement a besoin de FIPS 140-3 Level 4 ou CC EAL5+, de souveraineté juridictionnelle sous SecNumCloud ou BSI C5, et d'une absence complète d'exposition juridique étrangère.

L'on-prem avec Atos Trustway, Utimaco u.trust 360, ou un Thales Luna 7 opéré par souverain dans une installation tempest-rated est la seule réponse crédible. L'HSM cloud souverain via un opérateur local est acceptable pour certains workloads non-classifiés-mais-restreints. L'HSM dédié hyperscaler est disqualifié par juridiction, même lorsque les spécifications techniques seraient autrement suffisantes.

Architectures HSM hybrides

Les architectures intéressantes en 2026 sont hybrides. L'on-prem pur se réduit à la racine hors-ligne et aux workloads de paiement les plus régulés ; le cloud pur se réduit au chiffrement d'enveloppe commodité. Le milieu est où atterrissent la plupart des parcs régulés, et le milieu a quatre schémas nommés.

Split-root est le plus ancien et le plus simple. La clé CA racine vit dans un HSM on-prem hors-ligne et air-gappé, allumé uniquement pour les signatures de cérémonie. Les CA émettrices subordonnées tournent dans un HSM cloud sous leurs propres clés, signées par la racine hors-ligne. L'histoire d'audit est propre : la racine ne touche jamais un réseau, les subordonnées passent à l'échelle élastiquement, et une compromission de la partition HSM cloud force la révocation d'une subordonnée, pas de la racine.

C'est le schéma par défaut pour les nouvelles CA browser-trusted et pour les CA d'entreprise internes opérant sous PCI DSS 4.0.

Bring Your Own Key (BYOK) génère la clé à l'intérieur d'un HSM contrôlé par le client et l'importe dans l'HSM cloud sous une clé d'enveloppement. PKCS#11 C_WrapKey avec une key encryption key AES-256, ou AES Key Wrap RFC 3394/5649, sont les primitifs standard. AWS CloudHSM, Azure Key Vault Premium et Google Cloud HSM publient tous des procédures BYOK utilisant leur propre KEK. Le client conserve la copie maître on-prem, peut re-keyer la copie cloud à la rotation, et peut prouver à un auditeur que la clé a pris naissance sous contrôle client.

Le compromis est qu'une fois la clé à l'intérieur de l'HSM cloud, le fournisseur l'opère — BYOK ne donne pas au client le contrôle opérationnel, seulement le contrôle d'origination.

Hold Your Own Key (HYOK) va plus loin. La clé ne quitte jamais l'HSM client. Le service cloud rappelle l'HSM du client via PKCS#11-sur-réseau protégé par mTLS ou un proxy fournisseur (Thales Luna Cloud HSM Service, Atos Trustway Cloud Connector) pour chaque opération cryptographique. La latence est pire (10 à 40 ms par opération typique), mais le client conserve la garde opérationnelle. HYOK est la bonne réponse pour les données de santé sous HIPAA, les données classifiées sous des programmes nationaux, et les workloads critiques DORA Article 28 où l'équipe juridique n'acceptera pas la garde opérationnelle du fournisseur.

Les pipelines d'enveloppement de clé sont le schéma le plus flexible. Une clé de signature à courte durée de vie est générée dans un HSM cloud pour un lot spécifique (une signature de release, une mise à jour logicielle, une fenêtre de règlement), utilisée, et détruite. L'identité de signature à longue durée de vie vit on-prem et signe une attestation qui délègue l'autorité à la clé cloud pour une fenêtre bornée.

Ce schéma se compose bien avec des modèles de menace de pipeline de build où une clé long terme volée est catastrophique mais une clé de 6 heures volée a un rayon d'impact borné. Sigstore, la signature GitHub basée OIDC et la chaîne d'attestation SLSA Level 3 supposent toutes une variante de ce schéma.

Réalités de migration

La brochure dit que vous pouvez migrer de l'HSM A vers l'HSM B. La réalité est que vous ne pouvez généralement pas, et les projets qui prétendent le contraire se terminent en pannes de 90 jours.

La plupart des fournisseurs d'HSM ne vous laisseront pas exporter le matériel de clé privée en clair — c'est le but de l'équipement. Exporter une clé enveloppée nécessite une clé d'enveloppement partagée entre source et destination, ce qui nécessite soit un fournisseur commun (Thales-vers-Thales via cloning, nShield-vers-nShield via Security World), soit une cérémonie ponctuelle de wrap-import PKCS#11 avec une KEK contrôlée par le client. La migration inter-fournisseurs de clés asymétriques est techniquement possible pour RSA et ECDSA, mais pour ML-DSA et ML-KEM les formats de wrap sont encore spécifiques au fournisseur en 2026 et FIPS 140-3 IG D.G est encore en cours d'interprétation.

Planifiez la réémission, pas la migration.

La réémission signifie générer de nouvelles clés dans l'HSM de destination, émettre de nouveaux certificats pour les nouvelles clés, et faire tourner chaque consommateur vers la nouvelle chaîne. Pour une CA c'est direct mais lent : chaque CA subordonnée, chaque certificat d'entité finale, chaque configuration d'épinglage de clé, chaque client de code-signing et chaque vérificateur Authenticode doit accepter la nouvelle chaîne avant que l'ancienne chaîne n'expire.

L'épinglage est le tueur. HPKP est mort, mais les applis mobiles épinglent des certificats, les trust stores hardcodés dans le firmware IoT épinglent des certificats, les terminaux de paiement épinglent des certificats, et chaque épinglage est une valeur codée en dur qui nécessite un push de firmware pour faire tourner. Une migration cadrée sans énumérer chaque consommateur de chaque clé touchera un épinglage dont elle ignorait l'existence, et la panne se mesurera en jours, pas en minutes.

Les fenêtres de downtime sont l'autre réalité. Pour une racine hors-ligne, la bascule est une cérémonie — huit heures, témoignée, transcrite, faible risque. Pour une CA émettrice en ligne servant un endpoint ACME à 4 000 émissions par minute, la bascule est une période de parallel-run où les anciennes et nouvelles chaînes émettent concurremment pendant 30 à 90 jours, puis un wind-down soigneux de l'ancienne chaîne une fois que les consommateurs ont migré.

Planifiez un minimum de 6 mois de parallel-run pour toute PKI face client, et budgétez pour le fait que 5 à 10 % des consommateurs ne tourneront pas avant la deadline et auront besoin d'une escalade manuelle.

Les implications de chaîne de certificat survivent à la migration. Cross-signer la nouvelle racine depuis l'ancienne racine achète la rétrocompatibilité mais étend la complexité opérationnelle jusqu'à ce que l'ancienne racine expire. Cross-signer l'ancienne racine depuis la nouvelle racine est rarement utile.

Le chasing AIA sous RFC 5280 4.2.2.1 récupérera la plupart des problèmes de chaîne automatiquement pour les clients qui l'implémentent correctement ; les clients qui ne le font pas (chaque équipement embarqué, la moitié des plateformes mobiles) échoueront simplement. Testez la chaîne sur chaque classe de client avant la bascule et documentez le SLO de disponibilité de l'URL AIA à 99,99 % — si AIA tombe pendant la fenêtre de migration, la moitié d'internet cesse de vous faire confiance pendant quelques heures.

Où s'inscrit Evertrust

Les HSM sont la racine de confiance, mais une racine de confiance sans couche d'orchestration n'est qu'une boîte coûteuse. La question 2026 n'est pas seulement où les clés vivent — c'est comment les certificats qui dépendent de ces clés sont émis, renouvelés, révoqués, inventoriés et reportés contre PCI DSS 4.0, NIS2, DORA, eIDAS 2.0 et le Cyber Resilience Act de l'UE.

Evertrust se situe au-dessus de l'HSM, que cet HSM soit on-prem, cloud dédié, cloud souverain ou un mélange hybride, et fournit une surface opérationnelle et d'audit unique à travers tous.

Pour une banque tier-1, cela signifie orchestrer l'émission contre un cluster Thales payShield on-prem tout en alimentant le même inventaire vers le registre de risque de concentration DORA. Pour un fabricant IoT, cela signifie courtier BYOK vers AWS CloudHSM au burn-in d'usine pendant que la racine reste dans un Utimaco u.trust 360 hors-ligne. Pour un SaaS, cela signifie présenter une surface HYOK unifiée aux clients entreprise qui insistent sur des clés contrôlées par opérateur. Pour une agence souveraine, cela signifie une piste d'audit unique à travers un parc Atos Trustway certifié aux standards ANSSI.

Pour voir comment la couche d'orchestration se connecte au substrat cryptographique — HSM on-prem, HSMaaS ou hybride — explorez Evertrust PKI.