Stärk din MFA med hårdvarusäkerhetsmoduler (HSM)

Publicerad: maj 2026. Uppdaterad: augusti 2026. Granskad av Encryption Consultings PKI- och HSM-rådgivningsteam.

De flesta MFA-intrång omintetgör inte den andra faktorn i inloggningsögonblicket. De stjäl hemligheten som genererar den. Ett engångslösenordsfrö som finns i en programvarunyckel, en privat nyckel som cachas på en bärbar dators hårddisk eller en certifikatutfärdarnyckel som lagras i en konfigurationsfil är alla extraherbara, och när den väl är extraherad slutar den andra faktorn att vara en andra faktor. Den blir en kopia som en angripare kan spela upp i all oändlighet. En hårdvarusäkerhetsmodul (HSM) stänger den luckan genom att generera och hålla nyckelmaterialet inuti en manipulationssäker gräns som operativsystemet, nätverket och de flesta insiders aldrig kan nå.

Det här inlägget behandlar de specifika sätt som HSM:er stärker flerfaktorsautentisering : skydda FIDO2-, PIV- och smartkortsautentiseringsnycklar; förankra certifikatbaserad autentisering via PKI; distributionstopologin som kopplar samman dem; FIPS-gränserna och efterlevnadsmappningen som reglerade team behöver; hur CA-nycklarna bakom certifikatbaserad autentisering faktiskt föds i en nyckelceremoni; och vad som händer med autentiseringstillgängligheten när själva HSM:n misslyckas. Om din fråga är bredare, hur man utformar eller styr MFA generellt, täcker vår guide till centraliserad MFA klassificering på assurancenivå och styrning av autentiseringsuppgifter på djupet; det här inlägget är specifikt inriktat på HSM:s roll under autentisering.

Vilken roll spelar HSM:er för att stärka MFA?

En HSM stärker MFA på tre sammanhängande sätt: den skyddar de privata nycklarna och frömaterialet bakom hårdvarautentiserare, den förankrar certifikatbaserad autentisering genom att skydda certifikatutfärdarnycklarna (CA) som signerar varje autentiseringsuppgifter, och den tillhandahåller den revisionslogg och FIPS 140-3-validerade gräns som tillsynsmyndigheter och revisorer litar på. Inget av dessa är nya kryptografiska tekniker. Det som förändras är var nyckelmaterialet finns.

En programvarubaserad autentiserare, ett TOTP-frö i en mobilapp, en push-notissigneringsnyckel på en server, ett certifikat lagrat i en Windows-nyckelbutik, måste lita på värden den körs på. Om värden komprometteras kan nyckeln kopieras, och en kopierad MFA-nyckel kan inte skiljas från den riktiga vid autentiseringstillfället. En HSM tar bort detta förtroendeberoende. Nycklar som genereras inuti modulen markeras som icke-exporterbara, kryptografiska operationer sker inom hårdvarugränsen och klartextnyckeln visas aldrig på disk, i minnesdumpar eller i nätverket.

Hur fungerar HSM-baserad certifikatbaserad autentisering (PKI-baserad MFA)?

Certifikatbaserad autentisering använder ett digitalt certifikat och dess matchande privata nyckel som faktorn "något du har": användaren eller enheten presenterar ett certifikat, den förlitande parten (en VPN-gateway, en Windows-domänkontrollant, en SSO-leverantör) validerar certifikatets signaturkedja tillbaka till en betrodd certifikatutfärdare och kontrollerar att den inte har återkallats. Två separata nycklar spelar roll här, och en HSM kan skydda båda.

• Slutenhetens privata nyckel. Detta är nyckeln på användarens smartkort, säkerhetsnyckel eller enhetens säkra element (till exempel en TPM). Den bevisar att användaren innehar autentiseringsuppgifterna och aldrig lämnar hårdvaran.
• CA:s signeringsnyckel. Det här är nyckeln som utfärdade certifikatet från första början. Om den lagras i programvara kan en angripare som komprometterar CA-servern skapa giltiga certifikat för vilken identitet som helst, vilket undergräver alla autentiseringsuppgifter som CA någonsin har utfärdat eller någonsin kommer att utfärda. En HSM-skyddad CA-nyckel eliminerar den enda komprometteringspunkten.

