Multi factor authentication can protect an account even when its password is stolen.
In this lesson you will practise choosing an appropriate additional authentication method, enabling it carefully, protecting recovery options and testing the setup before you depend on it.
Goal: enable multi factor authentication on an important account and make sure both normal sign in and account recovery are understood.
Before you start
Read Multi Factor Authentication: What It Does and Why It Helps.
You should understand that different authentication methods provide different levels of protection.
You will need access to an account that supports additional authentication.
Choose an important account first
You do not need to change every account at once.
Begin with an account whose loss could affect many other parts of your digital life.
Good priorities include:
- your primary email account
- your password manager
- financial accounts
- cloud storage
- important work accounts
- social accounts
Email is especially important because many services use it for password resets and recovery.
Step 1: Open the real account directly
Do not enable authentication through a link in an unexpected message.
Open the service using:
- its official application
- a trusted bookmark
- the website address you normally use
Sign in normally.
Step 2: Find the security settings
Look for a section with a name such as:
- Security
- Sign in and security
- Authentication
- Two step verification
- Two factor authentication
- Multi factor authentication
The exact name varies between services.
Step 3: Review the available methods before choosing one
A service may offer several options.
Examples include:
- a security key
- a passkey or another FIDO based credential
- an authenticator application with number matching
- an authenticator application that generates temporary codes
- a trusted device approval
- a text message code
- an email code
Do not automatically choose the first option shown.
Prefer phishing resistant authentication when practical
Security keys and properly implemented FIDO based credentials can provide strong protection against ordinary credential phishing.
They are designed so that an authentication credential for one service cannot simply be entered into a fake site and reused against the real service.
If an important account supports a phishing resistant method that works with your devices and recovery plan, consider using it.
If phishing resistant authentication is not available
Use the strongest practical option the service provides.
An authenticator application is commonly available.
Number matching can provide better protection against accidental approval than a simple push notification.
Temporary authenticator codes are also useful additional protection, although manually entered codes can still be stolen by phishing.
Text message codes are better than password only protection
Some services provide text message verification as their main additional option.
This can improve security compared with relying only on a password.
However, text messages are generally weaker than stronger authentication methods because they can be affected by phishing, phone account attacks and interception risks.
If a stronger method becomes available later, consider moving to it.
Step 4: Prepare the authentication device
If you will use a phone, tablet or other device for authentication, check that it is protected.
The device should have:
- a secure device lock
- current software updates
- automatic locking
- access controlled by you
Do not register an untrusted public device as your authentication device.
Step 5: Begin the official setup process
Select the authentication method you want to register.
Follow the service provider's instructions exactly.
Depending on the method, the service might ask you to:
- scan a QR code
- connect or tap a security key
- approve registration on a trusted device
- enter a temporary code
- create a passkey
Be careful with QR codes used for authenticator setup
An authenticator setup QR code may contain information that allows an authenticator to generate valid future codes.
Treat it as sensitive.
Do not:
- send it through messages
- post a screenshot of it
- scan one from an untrusted website
- save unnecessary screenshots of it
Scan it only while you are using the real account's official setup page.
Step 6: Complete the verification test
Most services ask you to prove that the newly registered method works.
This may require a code, device approval or security key interaction.
Complete the test before leaving the setup page.
Do not assume that registration succeeded until the account confirms it.
Step 7: Save the recovery method safely
Many services provide backup or recovery codes when additional authentication is enabled.
These codes can be extremely important if you lose your normal authentication device.
They can also be sensitive because someone holding a valid recovery code may be able to gain account access.
Follow the service provider's instructions for storing them securely.
Do not keep your only recovery method on the device it is meant to replace
Imagine that your phone is both:
- your normal authenticator
- the only place where your recovery code is stored
If the phone is lost, both methods may disappear together.
Keep an appropriate independent recovery method when the service supports one.
Step 8: Review registered authentication methods
After setup, look at the account's list of authentication methods.
Confirm that you recognize each one.
Check for:
- your current phone
- security keys
- passkeys
- backup methods
- trusted devices
Remove an unknown method using the provider's official security process.
Do not remove your old method too early during migration
If you are moving authentication from one phone to another, first confirm that the new method works.
A safe sequence is:
- register the new device
- complete a test authentication
- confirm that recovery still works
- only then remove an obsolete device when appropriate
Step 9: Sign out and perform a real sign in test
After configuration, test the complete login process.
Use the real service.
Confirm that:
- your normal account credential is accepted
- the additional authentication request appears
- the request reaches the correct device or authenticator
- you can complete it successfully
- the account opens normally
Testing immediately is much safer than discovering a setup problem during an emergency.
Step 10: Learn what a normal authentication request looks like
Pay attention to how the genuine service presents authentication.
You may see:
- the service name
- the approximate location
- the device requesting access
- a number to match
- a security key prompt
Understanding the normal process makes unexpected requests easier to recognize.
Never approve a request you did not start
If an approval request appears while you are not signing in, deny it.
Do not approve it to stop repeated notifications.
An unexpected request may mean that someone already knows your password or is trying to access the account.
If unexpected requests continue
Use the provider's official account security process.
Depending on the situation, appropriate actions may include:
- denying every unexpected request
- checking recent account activity
- changing the password if it may be compromised
- signing out unknown sessions
- reviewing registered authentication methods
- contacting the provider through its official support channel
Number matching
Some authentication applications display a number on the login screen and require you to match it on your authentication device.
This helps connect the approval to the login you actually started.
Read the prompt rather than approving automatically.
Temporary authenticator codes
An authenticator application may create a short code that changes regularly.
Enter the code only into the real service that you intentionally opened.
Do not tell the code to someone who contacts you by phone, email, message or social media.
A verification code is not customer support information
A criminal may claim:
I need the code that just arrived so I can secure your account.
Do not provide it.
The code exists to authenticate a login, not to prove your identity to an unexpected caller.
Security keys
A physical security key can provide strong phishing resistant authentication when the service supports the appropriate standard.
During registration:
- use the real account security page
- follow the provider's instructions
- give the key a clear name if the service allows it
- understand what happens if the key is lost
Consider a backup authenticator for important accounts
Some services allow more than one security key or authentication device.
For a particularly important account, a separately protected backup can reduce the risk of being locked out if the primary authenticator is lost.
Use only backup methods supported by the service and keep them secure.
Passkeys
Some services support passkeys.
A passkey can provide strong phishing resistant authentication and may remove the need to enter a traditional password for that service.
The passkey may be stored on a trusted device or synchronized through a supported credential provider.
Follow the service and device provider instructions for setup and recovery.
Understand where your passkey is stored
Before relying on a passkey, understand:
- which device or provider stores it
- whether it synchronizes to other trusted devices
- how you regain access after replacing a device
- what account protects the synchronized credential system
Do not weaken the password because MFA is enabled
If the account still uses a password, keep it strong and unique.
Additional authentication is another layer of protection.
It is not a reason to reuse a weak password.
Review account recovery information
While you are in the security settings, check:
- recovery email addresses
- recovery telephone numbers
- backup authentication methods
- trusted devices
- recovery codes
Remove or update information that you no longer control.
Your recovery path should be protected too
Strong authentication can be undermined by a weak recovery route.
For example, if the account can be reset through an old email address that another person controls, the strong normal login method may not be enough.
Keep recovery information current and private.
Practice activity 1: Choose the stronger practical method
An account offers these methods:
- text message code
- authenticator application with temporary codes
- FIDO security key
Which provides the strongest phishing resistance?
Suggested answer
The properly implemented FIDO security key provides the strongest phishing resistance of those options.
Practice activity 2: Unexpected approval
Your phone displays a login approval request, but you are not signing in.
What should you do?
Suggested answer
Deny the request.
Then review the account using the provider's official security tools because someone may be attempting to sign in.
Practice activity 3: Lost phone planning
Imagine your phone disappears today.
Ask:
- Which accounts depend on that phone?
- Do you have approved recovery codes?
- Is another authenticator registered?
- Can you securely recover the phone's device account?
- Do you know how to remove the lost device from important accounts?
If the answers are unclear, improve your recovery plan before an emergency happens.
Practice activity 4: Spot the unsafe setup
A learner enables authentication and stores the only recovery code as a screenshot on the same phone used as the authenticator.
What is the problem?
Suggested answer
Losing that one phone could remove both the normal authentication method and the only recovery copy at the same time.
MFA setup checklist
Before considering the setup complete, check:
- I opened the real service directly.
- I reviewed the available authentication methods.
- I chose the strongest practical method I can maintain safely.
- I registered it using the provider's official process.
- I completed the setup verification.
- I protected recovery information.
- I tested a real sign in.
- I know what a normal authentication request looks like.
- I know never to approve an unexpected request.
- I reviewed registered devices and recovery information.
- I know what to do if my authentication device is lost.
Self check
- Why is a phishing resistant authentication method preferable when practical?
- Why should you never approve an unexpected push request?
- Why are recovery codes sensitive?
- Why should a new device be tested before removing an old authenticator?
- Why should a password remain unique even after MFA is enabled?
- Why should recovery information be reviewed during MFA setup?
Suggested answers
- It is designed to make it much harder for a fake service to capture authentication information and reuse it against the real service.
- The request may have been triggered by an attacker attempting to access your account.
- A recovery code may provide account access when the normal additional factor is unavailable.
- Testing reduces the risk of removing the only working authentication method and becoming locked out.
- MFA adds another security layer but does not make password reuse safe.
- An outdated or weak recovery route can undermine otherwise strong authentication.
Lesson summary
Enabling multi factor authentication involves more than switching on a setting.
Choose the strongest practical method available, register it through the real service and test it immediately.
Protect recovery information and understand how you would regain access after losing an authentication device.
Never approve an authentication request you did not initiate and never give temporary verification codes to someone who unexpectedly asks for them.
For important accounts, phishing resistant authentication provides stronger protection when it is supported and practical for you to maintain.
Continue learning
Review Multi Factor Authentication: What It Does and Why It Helps if you need to review authentication factors and phishing resistance.
Review Complete Guide to Staying Safe Online for the wider Digital Safety framework.