MFA-tekstiviestin loppu

TLDR

• Microsoft lakkauttaa 1. helmikuuta 2027 oman tekstiviesti- ja puhelusoittopalvelunsa monivaiheiselle todennukselle Entra ID:ssä.
• Global Adminit ja ulkoiset vieraat saavat poikkeuksen 1. heinäkuuta 2027 asti.
• 1. syyskuuta 2026 lähtien Microsoft kehottaa rekisteröintikampanjan puitteissa kyseisiä käyttäjiä ottamaan käyttöön passkeyn.
• Muutos ei koske vain käyttäjiä, jotka aktiivisesti käyttävät tekstiviestiä, vaan myös tilejä, joille tekstiviesti tai puhelu on vielä sallittu tai rekisteröity menetelmänä. Myös palautusprosessit kuten Self-Service Password Reset on tarkistettava.
• Yritysten kannattaa käyttää välttämätön migraatio hyväksi ja siirtyä phishing-kestäviin menetelmiin sekä vähentää jäljelle jäävää salasanojen tarvetta järjestelmällisesti.

Lähde: https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement

Syyskuun 1. päivästä 2026 lähtien Microsoft on aktivoinut tenanteissa rekisteröintikampanjan, joka kehottaa kaikkia käyttäjiä, joille tekstiviesti- tai puhelu-MFA on avattu, ottamaan seuraavalla kirjautumiskerralla käyttöön passkeyn. Käyttäjä voi toistaiseksi ohittaa tämän.
Automaattinen rekisteröintikampanja ja passkey-aktivointi ja ovat tilapäisesti vältettävissä. Microsoftin oman tekstiviesti- ja puhelusoittopalvelun lakkautuspäivään se ei vaikuta.

Helmikuun 1. päivänä 2027 Microsoftin oma tekstiviesti- ja puhelusoittopalvelu päättyy tavallisilta käyttäjiltä ilman mahdollisuutta opt-outiin. Käyttäjätilit, joille on käytettävissä yksinomaan tekstiviesti tai puhelu lisätodennusmenetelmänä, tarvitsevat ennen määräpäivää vaihtoehtoisen menetelmän. Muuten kyseiset käyttäjät eivät pysty saattamaan onnistuneesti loppuun kirjautumisia, jotka vaativat vahvaa todennusta.

Heinäkuun 1. päivänä 2027 myös Microsoftin tekstiviesti/puhelu kytketään pois Global Administratorseilta ja ulkoisilta vierailta.

Vaihtoehtoina tulevat kyseeseen erityisesti passkeyt, Windows Hello for Business, FIDO2-turva-avaimet ja käyttöskenaariosta riippuen muut soveltuvat menetelmät. Microsoft Authenticator Number Matchingin kanssa nostaa suojaa tekstiviestiin verrattuna, mutta ei itse ole phishing-kestävä.

Se, jonka on säilytettävä tekstiviesti regulatorisista tai operatiivisista syistä, voi tehdä sen jatkossakin Microsoft Security Storesta löytyvän teleoperaattorin kautta. Kyseessä on silloin oma sopimuksensa ja laskutuksen on määrä tapahtua viestikohtaisesti. Tarjoajat tulevat näkyviin 18. syyskuuta alkaen, konfiguroitavissa ne ovat 30. lokakuuta alkaen. Microsoft ei siis vastedes aja palvelua itse, vaan jättää sen ulkoisille tarjoajille.

Yksityiskohta, joka usein jää huomaamatta: kyse ei ole siitä, kuka käyttää tekstiviestiä, vaan siitä, kenelle se on avattu. Se, joka on vuosia käyttänyt Authenticator-sovellusta mutta jolla on vielä puhelinnumero varalla tallennettuna, on aivan yhtä lailla mukana kuin henkilöt, jotka ovat tähän asti säännöllisesti odotelleet tekstikoodia. Useimmissa tenanteissa tämä on historiallisista syistä selvä enemmistö. Ja vielä yksi asia on tärkeä: lakkautus ei koske vain kirjautumista. Muutos koskee myös Self-Service Password Resetiä: tekstiviesti ja puhelu eivät ole siihen enää käytettävissä Microsoftin omana vahvistusmenetelmänä. Organisaatioiden on siksi tarkistettava, mitkä vaihtoehtoiset menetelmät on varattu salasanan nollaukseen ja tilin palautukseen.

Miksi Microsoft tekee näin

Tämän päätöksen voi lukea holhoamisena. Sen voi lukea myös sinä, mitä se on: myöntönä siitä, että tekstiviesti ei enää tarjoa riittävää suojaa nykyaikaisia reaaliaikaisia phishing- ja SIM-swap-hyökkäyksiä vastaan.

Tyypillinen hyökkäys Microsoft 365 -tiliin ei enää tänään koostu salasanan arvaamisesta. Sen sijaan käyttäjä päätyy kirjautumissivulle, joka näyttää erehdyttävästi aidolta, ja syöttää sinne käyttäjätietonsa ja MFA-koodin. Hyökkääjä käyttää molempia reaaliajassa kirjautumiseen ja saa istuntotokenin, jolla hän ottaa käyttäjän identiteetin haltuunsa. Tällaisia työkaluja tarjotaan jo skaalautuvina hyökkäyspalveluina darknetissä. Automaatio ja tekoäly laskevat lisäksi uskottavien phishing-kampanjoiden vaivaa.