Det här är vad som skiljer HSM-baserad PKI MFA från en programvarubaserad infrastruktur för publika nyckelr: själva förtroendeankaret, inte bara slutanvändarens autentiseringsuppgifter, finns inuti validerad hårdvara. Encryption Consultings CertSecure Manager hanterar arbetsflödet för utfärdande, förnyelse och återkallelse utöver den HSM-skyddade CA:n, så händelser i autentiseringsuppgifternas livscykel förblir automatiserade istället för manuella.

Varför skydda autentiseringsnyckelmaterial i en HSM istället för programvara?

Programvarunyckellagring, ett krypterat nyckellager, en nyckelring, en databaskolumn, skyddar en nyckel mot tillfällig åtkomst, men inte mot en beslutsam angripare som redan har kodkörning på värden. Skadlig kod med tillräcklig behörighet kan läsa processminne, dumpa nyckellagret eller koppla in signeringsanropet. Inget av detta kräver att krypteringen bryts; det kräver bara åtkomst till den maskin där nyckeln finns.

Fast egendom	Programvarulagrad nyckel	HSM-skyddad nyckel
Exporterbarhet	Vanligtvis exporterbar med tillräcklig värdåtkomst	Genererad, ej exporterbar; kan inte lämna hårdvarugränsen
Exponering under användning	Dekrypteras till värdminnet för varje operation	Lämnar aldrig modulen; operationer sker inuti HSM
Insiderrisk	Administratörer med värd- eller säkerhetskopieringsåtkomst kan potentiellt kopiera den	Kvorumkontrollerad åtkomst; ingen enskild administratör kan extrahera den
Sabotagerespons	Ingen; en komprometterad värd ger tyst, oupptäckt åtkomst	Fysisk manipuleringsdetektering kan nollställa nycklar automatiskt
Validering av efterlevnad	Beror på påståenden om härdning av värden	Oberoende validerad enligt FIPS 140-3 av NIST:s kryptografiska modulvalideringsprogram

Det är därför NIST SP 800-63B kräver att hårdvarukryptografiska autentiserare på Authenticator Assurance Level 3 (AAL3) använder manipulationssäker hårdvara med minst FIPS 140 Level 3 fysisk säkerhet, och kräver att nycklar är designade att inte exporteras. Programvaruautentiserare kan nå AAL2 med god implementering, men de kan inte uppfylla AAL3:s hårdvarukrav, eftersom garantin som AAL3 kräver är en egenskap hos den fysiska enheten, inte programvarukonfigurationen.

Hur ser en distributionstopologi för HSM-baserad MFA ut?

En HSM-baserad MFA- och PKI-infrastruktur är byggd i lager, vart och ett med ett distinkt krav på förtroende och tillgänglighet:

1. Offline-root-CA på en HSM med luftgap. Roten signerar endast de utfärdande CA-certifikaten, kopplas sedan bort och lagras säkert. Den tas sällan, om någonsin, online.
2. Online-utfärdande CA som stöds av en klustrad, nätverksansluten HSM. Detta är CA:n som faktiskt signerar dagliga autentiseringscertifikat, så den måste vara mycket tillgänglig, inte bara säker.
3. Registreringsmyndighet och plattform för hantering av behörighetsuppgifter. Hanterar registrerings-, förnyelse- och återkallningsförfrågningar och verkställer identitetsverifiering innan ett certifikat utfärdas.
4. Katalog- och IAM-integration. Active Directory, Entra ID eller motsvarande identitetsarkiv mappar certifikat till användar- eller enhetsidentiteter.
5. Slutpunktsautentiserare. PIV- eller smartkort, FIDO2-säkerhetsnycklar eller TPM-baserade enhetscertifikat, som vart och ett innehåller sin egen icke-exporterbara privata nyckel.
6. Validering av förlitande part. VPN-gateways, SSO-leverantörer och OS-inloggningskomponenter kontrollerar certifikatkedjan och frågar OCSP eller en CRL i realtid innan åtkomst beviljas.

Encryption Consultings PKI Services- team utformar denna hierarki från början till slut, inklusive uppdelningen av offline-rot och utfärdande CA, så att topologin matchar den säkerhetsnivå som organisationen faktiskt behöver snarare än en generisk mall.

Varför spelar FIPS-gränsen roll för reglerade MFA-implementeringar?

