Kertakirjautumisen hyödyt ja riskit
This article is based on the previous blog posts written by Kari Laalo.
Kertakirjautuminen eli SSO mahdollistaa useiden sovellusten käytön yhden keskitetyn tunnistautumisen avulla. Käyttäjän ei tarvitse ylläpitää erillistä salasanaa jokaiseen palveluun, ja organisaatio voi toteuttaa tunnistautumisen keskeiset politiikat yhdessä paikassa.
Keskittäminen tuo samalla uudenlaisen riskin. Jos tunnistuspalvelu ei ole käytettävissä, jos sen määritys on virheellinen tai jos käyttäjän keskitetty tunnus vaarantuu, vaikutus voi ulottua moneen sovellukseen. SSO ei siis ole automaattisesti turvallinen tai turvaton. Lopputulos riippuu arkkitehtuurista, tunnistautumismenetelmistä, käyttöoikeuksista, elinkaaren hallinnasta, valvonnasta ja palautumiskyvystä.
Hyvin toteutettuna kertakirjautuminen parantaa sekä käyttökokemusta että tietoturvaa. Huonosti hallittuna se siirtää hajallaan olevat ongelmat keskeiseen palveluun ja kasvattaa yksittäisen virheen vaikutusta.
Lyhyesti: SSO:n tärkeimmät hyödyt ja riskit
Kertakirjautumisen tavoite ei ole poistaa kaikkea tunnistautumisen kitkaa. Arkaluonteinen toiminto voi edelleen vaatia tuoreen tai vahvemman tunnistautumisen. Turvallinen käyttökokemus vähentää turhaa kitkaa ja lisää sitä silloin, kun riski sitä edellyttää.
Kertakirjautumisen hyödyt
Sujuvampi käyttö ja vähemmän keskeytyksiä
Käyttäjän kannalta näkyvin hyöty on kirjautumisten väheneminen. Kun käyttäjällä on voimassa oleva tunnistuspalvelun istunto, sovellus voi hyväksyä tunnistuspalvelun välittämän tuloksen ilman uutta salasanakyselyä.
Tämä helpottaa päivittäistä työtä erityisesti organisaatioissa, joissa käytetään useita selain-, mobiili- ja pilvipalveluja. Uuden työntekijän ei tarvitse opetella jokaiselle sovellukselle erilaista kirjautumistapaa. Myös tuttu kirjautumisnäkymä auttaa käyttäjää tunnistamaan, milloin hän on oikeassa palvelussa.
SSO ei kuitenkaan tarkoita sitä, että käyttäjä ei koskaan tunnistaudu uudelleen. Istunnon vanheneminen, uusi laite, poikkeava riski tai kriittinen toiminto voi edellyttää uutta tai vahvempaa tunnistautumista. Näiden tilanteiden pitää olla ennakoitavia ja käyttäjälle ymmärrettäviä.
Yhdenmukaiset ja vahvemmat tunnistuspolitiikat
Hajautetussa ympäristössä jokainen sovellus voi toteuttaa salasanat, MFA:n, istunnot ja palautumisen eri tavalla. Keskitetty tunnistuspalvelu antaa organisaatiolle mahdollisuuden ottaa hyväksytyt kontrollit käyttöön johdonmukaisemmin.
Keskitetyssä palvelussa voidaan määrittää esimerkiksi:
- mitkä käyttäjät tarvitsevat monivaiheisen tunnistautumisen
- missä palveluissa vaaditaan tietojenkalastelua kestävä menetelmä
- milloin vaaditaan tuore tunnistautuminen tai step-up
- miten uusi tunnistusväline rekisteröidään ja palautetaan
- miten poikkeava laite, sijainti tai käyttäytyminen vaikuttaa päätökseen
- kuinka ylläpitäjien ja tavallisten käyttäjien tunnistautuminen erotetaan.
MFA tarkoittaa kahden tai useamman eri tunnistustekijän käyttämistä. Salasana ja erillinen hallussa oleva tunniste muodostavat tavallisesti kaksivaiheisen tai kaksivaiheiseen todentamiseen perustuvan kokonaisuuden, eivät kolmea tunnistustekijää. Kaikki MFA-menetelmät eivät suojaa tietojenkalastelulta yhtä hyvin. WebAuthniin ja FIDO-tekniikkaan perustuvat menetelmät sitovat tunnistautumisen oikeaan palveluun eivätkä perustu käyttäjän syöttämään kertakäyttökoodiin.
Nopeampi ja hallitumpi sovellusten liittäminen
Kun organisaatiolla on hyväksytty SAML- tai OpenID Connect -integraatiomalli, uutta sovellusta ei tarvitse suunnitella alusta asti. Toistettava liittämisprosessi voi nopeuttaa käyttöönottoa ja parantaa laatua.
Hyvä prosessi määrittää ainakin sovelluksen omistajan, käyttäjäryhmät, riskitason, tunnisteet, attribuutit, vaaditun tunnistautumisen, käyttöoikeuksien lähteen, istunnot, lokituksen, palautumisen ja käytöstäpoiston. Pelkkä tekninen SSO-liitäntä ei ole valmis hallintamalli.
SSO voi myös helpottaa käyttäjän poistumista organisaatiosta. Keskitetyn tunnuksen sulkeminen estää tavallisesti uuden federoidun kirjautumisen. Tämä on merkittävä etu verrattuna tilanteeseen, jossa jokaisella sovelluksella on erillinen salasana.
Etua ei pidä kuitenkaan liioitella. Paikalliset tilit, käyttöoikeudet, sovellusistunnot ja refresh tokenit voivat jäädä voimaan. Provisionointi, deprovisiointi, käyttöoikeustarkastukset ja istuntojen peruminen pitää toteuttaa erikseen esimerkiksi SCIM-protokollan, toimittajan rajapinnan tai muun hallitun prosessin avulla.
Parempi näkyvyys ja nopeampi reagointi
Keskitetty tunnistuspalvelu tuottaa yhdenmukaisia tapahtumia kirjautumisista, epäonnistumisista, MFA-haasteista, laitteista ja poikkeamista. Kun nämä tapahtumat yhdistetään sovellusten, käyttöoikeuksien ja infrastruktuurin lokeihin, organisaatio voi havaita väärinkäytöksiä ja tutkia niitä aiempaa tehokkaammin.
Valvonnassa voidaan seurata esimerkiksi:
- epätavallisia sijainteja, laitteita ja kirjautumisaikoja
- toistuvia epäonnistumisia ja tilien lukkiutumisia
- uuden tunnistusvälineen rekisteröintiä
- ylläpitäjän kirjautumisia ja step-up-tapahtumia
- poikkeavia attribuutti- tai roolimuutoksia
- toimintaa, joka jatkuu tunnuksen sulkemisen jälkeen
- tunnistuspalvelun ja sen riippuvuuksien saatavuutta.
Tunnistusloki ei yksin kerro, mitä käyttäjä teki sovelluksessa. Riittävä audit trail tarvitsee yhteisen korrelaation tunnistuspalvelun, sovelluksen ja käyttöoikeuspäätösten välillä. Lokeihin ei pidä tallentaa salasanoja, yksityisiä avaimia tai tarpeettomia tokenarvoja.
Tietojen minimointi ja yhdenmukaisempi tietosuoja
Federoidussa kirjautumisessa sovellukselle voidaan välittää vain sen käyttötarkoitukseen tarvittavat tiedot. Sovellus voi esimerkiksi tarvita tiedon käyttäjän organisaatiosta tai oikeusryhmästä, mutta ei välttämättä nimeä, sähköpostiosoitetta tai muuta suoraan tunnistavaa tietoa.
Palvelukohtaiset tai parittaiset pseudonyymit tunnisteet voivat vähentää käyttäjän toiminnan yhdisteltävyyttä sovellusten välillä. Pseudonyymi tai opaakki tunniste ei silti ole automaattisesti anonyymi. Se voi olla henkilötieto, jos käyttäjä voidaan tunnistaa suoraan tai muun tiedon avulla.
Keskittäminen helpottaa attribuuttien määrittelyä, hyväksyntää ja poistamista, mutta samalla tunnistuspalvelu näkee laajasti, mihin palveluihin käyttäjät kirjautuvat. Tietojen minimointi, säilytysajat, käyttöoikeudet, läpinäkyvyys ja lokien suojaus pitää siksi suunnitella myös tunnistuspalvelun näkökulmasta.
Kertakirjautumisen riskit
Tunnistuspalvelusta tulee kriittinen riippuvuus
Kertakirjautuminen keskittää monen sovelluksen pääsyn samaan tunnistuspalveluun. Häiriö voi estää uudet kirjautumiset laajasti, vaikka sovellukset itsessään olisivat toimintakunnossa.
Kyse ei aina ole yhdestä palvelimesta tai yhdestä pisteestä. Todellinen riippuvuusketju voi sisältää DNS:n, tietokannat, avainpalvelut, tietoliikenteen, pilvialueen, ulkoisen Identity Providerin, MFA-palvelun sekä ylläpitäjien pääsyn. Kahdennettu sovellus ei auta, jos molemmat instanssit käyttävät samaa rikkoutunutta riippuvuutta.
Riskin pienentäminen edellyttää:
- liiketoimintavaikutukseen perustuvia saatavuus- ja palautumistavoitteita
- korkean saatavuuden arkkitehtuuria ilman tarpeettomia yhteisiä vikapisteitä
- kapasiteetti- ja kuormitustestausta
- riippuvuuksien valvontaa ja hälytyksiä
- varmistuksia ja käytännössä testattua palautumista
- hallittua ylläpitäjän pääsyä häiriön aikana
- rajattuja hätätilejä vain nimetyille kriittisille palveluille.
Hätätilin pitää olla vahvasti suojattu, valvottu ja säännöllisesti testattu. Sen käyttö tarkastetaan jälkikäteen. Laaja rinnakkainen paikallinen kirjautumistapa heikentää keskitetyn mallin hyötyjä ja voi muuttua huomaamatta valvomattomaksi takaoveksi.
Lisäksi organisaatioiden tulisi kartoittaa eri käyttäjäryhmiä ja mahdollisesti ottaa käyttöön useampi kuin yksi todennuksen hallintaympäristö riskianalyysin perusteella. Vaadittu turvallisuustaso riippuu arvioidusta riskitasosta.
Yhden vaarantuneen tunnuksen vaikutus voi olla laaja
Kun yksi tili toimii useissa sovelluksissa, sen kaappaaminen kasvattaa hyökkääjän mahdollista vaikutusaluetta. SSO ei anna käyttäjälle automaattisesti oikeutta kaikkeen, mutta hyökkääjä voi käyttää kaikkia niitä palveluja, joihin tilillä ja sen voimassa olevilla käyttöoikeuksilla on pääsy.
Keskitetyn tunnuksen suojaamisessa tärkeimpiä keinoja ovat:
- tietojenkalastelua kestävä tunnistautuminen, kuten asianmukaisesti toteutettu WebAuthn
- vähimmän oikeuden periaate ja säännölliset käyttöoikeustarkastukset
- erilliset ylläpitoidentiteetit tavallisesta työtilistä
- tuore tai vahvempi tunnistautuminen kriittisiin toimintoihin
- tunnistusvälineen rekisteröinnin ja palautumisen vahva suojaus
- vaarantuneen tilin, laitteen ja istunnon nopea peruminen
- poikkeavan toiminnan valvonta tunnistautumisen jälkeen.
Käyttäjien koulutus auttaa tunnistamaan poikkeavia kirjautumispyyntöjä, mutta sitä ei pidä käyttää ensisijaisena suojauksena. Palvelun teknisen suunnittelun pitää rajoittaa sitä, kuinka helposti käyttäjä voidaan huijata luovuttamaan tunnisteensa.
Virheellinen luottamussuhde voi ohittaa hyvän tunnistautumisen
Vahva käyttäjän tunnistautuminen ei auta, jos sovellus hyväksyy väärän myöntäjän tokenin, jättää allekirjoituksen tarkistamatta tai sallii hallitsemattoman redirect-osoitteen. Federaation turvallisuus riippuu sekä tunnistuspalvelusta että jokaisen sovelluksen validoinnista.
Tyypillisiä hallittavia riskejä ovat:
- väärän issuer- tai audience-arvon hyväksyminen
- puutteellinen allekirjoituksen, nonce-arvon tai tilaparametrin tarkistus
- liian laajat tai dynaamiset redirect-osoitteet
- vanhentuneet, vuotaneet tai kiertämättä jääneet avaimet ja salaisuudet
- suojaamaton metadata- tai discovery-lähde
virheellinen käyttäjätilien yhdistäminen sähköpostiosoitteen perusteella - attribuuttien tai varmuustason erilainen tulkinta eri järjestelmissä.
Hyväksytyt protokollaprofiilit, ylläpidetyt kirjastot, avainten kierto, määritysten tarkastus ja negatiiviset testit pienentävät riskiä. Sovelluksen pitää hylätä virheellinen tai odottamaton vastaus turvallisesti.
SSO ei korjaa liian laajoja käyttöoikeuksia
Tunnistautuminen vastaa kysymykseen siitä, kuka käyttäjä on tai mitä hänestä voidaan todentaa. Autorisointi ratkaisee, mitä käyttäjä saa tehdä. SSO keskittää ensimmäistä, mutta ei automaattisesti jälkimmäistä.
Jos roolit, ryhmät ja paikalliset oikeudet ovat vanhentuneita, keskitetty kirjautuminen voi tehdä niiden käytöstä helpompaa ilman, että oikeudet ovat oikeita. Erityinen riski syntyy, kun käyttäjän tehtävä muuttuu, yhteistyösuhde päättyy tai paikallinen tili jää sovellukseen aktiiviseksi.
Käyttöoikeuksien hallinnassa tarvitaan:
- nimetty omistaja jokaiselle roolille ja oikeudelle
vähimmän oikeuden periaate - hyväksyntä riskin mukaan
- joiner, mover ja leaver -prosessit
- määräaikaisten oikeuksien automaattinen päättyminen
- säännölliset käyttöoikeustarkastukset
- erillinen hallinta ylläpitäjä- ja palvelutileille.
Keskittäminen lisää tietosuoja- ja sisäpiiririskiä
Tunnistuspalvelu tai identiteettivälittäjä käsittelee käyttäjätunnisteita, attribuutteja, laite- ja sijaintitietoja sekä laajaa kirjautumishistoriaa. Tämä tekee siitä kiinnostavan kohteen sekä ulkoiselle hyökkääjälle että oikeuksia väärinkäyttävälle sisäpiiriläiselle.
Tietosuojaa tukevat:
- attribuuttien ja lokitietojen minimointi
- palvelukohtaiset pseudonyymit tunnisteet, kun ne sopivat käyttötarkoitukseen
rajatut ylläpito- ja lukuoikeudet - ylläpitotoimien muuttumaton audit trail
- määritellyt säilytysajat ja poistaminen
- tietovirtojen, käsittelyperusteiden ja osapuolten vastuiden dokumentointi
- säännöllinen tietosuoja- ja riskiarvio.
Toimittajariippuvuus ja osaamisen keskittyminen
SSO-ratkaisu voi sitoa organisaation yhden tuotteen ominaisuuksiin, omiin rajapintoihin tai toimittajan lisenssimalliin. Myös osaaminen voi keskittyä muutamalle henkilölle. Tällöin tuote-, hinta- tai henkilöstömuutos vaikeuttaa jatkuvuutta.
Riskiä voidaan pienentää suosimalla standardeja, dokumentoimalla arkkitehtuuri ja määritykset, automatisoimalla toistettavat tehtävät, ylläpitämällä sovellusrekisteriä ja suunnittelemalla poistumistapa. Standardi ei poista toimittajariippuvuutta kokonaan, mutta se helpottaa integraatioiden ymmärtämistä ja siirtämistä.
Näin SSO:n riskit pidetään hallinnassa
1. Määritä omistajuus ja riskitaso
Nimeä liiketoiminta- ja tekninen omistaja tunnistuspalvelulle, välittäjälle ja jokaiselle liitetylle sovellukselle. Luokittele palvelut sen perusteella, mitä väärä pääsy, häiriö tai tietovuoto aiheuttaisi.
2. Suojaa tunnistuspalvelu tietojenkalastelua kestävällä MFA:lla
Tarjoa tietojenkalastelua kestävä tunnistautumistapa ja vaadi sitä erityisesti ylläpitäjiltä sekä korkean riskin palveluissa. Suojaa myös uuden tunnistusvälineen rekisteröinti, tilin palautuminen ja tukipalvelun tekemät muutokset.
3. Erota tavallinen ja etuoikeutettu käyttö
Älä käytä tavallista työidentiteettiä kaikkiin ylläpitotehtäviin. Rajaa ylläpitoroolit, käytä tarvittaessa määräaikaista korotusta ja vaadi kriittisiin toimintoihin tuore tai vahvempi tunnistautuminen.
4. Suunnittele elinkaari ja istuntojen peruminen
Yhdistä tunnuksen sulkeminen sovellustilien deprovisiointiin, käyttöoikeuksien poistamiseen sekä istuntojen ja tokenien perumiseen. Testaa prosessi todellisissa sovelluksissa, ei vain tunnistuspalvelussa.
5. Rakenna korkea saatavuus ja testaa palautuminen
Tunnista koko riippuvuusketju. Määritä palautumistavoitteet, testaa kuormitus, varmistukset ja katastrofipalautuminen. Pidä rajatut hätätilit toimintakunnossa vain niissä kriittisissä palveluissa, joissa niitä aidosti tarvitaan.
6. Käytä turvallisia integraatiomalleja
Hyväksy SAML- ja OIDC-profiilit, rajaa redirect-osoitteet tarkasti, tarkista issuer, audience, allekirjoitus ja transaktion sidonta. Hallitse avaimet, varmenteet, metadata ja salaisuudet koko elinkaaren ajan.
7. Valvo tunnistautumista ja sovellustoimintaa yhdessä
Yhdistä tunnistuspalvelun, sovelluksen, käyttöoikeuksien ja infrastruktuurin tapahtumat. Määritä hälytykset, korrelaatiotunnisteet, säilytysajat ja poikkeamien käsittely. Harjoittele vaarantuneen tunnuksen ja tunnistuspalvelun häiriön vaste.
8. Tarkasta käyttöoikeudet ja liitännät säännöllisesti
Poista tarpeettomat sovellukset, luottamussuhteet, avaimet, attribuutit ja ylläpito-oikeudet. Varmista, että jokainen tuotantoliitäntä on omistettu, valvottu ja mukana muutoksenhallinnassa.
Milloin SSO on organisaatiolle perusteltu?
Kertakirjautuminen on tavallisesti perusteltu, kun käyttäjillä on useita sovelluksia, organisaatio tarvitsee yhdenmukaisia tunnistautumisvaatimuksia tai käyttäjätilien hajautettu hallinta aiheuttaa selkeää riskiä ja työtä.
Päätöstä voi arvioida seuraavilla kysymyksillä:
- Kuinka monta sovellusta ja käyttäjäryhmää ratkaisu palvelee?
- Mitkä palvelut ovat liiketoimintakriittisiä?
- Mitä tunnistautumisen varmuutta eri palvelut tarvitsevat?
- Tukeeko sovellus turvallista SAML- tai OIDC-liitäntää?
- Miten käyttöoikeudet, tilit, istunnot ja tokenit poistetaan?
- Miten tunnistuspalvelun häiriöstä palaudutaan?
- Mitkä palvelut tarvitsevat rajatun hätäkäytön?
- Miten kirjautumista, käyttöoikeuksia ja sovellustoimintaa valvotaan?
- Kuka omistaa palvelun, integraatiot ja hyväksyttävän jäännösriskin?
- Millä mittareilla hyöty ja turvallisuus osoitetaan?
SSO:n liiketoimintahyötyä ei pidä perustella yleisillä prosenttiluvuilla ilman omaa lähtötietoa. Ennen ja jälkeen käyttöönoton voidaan mitata nollauspyyntöjä, kirjautumisaikaa, sovelluksen liittämiseen kuluvaa aikaa, epäonnistumisia, palautumiskykyä ja tunnistamiseen liittyviä poikkeamia.
Usein kysytyt kysymykset
Onko kertakirjautuminen turvallinen?
Kyllä, kun se suunnitellaan ja ylläpidetään hyvin. SSO voi parantaa turvallisuutta keskittämällä vahvan tunnistautumisen, politiikat ja valvonnan. Samalla se keskittää saatavuus- ja tilikaappausriskiä, joten MFA, vähimmät oikeudet, istuntojen hallinta, valvonta ja palautuminen ovat olennaisia.
Onko yksi tunnus kaikkiin palveluihin liian suuri riski?
Yksi identiteetti voi toimia useissa palveluissa ilman, että käyttäjällä on oikeus kaikkeen. Riskin laajuuden ratkaisevat käyttöoikeudet, tunnistautumisen vahvuus, istunnot ja valvonta. Ylläpitoidentiteetit ja kriittiset oikeudet kannattaa erottaa tavallisesta työtilistä.
Poistaako SSO salasanat?
Ei automaattisesti. SSO vähentää sovelluskohtaisia salasanoja. Keskitetty tunnistautuminen voi edelleen käyttää salasanaa, tai se voidaan toteuttaa salasanattomalla WebAuthn- tai passkey-menetelmällä.
Pitääkö salasanat vaihtaa säännöllisesti?
Ei mielivaltaisen aikataulun perusteella. Nykyinen NIST-ohjeistus kieltää määräaikaisen vaihdon vaatimisen ja edellyttää vaihtoa, kun tunnisteen vaarantumisesta on näyttöä. Salasanojen pituus, vaarantuneiden arvojen esto ja turvallinen palautuminen ovat tärkeämpiä.
Onko MFA:ssa aina kolme tunnistustekijää?
Ei. MFA tarkoittaa vähintään kahta eri tekijäluokkaa. Salasana ja hallussa oleva turva-avain ovat kaksi tekijää. Tietojenkalastelua kestävä MFA on tärkeämpi tavoite kuin vaiheiden lukumäärän kasvattaminen ilman riskiarviota.
Estääkö tunnuksen sulkeminen pääsyn heti kaikkialle?
Ei välttämättä. Se estää tavallisesti uuden federoidun kirjautumisen, mutta olemassa oleva sovellusistunto, refresh token tai paikallinen tunniste voi säilyä. Deprovisiointi ja istuntojen peruminen pitää toteuttaa ja testata erikseen.
Onko SSO sama asia kuin käyttöoikeuksien hallinta?
Ei. SSO todentaa käyttäjän ja välittää sovellukselle tunnistamisen tuloksen. Sovellus tai erillinen käyttöoikeusratkaisu päättää, mitä käyttäjä saa tehdä.
Mitä tapahtuu, jos tunnistuspalvelu ei toimi?
Uudet kirjautumiset voivat estyä useissa sovelluksissa. Olemassa olevat sovellusistunnot voivat jatkua niiden omien sääntöjen mukaan. Organisaatio tarvitsee korkean saatavuuden, testatun palautumisen ja rajatun hätäkäytön suunnitelman kriittisille palveluille.
Yhteenveto
Kertakirjautumisen suurin vahvuus on sama kuin sen keskeinen riski: tunnistautuminen keskitetään. Keskittäminen vähentää sovelluskohtaisia salasanoja, yhdenmukaistaa politiikkoja, parantaa käyttökokemusta ja mahdollistaa paremman näkyvyyden. Samalla tunnistuspalvelusta tulee kriittinen riippuvuus ja vaarantuneen tilin vaikutus voi laajentua.
Turvallinen SSO ei pääty onnistuneeseen kirjautumiseen. Se tarvitsee tietojenkalastelua kestävän tunnistautumisen, hallitut käyttöoikeudet, erilliset ylläpitoidentiteetit, toimivan käyttäjätilien elinkaaren, istuntojen perumisen, turvalliset federaatioliitännät, korkean saatavuuden, valvonnan ja harjoitellun palautumisen.
Kun nämä osa-alueet suunnitellaan kokonaisuutena, SSO voi vähentää sekä käyttäjien kitkaa että organisaation tietoturvariskiä.
Tarvitsetko apua kertakirjautumisen, identiteetinhallinnan tai turvallisten SAML- ja OIDC-liitäntöjen suunnittelussa? Tutustu WeAren identiteetin- ja pääsynhallinnan palveluihin tai ota yhteyttä asiantuntijoihimme.
Kertakirjautumisen artikkelisarja
- Mitä kertakirjautuminen eli SSO tarkoittaa ja miten se toimii?
- SAML 2.0 vs OpenID Connect: SSO-protokollat ja WebAuthnin rooli
- Federoitu kirjautuminen ja SSO-hallintamalli
- Kertakirjautumisen hyödyt ja riskit
Lähteet ja standardit
- Regulation (EU) 2024/1183 (eIDAS 2.0)
- Directive (EU) 2022/2555 (NIS2 Directive)
- Regulation (EU) 2022/2554 (Digital Operational Resilience Act – DORA)
- Payment Services Regulation (PSR)
- Payment Services Directive 3 (PSD3)
- Finnish Act on Strong Electronic Identification and Electronic Trust Services (617/2009)
- CISA, More than a Password
- W3C, Web Authentication: An API for accessing Public Key Credentials, Level 3