Phishing-kestävät menetelmät kuten passkeyt käyttävät toisenlaista tapaa. Passkey on kiinteästi sidottu siihen verkko-osoitteeseen, jota varten se on luotu, eikä sitä voi käyttää väärennetyllä verkkosivustolla. Myös hienostuneet hyökkäykset, joissa huijarit välittävät kirjautumisen huomaamatta aidolle sivulle, menevät tyhjään: selain tunnistaa, ettei se ole oikeassa osoitteessa, eikä tarjoa passkeytä lainkaan. Vaikka vastaus saavuttaisi aidon palvelun, siinä lukisi väärentämättömästi väärä osoite, ja palvelu hylkäisi sen. Tarkistus ei siis ole enää ihmisellä vaan tekniikalla, kryptografian varmistamana. Käyttäjien ei enää tarvitse itse tunnistaa, onko verkkosivusto aito. Tämä erottaa passkeyt salasanoista ja klassisesta kaksivaiheisesta kirjautumisesta. Windows Hello for Business, FIDO2-turva-avaimet ja Microsoft Authenticatorin passkeyt käyttävät vastaavia phishing-kestäviä periaatteita. Käytön ja käyttäjäohjauksen kannalta ne eivät kuitenkaan ole identtisiä: laitesidonnaisuus, synkronointi, palautus ja tuetut alustat eroavat toisistaan ja ne on arvioitava personakohtaisesti. Tekniikka on ollut olemassa jo vuosia. Uutta on se, että Microsoft tekee siitä nyt standardin.

Pankit ovat muuten kulkeneet tämän tien jo muutama vuosi sitten. Tekstiviesti-TANin, pitkään yleisimmän hyväksyntämenetelmän verkkopankissa, useimmat laitokset ovat poistaneet vapaaehtoisesti ja korvanneet laite- tai tapahtumasidonnaisilla menetelmillä kuten pushTAN, photoTAN ja chipTAN. Tekninen toteutus eroaa, mutta tavoite on samankaltainen: hyväksynnät halutaan sitoa vahvemmin rekisteröityyn laitteeseen ja konkreettiseen tapahtumaan. Syyt muistuttavat tämän päivän syitä: SIM-swapping, siepatut viestit ja reaaliaikainen phishing.

NIS2:n, DORAn tai ISO 27001:n piirissä oleville organisaatioille käy yhä vaikeammaksi perustella heikkoja todennusmenetelmiä asianmukaisiksi. Phishing-kestävät menetelmät vahvistavat siksi paitsi teknistä turvallisuutta myös näyttökykyä johdon, sisäisen tarkastuksen ja valvonnan suuntaan.

Voiko salasanan poistaa kokonaan?

Se, joka muutoksen yhteydessä joka tapauksessa inventoi todennusmenetelmiä, tiedottaa käyttäjille ja ottaa käyttöön uusia kirjautumistapoja, kannattaa samalla tarkistaa, missä salasanoja vielä todella tarvitaan. Passkey voi tuetuissa sovelluksissa korvata salasanan ja toisen tekijän. Yhdistettynä Windows Hello for Businessiin kannettavalla ja Microsoft Authenticatorin passkeyhin salasanaton kirjautuminen tavanomaisiin Microsoft-palveluihin on mahdollista, ja sopivalla konfiguraatiolla myös pääsy paikallisiin Active Directory -resursseihin.

Myös uusien työntekijöiden käyttöönoton voi järjestää vastaavasti. Alkusalasanan sijaan voidaan käyttää ajallisesti rajattua Temporary Access Passia, jonka Entra ID tunnustaa täysimittaiseksi MFA- ja kirjautumismenetelmäksi. Sillä tehdään ensimmäinen kirjautuminen Autopilotilla toimitetulle laitteelle. Sen jälkeen otetaan käyttöön Windows Hello ja passkey. Temporary Access Passin vanhennuttua tavanomaiseen kirjautumiseen ei enää tarvita salasanaa.

Tavoitetilassa työntekijöiden ei tarvitse tavallisessa työarjessa tuntea salasanaansa eikä syöttää sitä. Siten phishing-riskit ja salasanan nollausten tarve laskevat selvästi.

Missä se käytännössä takkuaa

glueckkanja saattaa tällaisia muutoksia säännöllisesti maaliin. Vaikeudet ovat harvoin teknologiassa. Ne ovat toteutuksen yksityiskohdissa.

Aktivoitu ei ole pakotettu. Pelkkä passkeyden avaaminen ei varmista, että niitä käytetään jokaisessa relevantissa kirjautumisessa. Myös ”System-preferred MFA” vain priorisoi vahvimman käytettävissä olevan menetelmän, mutta ei pakota sitovaa pääsyvaatimusta. Jos resurssin pitää olla tavoitettavissa yksinomaan phishing-kestävällä todennuksella, se on pakotettava sopivalla Authentication Strengthillä Conditional Accessissa. Muuten tarjolla voi edelleen olla heikompia fallback-menetelmiä. Passkey olisi silloin vain ”koristetta”.