FIPS-gränsen är den definierade fysiska och logiska omkretsen av HSM:n, inom vilken nycklar genereras, används och förstörs, och utanför vilken nyckelmaterial i klartext aldrig tillåts förekomma. FIPS 140-3 är den nuvarande NIST-standarden för att validera den gränsen och ersätter FIPS 140-2 under en formell övergång som hanteras av NIST:s Cryptographic Module Validation Program. För reglerade MFA-distributioner är det den gränsen som revisorerna faktiskt kontrollerar:

• PCI DSS 4.0.1. Krav 8.4.2 kräver MFA för all åtkomst till kortinnehavarens datamiljö, inte bara fjärråtkomst, vilket gäller sedan den 31 mars 2025. Det föreskriver inte HSM-baserad autentisering med namn, men det kräver att autentiseringsfaktorer motstår kompromisser, och att hårdvaruskyddade certifikat eller FIDO2-autentiseringsuppgifter är det starkaste sättet att uppfylla den avsikten för administrativ och privilegierad CDE-åtkomst.
• HIPAA. Säkerhetsregeln kräver åtkomstkontroller som är lämpliga för känsligheten hos skyddad hälsoinformation; HSM-baserad autentisering stöder det kravet för system som hanterar PHI, särskilt för privilegierad administrativ åtkomst.
• FIDO. FIDO Alliance-autentiseringscertifiering sträcker sig från nivå 1 till nivå 3+, där de högre nivåerna kräver hårdvarubaserad, manipulationssäker nyckelskydd snarare än enbart programvaruimplementering.

Den praktiska slutsatsen: om ditt MFA-program behöver demonstrera AAL3 eller motsvarande högkvalitativ säkerhet för en revisor, är FIPS 140-3-valideringscertifikatet för HSM:en som skyddar CA:n eller autentiseringsnycklarna den artefakt som avslutar den konversationen.

Hur utfärdar en nyckelceremoni CA-nyckelmaterialet bakom certifikatbaserad autentisering?

Varje certifikat som autentiserar en användare eller enhet spåras tillbaka till ett CA-nyckelpar, och det nyckelparet måste genereras någonstans. För en HSM-baserad PKI genereras den inuti HSM under en formell nyckelceremoni: en skriptad, bevittnad och granskad process där den privata nyckeln skapas inuti hårdvarugränsen och aldrig existerar i klartext utanför den. Kvorumkontroller, vanligtvis ett M-of-N-smartkortschema, innebär att ingen enskild administratör ensam kan komma åt eller exportera nyckeln efteråt.

Detta är särskilt viktigt för UT eftersom ceremonin är det ögonblick då förtroendeankaret för varje certifikatbaserad autentiseringsuppgift nedströms etableras. En svag eller odokumenterad ceremoni, till exempel nycklar som genereras på en arbetsstation och importeras senare, undergräver säkerhetsnivån för varje certifikat som certifikatutfärdaren senare utfärdar, oavsett hur väl dessa individuella autentiseringsuppgifter är skyddade. För en fullständig genomgång av själva ceremoniprocessen, roller, kvorumdesign och dokumentationskrav, se vår guide till HSM-nyckelceremonin.

Hur implementerar man HSM-stödd MFA?

1. Klassificera resurser efter säkerhetsnivå. Kartlägg system till NIST SP 800-63B AAL1 till AAL3 innan du väljer en metod; detta behandlas i detalj i vår centraliserad MFA-guide och bör inte upprepas per projekt.
2. Välj och etablera FIPS 140-3-validerade HSM:er. Välj en dedikerad enhet, en molnbaserad HSM eller en hanterad HSM-som-en-tjänst prenumeration baserad på operativ kapacitet och efterlevnadsomfattning.
3. Utforma CA-hierarkin och genomför nyckelceremonin. Dela upp offline-root- och online-utfärdande CA, och generera CA-nycklar inuti HSM under kvorumkontroll.
4. Distribuera den utfärdande certifikatutfärdaren i ett kluster med hög tillgänglighet. Koppla det till din katalog och IAM-plattform så att certifikatutfärdandet automatiskt mappas till verkliga identiteter.
5. Välj formfaktorn för slutpunktsautentiseraren. PIV- eller smartkort, FIDO2-säkerhetsnycklar eller TPM-baserade certifikat, matchade till varje användarpopulations enheter och arbetsflöde.
6. Integrera en plattform för hantering av autentiseringsuppgifter. Automatisera registrering, förnyelse och återkallelse i stor skala istället för att hantera certifikatlivscykelhändelser manuellt.
7. Anslut förlitande parter. VPN-, SSO-, OS-inloggnings- och VDI-system behöver alla validera certifikatkedjan och kontrollera återkallningsstatus i realtid.
8. Upprätta övervakning och test av redundans innan driftsättning. Bekräfta att HSM-klustret, säkerhetskopiorna och OCSP- eller CRL-svararna beter sig korrekt under simulerade fel, inte bara under normal belastning.

