Passkeys are in use in your Microsoft Tenant, here's how to set policy effectively.
(suomeksi alla)
In our previous article we explained the concept that separates the two families of passkeys: key custody. Synced passkeys replicate through consumer cloud accounts. Device-bound passkeys live in hardware and cannot be copied out. This spring, that distinction became a practical matter for every organization with passkeys enabled in Microsoft Entra ID. This article covers what changed, what the standards require, and how to build a policy that fits your risk.
What changed in your tenant this spring
In early March 2026, Microsoft began rolling out passkey profiles in Entra ID, a new group-based way of managing FIDO2 authentication. From April onward, tenants with Passkeys (FIDO2) enabled that had not opted in were migrated automatically.
The migration added a passkeyType property that separates device-bound passkeys from synced ones, and mapped every migrated tenant's old FIDO2 settings onto it with a single rule. Tenants that enforced attestation were set to allow device-bound passkeys only. Tenants that did not enforce attestation now allow both types.
The second case is the one to pay attention to. A setting many administrators configured years ago, or never consciously configured at all, now decides whether corporate credentials can replicate into employees' personal iCloud and Google accounts. If your registration campaign is Microsoft-managed, it may already be prompting users to enroll whichever passkey types your inherited profile allows.
The new architecture does bring a real improvement. Profiles allow different rules for different groups, for example attested hardware keys for admins and more permissive settings for frontline staff, instead of one tenant-wide policy. But the migration defaults were chosen for the average tenant, and your risk profile is probably not average. The rest of this article is about choosing your settings deliberately.
Attestation: the only way to know what holds your keys
During a normal login, synced and device-bound passkeys behave identically. The difference appears at registration, and it comes down to attestation.
A device-bound authenticator can present an attestation statement when it registers: cryptographic proof, chained back to the manufacturer, of exactly what hardware generated the credential. The relying party validates that chain against the FIDO Alliance Metadata Service and knows with certainty that this is a genuine security key of model X, certified to level Y, holding a private key that cannot be exported.
Synced passkeys cannot offer this. A sync service cannot guarantee anything about every device a key may eventually end up on, so consumer passkey providers attest nothing. This is why Entra's behavior is binary: if a profile enforces attestation, synced passkeys are automatically excluded from it.
There is a further consequence here that many deployments miss. Every authenticator reports an AAGUID, a 128-bit make-and-model identifier, and organizations commonly build allow-lists on it ("YubiKey 5 series only"). The AAGUID, however, is self-reported. Without attestation enforcement, an attacker who reaches a registration flow can enroll a credential that falsely claims to be approved hardware, gaining durable access that looks compliant in every report. An AAGUID allow-list without attestation labels your inventory. It does not secure it.
What the standards require
This assurance gap is written into the standards, not just vendor opinion.
NIST's finalized SP 800-63-4 Digital Identity Guidelines (2025) recognize both passkey families, but set a ceiling. Synced passkeys can satisfy AAL2, the assurance level appropriate for general workforce access. AAL3, the level expected for privileged and high-impact access, requires a phishing-resistant authenticator with a non-exportable private key. A synced passkey is exportable by definition, because replication is its entire purpose. Only hardware-backed, device-bound credentials qualify.
European organizations should apply the same logic to NIS2's strong-authentication expectations and DORA's requirements for financial entities. Regulators are moving from asking whether you deploy MFA to asking what assurance you can demonstrate about it. A policy that enforces attested, device-bound authenticators for privileged access is something you can demonstrate. Passkeys on unknown devices in personal cloud accounts is not.
How attackers get around passkeys
The cryptography of FIDO2 has held, so attack research in 2025 and 2026 moved to the seams around it. The findings should shape your configuration.
In August 2025, Proofpoint demonstrated a downgrade attack against FIDO authentication in Entra ID. A standard adversary-in-the-middle kit (Evilginx) ran a custom phishlet that spoofed a browser without FIDO support, Safari on Windows. Because the login flow believed the user could not use a passkey, it offered a fallback instead: an SMS code or push approval, both phishable, both captured by the proxy. The passkey itself was never attacked. The attacker simply steered the user onto a weaker method.
Months earlier, the PoisonSeed campaign abused the cross-device QR-code sign-in flow at scale, luring victims into scanning attacker-supplied QR codes and approving fresh authentications. Both Microsoft and Okta published hardening guidance in response.
The lesson is simple: your authentication is only as strong as the weakest method a user can be pushed into. Passkeys with SMS fallback enabled are not phishing-resistant for the user who is being phished right now. The same applies to account recovery. If your helpdesk re-enrolls credentials after one convincing phone call, that is a downgrade path too, just one that runs through a person instead of a login page.
Building a deliberate policy
Audit what the migration did. Check which profile your tenant landed in, whether attestation is enforced, which passkey types users have registered since April, and what your registration campaign is now promoting.
Tier your users. For privileged and high-impact access (admins, finance approvers, production access, anyone NIS2 or DORA would call critical), require attested, device-bound passkeys on certified hardware keys. Enforcing attestation makes your AAGUID allow-list verifiable and excludes synced credentials automatically. For the general workforce, make the call consciously: synced passkeys are still phishing-resistant and far better than what they replace, but the custody trade-off should be accepted knowingly. Keep in mind that modern attacks often target finance, HR, and procurement before admins. Many organizations will conclude that hardware keys are cheap compared to the gap.
Close the side doors. Remove SMS and voice fallbacks entirely. Restrict or monitor cross-device QR flows. Enforce passkey sign-in for sensitive resources through Conditional Access authentication strengths, so a downgrade attempt has nowhere to land.
Hold recovery to the same standard as registration. Whatever process enrolls a credential, recovery must be no weaker. Otherwise recovery becomes the easiest way in, and your recovery process, not your login policy, defines your real level of assurance.
The bottom line
The question is no longer whether to adopt passkeys. The question is key custody: does the private key live in certified hardware you control and can crypto-graphically prove, or in a consumer cloud account you cannot see? For most users and most logins, synced passkeys are a clear step forward. For the accounts that can move money, change infrastructure, or appear in a regulator's incident report, the answer has not changed. The key belongs in hardware, the hardware should prove itself at registration, and there should be no weaker path around it.
Spear Innovations helps European organizations deploy phishing-resistant, hardware-backed authentication that meets NIS2, DORA, and AAL3-grade requirements, including tiered passkey policy design for Microsoft Entra ID. Talk to us.
Passkeyt ovat nyt käytössä Microsoft palvelimellasi, näin otat ne käyttöön hallitusti
Edellisessä artikkelissamme selitimme, mikä on passkeyden kahden pääryhmän keskeinen ero: avainten säilytys. Synkronoidut passkeyt kopioidaan käyttäjien pilvipalvelutilien kautta. Laitteeseen sidotut passkeyt sijaitsevat laitteistossa, eikä niitä voi kopioida. Tänä keväänä tästä erosta tuli käytännön kysymys kaikille organisaatioille, joissa passkeyt on otettu käyttöön Microsoft Entra ID:ssä. Tässä artikkelissa käsitellään, mitä on muuttunut, mitä standardit edellyttävät ja miten laaditaan riskeihisi sopiva käytäntö.
Mitä muutoksia Microsoft tenantissa tapahtui tänä keväänä
Maaliskuun 2026 alussa Microsoft alkoi ottaa käyttöön Entra ID:ssä passkey-profiileja, jotka ovat uusi ryhmäpohjainen tapa hallita FIDO2-todennusta. Huhtikuusta lähtien ne tenantit, joilla passkeys (FIDO2) oli käytössä mutta jotka eivät olleet ottaneet ominaisuutta käyttöön itse, siirrettiin automaattisesti uuden mallin piiriin.
Siirron yhteydessä lisättiin passkeyType-ominaisuus, joka erottaa laitteeseen sidotut passkeyt synkronoiduista passkeystä, ja jokaisen siirretyn tenantin vanhat FIDO2-asetukset määritettiin siihen yhden säännön avulla. Tenantit, jotka vaativat varmennusta, asetettiin sallimaan vain laitteeseen sidotut passkeyt. Tenantit, jotka eivät vaatineet varmennusta, sallivat nyt molemmat tyypit.
Toinen tapaus on se, johon kannattaa kiinnittää huomiota. Asetus, jonka monet järjestelmänvalvojat määrittivät vuosia sitten tai jota he eivät ole koskaan tietoisesti määrittäneet, päättää nyt siitä, voidaanko yrityksen tunnistetiedot synkronoida työntekijöiden henkilökohtaisiin iCloud- ja Google-tileihin. Jos rekisteröintikampanjasi on Microsoftin hallinnoima, se saattaa jo kehottaa käyttäjiä rekisteröitymään niillä passkey-tyypeillä, jotka peritty profiilisi sallii.
Uusi arkkitehtuuri tuo mukanaan todellisen parannuksen. Profiilien avulla voidaan määrittää eri sääntöjä eri ryhmille, esimerkiksi varmennetut laitteistokoodit järjestelmänvalvojille ja sallivammat asetukset asiakaspalveluhenkilöstölle, sen sijaan että käytettäisiin yhtä koko tenanttia koskevaa käytäntöä. Siirtymän oletusasetukset on kuitenkin valittu keskimääräistä tenanttia silmällä pitäen, eikä riskiprofiilisi todennäköisesti ole keskimääräinen. Tämän artikkelin loppuosa käsittelee asetusten harkittua valintaa.
Varmennus: ainoa tapa selvittää, missä avaimesi ovat
Tavallisessa kirjautumisessa synkronoidut ja laitteeseen sidotut passkeyt toimivat täsmälleen samalla tavalla. Ero tulee esiin rekisteröitymisen yhteydessä, ja se liittyy varmennukseen.
Laitteeseen sidottu todennusväline voi esittää rekisteröityessään todistuslausunnon: kryptografisen todisteen, joka on ketjutettu takaisin valmistajaan ja joka osoittaa tarkalleen, mikä laitteisto on luonut tunnistetiedot. Luottava osapuoli tarkistaa tämän ketjun FIDO Alliance Metadata Service -palvelun avulla ja saa varmuuden siitä, että kyseessä on aito malli X:n turva-avain, joka on sertifioitu tasolle Y, ja joka sisältää yksityisavaimen, jota ei voi viedä laitteesta.
Synkronoidut passkeyt eivät voi tarjota tätä. Synkronointipalvelu ei voi taata mitään koskien kaikkia laitteita, joille avain saattaa lopulta päätyä, joten kuluttajille suunnattujen passkeyden tarjoajat eivät anna minkäänlaista todistusta. Tästä syystä Entran toiminta on binääristä: jos profiili vaatii todistusta, synkronoidut passkeyt suljetaan automaattisesti sen ulkopuolelle.
Tähän liittyy vielä yksi seuraus, jota monissa käyttöönotoissa ei huomioida. Jokainen todennuslaite ilmoittaa AAGUID-tunnuksen, joka on 128-bittinen valmistaja- ja mallitunniste, ja organisaatiot laativat sen perusteella yleisesti sallittujen laitteiden luetteloita (”vain YubiKey 5 -sarja”). AAGUID on kuitenkin laitteen itse ilmoittama. Ilman todentamisen pakollisuutta hyökkääjä, joka pääsee rekisteröintiprosessiin, voi rekisteröidä tunnistetiedot, jotka väittävät virheellisesti olevansa hyväksyttyä laitteistoa, ja saada siten pysyvän pääsyn, joka näyttää sääntöjenmukaiselta jokaisessa raportissa. AAGUID-sallittujen laitteiden luettelo ilman todentamista merkitsee laitteistosi. Se ei suojaa sitä.
Mitä standardit edellyttävät
Tämä varmuuden puute on kirjattu standardeihin, eikä kyse ole pelkästään toimittajan mielipiteestä.
NIST:n lopullisissa SP 800-63-4 -ohjeissa digitaalisesta identiteetistä (2025) tunnustetaan molemmat passkeyt, mutta niille on asetettu yläraja. Synkronoidut passkeyt voivat täyttää AAL2-tason vaatimukset, joka on sopiva yleisen henkilöstön pääsyn varmuustaso. AAL3-taso, jota edellytetään etuoikeutetulta ja merkittäviltä pääsyoikeuksilta, vaatii kalastelunkestävän todennusvälineen, jonka yksityistä avainta ei voi viedä järjestelmän ulkopuolelle. Synkronoitu passkey on määritelmänsä mukaan vietävissä, koska sen koko tarkoitus on kopiointi. Ainoastaan laitteistopohjaiset, laitteeseen sidotut tunnistetiedot täyttävät vaatimukset.
Eurooppalaisten organisaatioiden tulisi soveltaa samaa ajattelutapaa NIS2:n vahvan todennuksen vaatimuksiin ja DORA:n rahoitusalan toimijoille asettamiin vaatimuksiin. Sääntelyviranomaiset ovat siirtymässä pois kysymyksestä “onko MFA käytössä?” kohti kysymystä “mitä näyttöä voitte esittää sen luotettavuudesta?”. Käytäntö, joka pakottaa käyttämään varmennettuja, laitteeseen sidottuja tunnistautumismenetelmiä korkean käyttöoikeustason käyttäjille, on jotain, jonka toimivuudesta voidaan esittää todennettavaa näyttöä. Sen sijaan tuntemattomilla laitteilla käytettävät passkeyt henkilökohtaisiin pilvitileihin liitettyinä eivät täytä samaa vaatimustasoa.
Miten hyökkääjät kiertävät passkeyt
FIDO2:n salaus on osoittautunut kestäväksi, joten vuosina 2025 ja 2026 hyökkäystutkimus keskittyi sen ympärillä oleviin heikkouksiin. Tutkimustulosten tulisi ohjata konfiguraatiotasi.
Elokuussa 2025 Proofpoint esitteli hyökkäyksen, jossa Entra ID:n FIDO-todennus heikennettiin vähemmän turvalliseen menetelmään. Tavallinen adversary-in-the-middle -työkalu (Evilginx) käytti mukautettua phishlet-komponenttia, joka tekeytyi FIDO-tukea vailla olevaksi selaimeksi, eli Windowsin Safariksi. Koska kirjautumisprosessi uskoi käyttäjän olevan kykenemätön käyttämään passkeyta, se tarjosi sen sijaan vaihtoehtoista tunnistautumistapaa: tekstiviestikoodia tai push-hyväksyntää. Molemmat menetelmät olivat alttiita tietojenkalastelulla, ja jotka välityspalvelin pystyi kaappaamaan ne. Itse passkeyta ei koskaan murrettu. Sen sijaan hyökkääjä ohjasi käyttäjän käyttämään heikompaa tunnistautumismenetelmää.
Kuukausia aiemmin PoisonSeed-kampanja hyödynsi laajamittaisesti laitteiden välistä QR-koodilla tapahtuvaa kirjautumisprosessia houkuttelemalla uhreja skannaamaan hyökkääjän toimittamia QR-koodeja ja hyväksymään uusia todennuksia. Sekä Microsoft että Okta julkaisivat vastauksena turvallisuuden vahvistamista koskevia ohjeita.
Opetus on yksinkertainen: tunnistautumisesi on vain niin vahva kuin heikoin menetelmä, johon käyttäjä voidaan ohjata. Passkeyt, joiden rinnalla on käytössä tekstiviestivarmennus varamenetelmänä, eivät ole tietojenkalastelun kestäviä sille käyttäjälle, jota kalastellaan juuri sillä hetkellä. Sama pätee myös tilin palautusprosesseihin. Jos helpdesk ottaa tunnistetiedot uudelleen käyttöön yhden vakuuttavan puhelun perusteella, kyseessä on yhtä lailla turvallisuuden heikentämiseen johtava vaihtoehtoinen reitti. Erona on vain se, että tässä tapauksessa hyökkäys kulkee ihmisen kautta kirjautumissivun sijaan.
Tarkoituksellisen käytännön rakentaminen
Tarkista, mitä siirto on saanut aikaan. Selvitä, mihin profiiliin tenantti on sijoitettu, onko todentamista vaadittu, minkä tyyppisiä passkey-avaimia käyttäjät ovat rekisteröineet huhtikuun jälkeen ja mitä rekisteröintikampanjasi tällä hetkellä suosittelee käyttäjille.
Ryhmittele käyttäjäsi. Korkean vaikutuksen ja etuoikeutetun pääsyn käyttäjiltä (ylläpitäjät, taloushyväksyjät, tuotantoympäristöjen käyttäjät sekä henkilöt, joita NIS2 tai DORA pitää kriittisinä) tulisi vaatia varmennettuja, laitteeseen sidottuja passkey-avaimia sertifioiduissa laitteistotunnisteissa (hardware keys). Varmennoinnin pakottaminen mahdollistaa AAGUID-sallittujen laitteiden luettelon luotettavan todentamisen ja sulkee automaattisesti pois synkronoidut tunnistetiedot. Muiden työntekijöiden osalta päätös kannattaa tehdä tietoisesti: synkronoidut passkeyt ovat edelleen tietojenkalastelun kestäviä ja huomattavasti turvallisempia kuin useimmat korvaamansa menetelmät, mutta niiden hallintaan liittyvät kompromissit tulee hyväksyä tietoisesti. On myös syytä muistaa, että nykyaikaiset hyökkäykset kohdistuvat usein taloushallintoon, henkilöstöhallintoon ja hankintatoimeen ennen ylläpitäjiä. Moni organisaatio päätyy siihen, että laitteistoavainten kustannus on pieni verrattuna niiden tarjoamaan lisäturvaan..
Sulje sivuportit. Poista tekstiviesti- ja puhelupohjaiset varamenetelmät kokonaan. Rajoita tai valvo laitteiden välisiä QR-koodipohjaisia kirjautumisprosesseja. Vaadi passkey-kirjautuminen arkaluonteisiin resursseihin käyttämällä Conditional Accessin autentikointivahvuuksia, jotta turvallisuustason heikentämiseen tähtäävillä hyökkäyksillä ei ole vaihtoehtoista reittiä onnistua.
Pidä tilin palautusprosessi yhtä vahvana kuin rekisteröinti. Millä tahansa prosessilla tunnistetieto voidaan ottaa käyttöön, palautusprosessin on oltava vähintään yhtä turvallinen. Muussa tapauksessa tilin palautuksesta tulee helpoin tapa päästä järjestelmään, jolloin todellisen luottamustason määrittää palautusprosessi eikä kirjautumiskäytäntösi.
Yhteenveto
Kysymys ei ole enää siitä, otetaanko passkeyt käyttöön. Kysymys koskee avaimen hallintaa: sijaitseeko yksityinen avain sertifioidussa laitteistossa, jota hallitset ja jonka aitouden voit todistaa kryptografisesti, vai kuluttajille tarkoitetussa pilvipalvelutilissä, johon et pääse käsiksi? Useimmille käyttäjille ja useimmissa kirjautumistilanteissa synkronoidut passkeyt ovat selvä askel eteenpäin. Niiden tilien osalta, joilla voidaan siirtää rahaa, muuttaa infrastruktuuria tai jotka voivat näkyä sääntelyviranomaisen poikkeamaraportissa, vastaus on edelleen sama. Avain kuuluu laitteistoon, laitteiston on todistettava luotettavuutensa rekisteröinnin yhteydessä, eikä sen ohittamiseen saa olla heikompia vaihtoehtoja.
Spear Innovations auttaa eurooppalaisia organisaatioita ottamaan käyttöön kalastelunkestävän, laitteistopohjaisen todennuksen, joka täyttää NIS2-, DORA- ja AAL3-tason vaatimukset, mukaan lukien Microsoft Entra ID:n porrastetun passkey-käytännön suunnittelu. Ota meihin yhteyttä.