IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
MFA enrollment & factors
Maya turns on MFA for her account. It is easy to switch on. It is harder to do well. Your goal: pick a strong factor, enroll it safely and plan for a lost phone.
- MFA means more than one kind of proof.
- Passkeys are strongest. SMS is weakest.
- Removing a factor needs a code to a channel the server chooses.
- Never make recovery depend on the factor you may lose.
Factors from strong to weak
A factor is one kind of proof. It is something you know (a password), have (a phone) or are (a fingerprint). A debit card plus its PIN is two kinds: have and know. MFA asks for more than one kind. Factors do not all resist the same attacks. So we can rank them like rungs on a ladder.
🔑 Passkey
Phishing-resistant. It works only on the real site, so a fake site gets nothing. This is the strongest rung. See passkeys.
📱 Authenticator app or push
An authenticator app shows a code that changes every 30 seconds (TOTP). A push asks you to tap Approve. Both stop attackers who only have your password. But a trick can still work. The user types the code, or taps Approve, for the attacker.
💬 SMS or voice call
The weakest rung. A code can be intercepted. It can also go to an attacker after a SIM swap. Scammers also phone people and ask them to read it out. See Spotting phishing and fake logins. Many bank apps still send SMS codes today. Use SMS as a backup, not the main factor, wherever you can choose.
How in-app enrollment works
Sometimes you add an authenticator inside your own app, with no hosted login page. The app's servers do the steps in the background.
- The backend swaps the session's refresh token for a short-lived MFA token. This token stays in the backend. It never goes to the browser.
- The backend uses that token to ask the enroll endpoint for a secret and a QR code.
- Maya scans the QR code. She types the first code her app shows.
- The backend confirms the factor with that first code.
Getting a spare house key cut. The locksmith needs proof that you already have a working key. In the same way, an app cannot quietly create a new factor behind your back.
Changing factors, and the reset gate
Removing a factor is risky. So is "reset all my MFA" after a lost phone. For these, the system asks for proof of possession. It sends a one-time code to a verified email or phone that the server chooses. So a stolen session alone cannot remove your protection.
If your last sign-in is old, the system first asks for a fresh password sign-in. It never asks for the second factor you may have lost.
The golden rule: never make lost-factor recovery depend on the factor that may be lost. If recovery needs the phone you dropped in the lake, you are locked out. Use a fresh password sign-in plus a code to an independent verified channel. Also give each user a few one-time recovery codes to save. See safe account recovery.
Go deeper: standards and names
The US standard NIST calls the phone network a "restricted" choice for sign-in. That is why SMS is only a backup.
Names like /mfa/associate in the figure come from one popular vendor. The steps are the same elsewhere.
If a safe channel is not possible, use a human support process. Do not wipe factors on weak proof, such as a security question.
🧪 Interactive lab — enable JavaScript to play with this one.
Designing an MFA rollout or recovery policy? Talk to our team.