Vilka HA- och säkerhetskopieringsöverväganden skyddar autentiseringstillgängligheten?

MFA-tillgänglighet beror på mer än att identitetsleverantören håller sig aktiv. Om den utfärdande certifikatutfärdarens HSM-nivå eller OCSP- och CRL-svararna som validerar certifikat slutar fungera, kan certifikatbaserade inloggningar misslyckas även om alla andra autentiseringskomponenter är felfria. En enda, icke-klustrad HSM är en enda punkt för autentiseringsfel för varje certifikat som spåras tillbaka till den.

Baslinjen för den utfärdande CA-nivån är minst två HSM:er spridda över två tillgänglighetszoner, med lastbalansering över klustret och automatisk redundansväxling när en medlem förloras. Tillgänglighet och nyckelhållbarhet är dock separata egenskaper: ett synkroniserat kluster skyddar mot att förlora en enhet, men en skadad nyckelimport eller en felaktig administrativ åtgärd kan spridas till varje synkroniserad medlem samtidigt. Oberoende, krypterade säkerhetskopior av CA-nyckelmaterial, som hålls separat från det aktiva klustret och testas regelbundet genom att faktiskt återställa från dem, är det som skyddar mot det scenariot. Vår detaljerade guide till HSM-klusterning och hög tillgänglighet täcker klusterdesign, strategi över flera regioner och redundanstestning i sin helhet; sammanfattningen här är begränsad till vad det specifikt innebär för autentiseringsdrifttid.

Vilka är integrationsförutsättningarna före driftsättning?

Innan ett HSM-stödt MFA-projekt kan påbörjas måste några delar redan vara på plats eller planerade:

• En befintlig IAM- eller katalogtjänst (Active Directory, Entra ID eller LDAP) som certifikatidentiteter kan mappas till.
• Nätverksanslutning mellan applikationer och HSM, vanligtvis via PKCS#11, KMIP eller en leverantörsspecifik klient, med latensbudget för att stödja signeringsåtgärder i realtid.
• En dokumenterad certifikatpolicy och certifieringspraxis (CP/CPS) som definierar hur CA-hierarkin ska fungera och vilken säkerhetsnivå den siktar på.
• En plattform för hantering av autentiseringsuppgifter som kan automatisera utfärdande, förnyelse och återkallelse av autentiseringsuppgifter för den förväntade enheten och användarpopulationen.
• Integrationspunkter, RADIUS, SAML eller OIDC, för de efterföljande applikationerna och VPN- eller SSO-system som kommer att förbruka certifikaten.
• En kvorumbaserad åtkomstkontrollpolicy för HSM- och CA-administration, definierad före nyckelceremonin, inte improviserad under den.
• En loggnings- och övervakningspipeline som samlar in HSM- och CA-händelser för revisionsbevis och avvikelsedetektering.

Vad händer när HSM-systemet misslyckas, och hur kan man mildra det?

Felscenario	Påverkan på autentisering	Mitigation
Enskilt HSM-hårdvarufel	Nya certifikatutfärdande- och signeringsförfrågningar som dirigeras till den enheten misslyckas	Multi-AZ HSM-kluster med automatisk redundansväxling till kvarvarande medlemmar
Nätverkspartition mellan utfärdande CA och HSM	Utfärdandet av nya autentiseringsuppgifter stoppas; redan utfärdade certifikat kan fortfarande valideras via cachade OCSP-svar.	Redundanta nätverksvägar till HSM-klustret; rimliga OCSP-svarscachningsfönster
Förlorad eller skadad CA-privat nyckel utan säkerhetskopiering	Total förlust av förtroendekedjan; varje certifikat som CA utfärdat måste utfärdas på nytt från en ny rot.	Dokumenterad nyckelceremoni med kvorumstyrda, oberoende lagrade nyckelbackuper
Fel på uppdatering av HSM-firmware	Tillfällig förlust av signeringskapacitet på den berörda klustermedlemmen	Stegvisa, löpande uppdateringar över klustermedlemmar med en testad återställningsprocedur
Komprometterade administrativa kvorumuppgifter för HSM	Risk för otillåten certifikatutfärdande under den legitima CA-identiteten	Kvorumkontroll för alla M-av-N-personer, granskningsloggning och aviseringar för alla åtgärder på kvorumnivå

