{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://atlas.maintz.dev/)"},"id":"security/mfa","url":{"en":"https://atlas.maintz.dev/en/terms/security/mfa/","da":"https://atlas.maintz.dev/da/terms/security/mfa/"},"term":{"en":"Multi-factor authentication","da":"Multifaktorgodkendelse"},"aka":{"en":["MFA"],"da":["MFA","multifaktorautentificering"]},"domain":["security"],"cluster":"controls","layer":"identity","status":"current","era":2011,"summary":{"en":"A way to log in that asks for two or more separate kinds of proof, such as a password plus a code or an approval in a phone app.","da":"Et login, der kræver to eller flere forskellige slags bevis, fx en adgangskode plus en kode eller en godkendelse i en app."},"body":{"formal":{"en":"An authentication method that grants access only after the user presents at least two factors from different categories - something they know, something they have, or something they are.","da":"En autentificeringsmetode, der kun giver adgang, når brugeren fremviser mindst to faktorer fra forskellige kategorier - noget man ved, noget man har, eller noget man er."},"plain":{"en":"Like a safe-deposit box that needs both your key and your signature - a thief who copies one still cannot open it.","da":"Som en bankboks, der kræver både din nøgle og din underskrift - en tyv, der kopierer den ene, kan stadig ikke åbne den."},"inPractice":{"en":"A finance clerk in a municipality logs in to the payment system with MitID; she types her user ID, then approves the request in the MitID app on her phone, which she unlocks with her PIN.","da":"En bogholder i en kommune logger ind i betalingssystemet med MitID; hun taster sit bruger-ID og godkender derefter i MitID-appen på sin telefon, som hun låser op med sin pinkode."},"whyItMatters":{"en":"Passwords are stolen and guessed every day; asking for a second, different proof makes a stolen password worth far less to an attacker.","da":"Adgangskoder bliver stjålet og gættet hver dag; et ekstra, anderledes bevis gør en stjålet adgangskode langt mindre værd for en angriber."}},"deepDive":{"en":"NIST SP 800-63B (revision 4, finalised in 2025) grades authentication by Authenticator Assurance Level. AAL1 permits a single factor; AAL2 requires two distinct factors and, in revision 4, obliges verifiers to offer at least one phishing-resistant option; AAL3 requires a phishing-resistant cryptographic authenticator with a non-exportable private key, which excludes syncable passkeys. OTP over SMS or voice (PSTN out-of-band) is a \"restricted\" authenticator whose use requires the verifier to assess the risk and offer an alternative. US federal policy (OMB M-22-09, 2022) went further and required phishing-resistant MFA for agency staff. In EU law, NIS2 Art. 21(2)(j) lists MFA or continuous authentication among the risk-management measures, and the Danish NIS2 law that took effect on 1 July 2025 carries that requirement into national law.\n\n\"Phishing-resistant\" has a precise technical meaning: the authenticator output must be bound to the verifier's identity so it cannot be replayed to a different site. NIST recognises two mechanisms, verifier-name binding and channel binding. WebAuthn/FIDO2 implements the former: the browser writes the actual origin into clientDataJSON, the authenticator includes a hash of the relying-party ID in authenticatorData, and the signature covers both plus a server challenge, so a response produced on a look-alike domain is useless to the real site. Smart-card client authentication in mutual TLS provides channel binding. OTPs, push approvals and SMS codes carry no such binding, which is why adversary-in-the-middle (AiTM) toolkits such as Evilginx can relay them in real time.\n\nPush-based MFA added its own failure mode, MFA fatigue or prompt bombing, used in the 2022 Uber breach: the attacker holding the password triggers repeated prompts until the user approves one. Number matching (the user types a number shown on the login page into the app), displayed location and application context, and rate limits on prompts are now standard mitigations; Microsoft made number matching mandatory in Authenticator in 2023.\n\nMFA protects the authentication event, not the session that follows. AiTM kits capture not only the password and code but the resulting session cookie or OAuth refresh token, which then works without any further factor; defences include short token lifetimes, conditional access tied to compliant devices, and emerging token-binding approaches such as Device Bound Session Credentials. Other bypass paths are weaker fallback methods left enabled, help-desk resets performed on a phone call, legacy protocols (IMAP, POP, basic authentication) that never prompt for a second factor, and service accounts exempted from policy. An MFA programme is therefore assessed on coverage of all interactive and remote access paths, the strength of the weakest enabled method, and the rigour of enrolment and recovery - not on whether MFA is \"turned on\".","da":"NIST SP 800-63B (revision 4, færdiggjort i 2025) graduerer autentificering efter Authenticator Assurance Level. AAL1 tillader én faktor; AAL2 kræver to forskellige faktorer og forpligter i revision 4 verifikatoren til at tilbyde mindst én phishing-resistent mulighed; AAL3 kræver en phishing-resistent kryptografisk autentifikator med en ikke-eksporterbar privat nøgle, hvilket udelukker synkroniserbare passkeys. Engangskoder via sms eller opkald (PSTN out-of-band) er en \"restricted\" autentifikator, hvor verifikatoren skal vurdere risikoen og tilbyde et alternativ. Amerikansk føderal politik (OMB M-22-09, 2022) gik videre og krævede phishing-resistent MFA for myndighedernes ansatte. I EU-retten nævner NIS2 art. 21, stk. 2, litra j, MFA eller kontinuerlig autentificering blandt risikostyringsforanstaltningerne, og den danske NIS2-lov, der trådte i kraft 1. juli 2025, fører kravet ind i dansk ret.\n\n\"Phishing-resistent\" har en præcis teknisk betydning: autentifikatorens svar skal være bundet til verifikatorens identitet, så det ikke kan genbruges mod et andet site. NIST anerkender to mekanismer, verifier-name binding og channel binding. WebAuthn/FIDO2 implementerer den første: browseren skriver den faktiske origin ind i clientDataJSON, autentifikatoren medtager et hash af relying party-ID'et i authenticatorData, og signaturen dækker begge plus en challenge fra serveren, så et svar dannet på et look-alike-domæne er værdiløst for det rigtige site. Klientautentificering med chipkort i gensidig TLS giver channel binding. Engangskoder, push-godkendelser og sms-koder har ingen sådan binding, og derfor kan adversary-in-the-middle-værktøjer (AiTM) som Evilginx videresende dem i realtid.\n\nPush-baseret MFA gav sin egen fejltype, MFA-træthed eller prompt bombing, som blev brugt ved Uber-bruddet i 2022: angriberen, der har adgangskoden, udløser gentagne anmodninger, til brugeren godkender én. Number matching (brugeren taster et tal fra loginsiden ind i appen), visning af placering og applikation samt begrænsning af antallet af anmodninger er nu standardmodtræk; Microsoft gjorde number matching obligatorisk i Authenticator i 2023.\n\nMFA beskytter selve login-hændelsen, ikke den session, der følger. AiTM-værktøjer opsnapper ikke kun adgangskode og kode, men også den resulterende sessionscookie eller OAuth refresh token, som derefter virker uden yderligere faktor; forsvaret omfatter korte token-levetider, betinget adgang knyttet til compliant enheder og nye token binding-tilgange som Device Bound Session Credentials. Andre omgåelsesveje er svagere reservemetoder, der stadig er slået til, nulstillinger foretaget af servicedesken over telefonen, ældre protokoller (IMAP, POP, basic authentication), der aldrig beder om en anden faktor, og servicekonti, der er undtaget fra politikken. Et MFA-program vurderes derfor på dækningen af alle interaktive adgangsveje og fjernadgange, styrken af den svageste aktiverede metode og grundigheden af tilmelding og gendannelse - ikke på, om MFA er \"slået til\"."},"howTo":{"steps":{"en":["Map every way to log in to the organisation, including webmail, VPN, remote desktop, cloud admin portals and legacy protocols such as IMAP and POP.","Decide which methods are allowed, preferring phishing-resistant ones such as passkeys, FIDO2 security keys or certificate-based login, and allow SMS codes only as a documented exception.","Require MFA first for administrators, remote access and email, then extend it to all users and all applications through a conditional access policy or equivalent.","Block legacy authentication protocols that cannot ask for a second factor, and remove fallback methods that are weaker than your chosen standard.","Turn on number matching and show the application and location in push prompts, so users can spot and reject logins they did not start.","Secure enrolment and recovery by verifying identity in person or with MitID before a factor is issued or reset, and never reset MFA on the strength of a phone call alone.","Create two emergency access accounts with strong credentials stored offline, keep every exclusion from the MFA policy documented and minimal, and alert whenever an excluded account signs in.","Review MFA coverage and exceptions from the sign-in logs every quarter, and move the remaining users step by step to phishing-resistant methods."],"da":["Kortlæg alle måder at logge ind i organisationen på, herunder webmail, VPN, fjernskrivebord, administrationsportaler i skyen og ældre protokoller som IMAP og POP.","Beslut, hvilke metoder der er tilladt, og foretræk phishing-resistente som passkeys, FIDO2-sikkerhedsnøgler eller certifikatbaseret login; tillad kun sms-koder som dokumenteret undtagelse.","Kræv MFA først for administratorer, fjernadgang og e-mail, og udvid derefter til alle brugere og alle applikationer via en politik for betinget adgang eller tilsvarende.","Bloker ældre autentificeringsprotokoller, der ikke kan bede om en ekstra faktor, og fjern reservemetoder, der er svagere end jeres valgte standard.","Slå number matching til, og vis applikation og placering i push-anmodninger, så brugerne kan opdage og afvise login, de ikke selv har startet.","Sikr tilmelding og gendannelse ved at kontrollere identiteten personligt eller med MitID, før en faktor udstedes eller nulstilles, og nulstil aldrig MFA alene på grundlag af et telefonopkald.","Opret to nødadgangskonti med stærke loginoplysninger opbevaret offline, hold alle undtagelser fra MFA-politikken dokumenterede og få, og alarmér, når en undtaget konto logger ind.","Gennemgå MFA-dækning og undtagelser i loginloggene hvert kvartal, og flyt de resterende brugere trin for trin over på phishing-resistente metoder."]},"pitfalls":{"en":["Calling MFA done when it is switched on for the portal while VPN, legacy protocols or service accounts still accept a password alone.","Relying on push approvals or SMS codes for administrators, although adversary-in-the-middle phishing kits can relay them in real time.","Letting the service desk reset a user's second factor after a phone call, which gives attackers an easy way around MFA."],"da":["At erklære MFA for færdig, fordi det er slået til på portalen, mens VPN, ældre protokoller eller servicekonti stadig accepterer en adgangskode alene.","At lade administratorer bruge push-godkendelser eller sms-koder, selv om adversary-in-the-middle-phishingværktøjer kan videresende dem i realtid.","At lade servicedesken nulstille en brugers ekstra faktor efter et telefonopkald, hvilket giver angribere en nem vej uden om MFA."]},"guides":[{"title":"NIST SP 800-63B-4 - Digital Identity Guidelines, Authentication and Authenticator Management","url":"https://csrc.nist.gov/pubs/sp/800/63/b/4/final","publisher":"NIST","tier":"standard"},{"title":"Multi-factor authentication for your corporate online services","url":"https://www.ncsc.gov.uk/guidance/multi-factor-authentication-online-services","publisher":"NCSC UK","tier":"official-doc"},{"title":"Require MFA for all users with Conditional Access - Microsoft Entra ID","url":"https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-all-users-mfa-strength","publisher":"Microsoft","tier":"official-doc"},{"title":"Lav stærke adgangskoder og brug to-faktor login","url":"https://www.sikkerdigital.dk/virksomhed/syv-raad-om-it-sikkerhed/6-lav-staerke-adgangskoder-og-brug-to-faktor-login","publisher":"Styrelsen for Samfundssikkerhed","tier":"official-doc","lang":"da"}]},"edges":[{"type":"requires","to":"cs/credential","confidence":"high","strength":"normal"},{"type":"requires","to":"security/authentication-factor","confidence":"high","strength":"normal"},{"type":"kind-of","to":"security/control","confidence":"high","strength":"normal"},{"type":"implements","to":"cs/authentication","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/phishing","why":{"en":"Even if phishing captures a password, the extra factor in most cases still stops the attacker from logging in.","da":"Selv hvis phishing opsnapper en adgangskode, forhindrer den ekstra faktor i de fleste tilfælde angriberen i at logge ind."},"confidence":"high","strength":"primary"},{"type":"mitigates","to":"security/credential-stuffing","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/single-sign-on","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/zero-trust","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/privileged-account","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/passkey","confidence":"high","strength":"normal"},{"type":"used-with","to":"cs/privileged-access-management","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/one-time-password","confidence":"high","strength":"normal"}],"depth":4,"sources":[{"title":"Cyber Security Fast Track - Ordliste","tier":"course-material"},{"title":"NIST SP 800-63B - Digital Identity Guidelines, Authentication","tier":"standard","publisher":"NIST"},{"title":"NIST SP 800-63B-4 - Digital Identity Guidelines, Authentication and Authenticator Management","url":"https://pages.nist.gov/800-63-4/sp800-63b.html","tier":"standard","publisher":"NIST"}],"draft":true}