Realistinen eteneminen noudattaa neljää askelta:

1. Inventaario. Kenelle tekstiviesti ja puhelu on avattu? Kenellä on puhelinnumero rekisteröitynä, ja kuka on viimeksi tosiasiassa käyttänyt sitä? Onko tenant migroitu uuteen todennusmenetelmäpolitiikkaan? Mitä vierailijakäyttäjiä on olemassa, onko heillä omat tenantit?
2. Persona-päätös. Mikä passkey-profiili (device-bound vai synced) sopii mihinkin käyttäjäryhmään, ja mitkä Conditional Access -politiikat Authentication Strengthin kanssa pakottavat sen sitovasti? Miten toimitaan shared devicejen ja ulkoisten käyttäjien kanssa? Mitä tekevät työntekijät, joilla ei ole älypuhelinta? Halutaanko kumppaniyrityksiin vierailijakäyttäjineen luottaa MFA:n osalta?
3. Pilotti ja kampanja. Ensin muutosta kokeillaan pilottiryhmällä. Sen jälkeen seuraa rekisteröintikampanja saatteineen ja rajattuine lykkäyksineen. Käyttäjien hyvä valmistelu vähentää lisäkysymyksiä ja välttää ylimääräistä kuormaa servicedeskille. Poikkeukset tarvitsevat päättymispäivän ennen 1.2.27.
4. Lakkautus. Vasta rekisteröintikampanjan päätyttyä puhelinnumerot poistetaan MFA-menetelmänä ja tekstiviesti otetaan pois käytöstä politiikassa. Lakkautus tehdään tietoisesti ennen Microsoftin määräpäivää, jotta voidaan varmistaa, ettei yksikään käyttäjä enää ole asian piirissä.

Erityispiirre koskee B2B-vieraita: ulkoisille käyttäjille pätevät toisenlaiset rekisteröinti- ja luottamusmallit kuin sisäisille tileille. Tarkistakaa, voidaanko MFA vakiinnuttaa kotitenantista Cross-Tenant Access Settingsien kautta ja mikä vaihtoehto on varattu vieraille, joilla ei ole omaa Entra-tenanttia. 19. syyskuuta 2026 tilanteen mukaan Microsoft aikoo tuoda passkey-tuen sisäisille vierailijakäyttäjille lokakuuhun mennessä. Yleisempi ulkoisten vieraiden (B2B) tapaus saa passkey-tuen myöhemmin ja päivämäärä ilmoitetaan vielä. Oletettavasti hieman lisäajan saamiseksi tekstiviestin ja puhelun saatavuutta ulkoisille vieraille pidennettiin heinäkuuhun 2027.

Siihen asti on varattava soveltuvat siirtymämenetelmät tai luottamuspohjaiset cross-tenant-skenaariot.

Mitä passkeyt eivät ratkaise: phishing-kestävä kirjautuminen suojaa todennustapahtuman, ei automaattisesti jokaista jo olemassa olevaa istuntoa. Haittaohjelmat, kompromentoidut selaimet tai varastetut istuntotokenit pysyvät relevantteina riskeinä. Siksi Authentication Strength, laitteiden vaatimustenmukaisuus, päätelaitesuojaus, riskipohjaiset pääsypäätökset ja soveltuvat istuntokontrollit tulisi suunnitella yhdessä. Näin riskiä voidaan pienentää ja, mikäli laitteiden vaatimustenmukaisuutta vaaditaan sitovasti, rajata pääsy vastaavasti hallinnoituihin laitteisiin.

Miten me lähestymme tätä

glueckkanjalla tarkastelemme identiteettiä ja päätelaitetta yhtenä yhteisenä kontrollijärjestelmänä. Todennusmenetelmien politiikat, passkey-profiilit, Authentication Strengthit, Conditional Access ja Intune määritellään jäljitettävästi, versioidaan ja rullataan automatisoidusti ulos Infrastructure as Coden (IaC) periaatteiden mukaan. Näin tavoitetila ja poikkeamat voidaan dokumentoida sekä muutokset osoittaa versioituina. Se luo kestävän pohjan käytölle, johtamiselle ja audiiteille ilman että tilaa pitäisi rekonstruoida käsin portaaleista.

Tämä toimintatapa on osa palveluitamme Managed Entra ja Managed Intune. Ne yhdistävät tekniset blueprintit, jatkuvan mukauttamisen ja jäljitettävän konfiguraation.

Lopputulema

Tekstiviestin loppu ei tässä katsannossa ole harmi vaan tervetullut sysäys. Se pakottaa inventaarioon, joka oli jo pitkään myöhässä. Ja se avaa oven identiteettiin, jossa heikointa lenkkiä ei enää esiinny: salasanaa ihmisen päässä.

Jos haluatte tietää, missä teidän tenanttinne tänään on, voimme mielellämme tehdä teille ensimmäisen assessmentin. Ottakaa yhteyttä!