Den gemensamma tråden i varje scenario är att tillgänglighet och integritet är separata fellägen som kräver separata åtgärder. HA-kluster löser avbrottsproblemet. Dokumenterade nyckelceremonier och oberoende säkerhetskopior löser förlustproblemet. Kvorumkontroll och loggning löser insider- och komprometteringsproblemet. En implementering som bara adresserar en av de tre är egentligen inte motståndskraftig.

Autentiseringsmetod, HSM-beroende och säkerhetsnivå jämförd

Autentiseringsmetod	HSM-beroende	Typisk NIST SP 800-63B-säkringsnivå
Endast lösenord	Ingen	Under AAL1 (inte MFA)
SMS eller mjukvaru-TOTP-app	Ingen; hemligheten lagras i programvara	AAL1 till AAL2
Mobil push-godkännande	Valfritt, för signering av backend-tokens	AAL2
FIDO2- eller WebAuthn-programvarulösenord	Ingen; nyckeln lagrad i plattformens nyckelarkiv	AAL2
FIDO2- eller WebAuthn-hårdvarusäkerhetsnyckel	Inbyggt i enhetens säkra element	AAL2 till AAL3
Smartkort eller PIV-certifikat med en programvaruskyddad CA	Svag; CA-nycklar i programvara riskerar att äventyra hela kedjan	Nominellt AAL3, men den faktiska säkerheten beror på CA-nyckelskydd
Smartkort eller PIV-certifikat med en HSM-baserad CA	Krävs; rot- och utfärdande CA-nycklar lagras i en FIPS 140-3-validerad HSM	AAL3, verifierare mot imitation
HSM-baserad certifikatbaserad autentisering (fullständig PKI MFA)	Krävs för CA-nycklar och, där de används, hårdvaruslutpunktsnycklar	AAL3

Begränsningar

• En HSM skyddar nyckelmaterialet bakom en autentiseringsfaktor; den upptäcker inte själv nätfiske, social manipulation eller en användare som godkänner en bedräglig begäran. Certifikatbaserad autentisering är i sig nätfiskeresistent eftersom det inte finns någon delad hemlighet för nätfiske, men den omgivande processen, registrering och återkallelse, behöver fortfarande den styrning som täcks i vår centraliserade MFA-guide.
• HSM-baserad PKI ökar verklig operativ komplexitet: en CA-hierarki, en plattform för hantering av autentiseringsuppgifter och HA-infrastruktur att designa och underhålla. Den passar perfekt för AAL3-åtkomst, inte för alla interna applikationer.
• Den regelmässiga kartläggningen här är en utgångspunkt. Exakta PCI DSS-, HIPAA- eller FIDO-skyldigheter beror på en organisations specifika omfattning och bör bekräftas med en compliance-rådgivare eller en kvalificerad bedömare.

Vad skulle krypteringskonsulter rekommendera?

Börja med den säkerhetsnivå som åtkomsten faktiskt behöver, inte den autentiserare som är lättast att lansera. För privilegierad, administrativ eller CDE-åtkomst under PCI DSS 8.4.2, eller för alla AAL3-system, rekommenderar vi HSM-baserad certifikatbaserad autentisering framför programvaru-MFA, eftersom det tar bort det enda som programvara i felläge inte kan: nyckelutvinning från en komprometterad värd.

• Om du behöver HSM-skydd utan att äga och lagra hårdvara, HSM-som-en-tjänst ger dig FIPS 140-3-validerat nyckelskydd med inbyggd HA och driftskydd.
• Om ni står upp för eller omstrukturerar CA-hierarkin bakom certifikatbaserad MFA, inklusive den viktiga ceremonin som etablerar den, vår PKI-tjänster teamet utformar och genomför processen från början till slut.
• Om utfärdande, förnyelse och återkallelse av behörighetsuppgifter i stor skala är flaskhalsen, CertSecure-hanterare automatiserar certifikatets livscykel så att HSM-baserad autentisering inte blir en manuell börda allt eftersom den växer.

Slutsats

Programvarubaserad MFA höjde ribban enbart för lösenord, men den ärvde värdens förtroendeproblem: vilken nyckel som helst som en komprometterad maskin kan läsa är en nyckel som en angripare så småningom kan kopiera. En HSM tar bort det beroendet för de autentiseringsuppgifter som är viktigast, FIDO2- och PIV-nycklar, smartkortscertifikat och CA-nycklarna som signerar dem alla, genom att generera och hålla dem inom en FIPS 140-3-validerad gräns som aldrig släpper nyckelmaterial i klartext. Att få fördelarna i praktiken kräver mer än att köpa en HSM: det krävs en avsiktlig distributionstopologi, en dokumenterad nyckelceremoni, HA-design som behandlar tillgänglighet och hållbarhet som separata problem, och integrationsförutsättningar som planeras innan projektet startar, inte upptäcks under det.

Om du utvärderar hur HSM-baserad autentisering passar ditt MFA-program, eller om du redan vet att du behöver AAL3-omfattningsbaserad certifikatbaserad autentisering och vill att den ska utformas och driftsättas korrekt första gången, kontakta vårt team.

Vanliga frågor om partihandel med mat och dryck

Behöver jag en HSM för att implementera MFA? Nej. De flesta MFA, SMS-koder, autentiseringsappar och programvarukoder fungerar utan en HSM och når AAL1 till AAL2. En HSM blir nödvändig när du behöver AAL3-försäkran, hårdvarubaserad certifikatautentisering eller bevis på att autentiseringsnyckelmaterial aldrig existerade utanför en validerad hårdvarugräns.

Vad är skillnaden mellan programvarubaserad och HSM-baserad FIDO2-autentisering? En programvarubaserad FIDO2-nyckel lagrar sin privata nyckel i enhetens plattformsnyckellager, skyddat av operativsystemet. En HSM-baserad eller hårdvarubaserad FIDO2-säkerhetsnyckel genererar och lagrar nyckeln i ett dedikerat säkert element som aldrig exponerar den, inte ens för värdoperativsystemet, vilket är det som gör att den kan nå AAL3.

Kräver PCI DSS HSM-baserad MFA? PCI DSS 4.0.1 Krav 8.4.2 kräver MFA för all åtkomst till kortinnehavarens datamiljö, vilket gäller sedan den 31 mars 2025, men det namnger inte HSM:er specifikt. HSM-baserade hårdvaruautentiserare är det starkaste sättet att uppfylla kravets avsikt för privilegierad och administrativ CDE-åtkomst.

Vad händer med autentiseringen om HSM:n går ner? Med en enda, icke-klustrad HSM misslyckas nya certifikatutfärdanden och signeringsåtgärder. Med ett korrekt utformat HSM-kluster med flera AZ fortsätter de överlevande medlemmarna att hantera förfrågningar automatiskt, vilket är anledningen till att HA-designen, inte bara HSM-implementeringen, avgör om autentiseringen förblir tillgänglig under ett fel.

Kan jag lägga till HSM-baserad certifikatautentisering utan att ersätta vår befintliga MFA? Ja. Certifikatbaserad autentisering distribueras vanligtvis tillsammans med befintliga MFA-metoder för användare och system som behöver AAL3-säkring, till exempel administratörer eller CDE-åtkomst, medan åtkomst med lägre risk fortsätter att använda organisationens befintliga centraliserade MFA-metod.

Referensprojekt

• NIST SP 800-63B, Riktlinjer för digital identitet: Autentisering och livscykelhantering: https://pages.nist.gov/800-63-3/sp800-63b.html
• PCI Security Standards Council, PCI DSS v4.0.1, Krav 8.4.2: https://www.pcisecuritystandards.org/document_library/
• NIST, FIPS 140-3 Övergångsinsats, Valideringsprogram för kryptografiska moduler: https://csrc.nist.gov/projects/fips-140-3-transition-effort
• FIDO Alliance, Authenticator-certifieringsnivåer: https://fidoalliance.org/certification/authenticator-certification-levels/
• Entrust, varför använda en HSM för PKI: https://www.entrust.com/use-case/why-use-an-hsm/pki