-
Introduction to Cybersecurity
-
Assessing Your Current State
-
Building a Security-Conscious Culture
-
Device Management and BYOD Policies
- Phishing and Social Engineering Attacks
- Password Management and Authentication
-
Security Practices and Device Planning
- Data Backup and Recovery
-
Securing WiFi and Network Connections
-
Payment and Financial Security
-
Payment Providers and System Separation
- Multifactor Authentication and Advanced Protocols
-
Expert Consultation with Colabmo
-
Conclusions and Next Steps
Implementing Two-Factor Authentication
Choose stronger two-factor authentication
Learning edition: 5 October 2026. Introductory learning material.
Two-factor authentication uses two different factor types, such as a password and a possession-based authenticator. Two passwords or a password plus a security question do not provide two different factors.
Prefer phishing-resistant authentication, such as an appropriately configured FIDO security key or passkey. One-time codes and push prompts can still be phished; SMS also carries interception and account-transfer risks. Use the strongest supported option and plan improvements where stronger methods are unavailable.
Activity: With your IT owner, identify the options for one important account, including recovery and lost-authenticator handling. Never share a code or approve an unexpected prompt.
Reference: CISA multifactor authentication guidance. Check the source and your system provider’s current instructions before implementation.
FIDO Alliance: passkeys and phishing resistance.
Make the choice operational
For one important account, record the account owner, available authentication methods, selected method, recovery owner and evidence that enforcement works. Prefer a phishing-resistant option where supported. Test recovery using the provider's approved procedure before relying on the account for critical work.
Example: A manager receives an approval prompt while not signing in. They reject it and report it through a known support route. Repeated prompts are a reason to investigate, not a reason to approve one.
Complete the knowledge check below. Later, the MFA rollout lesson helps you extend this account-level decision across the business.
Two traps that a genuine sign-in page does not resolve
Consent phishing: A malicious app can ask for permission to read mail, send messages or access files through a real provider’s permission screen. Check the app, purpose and requested access against your organization’s approval process. Signing in successfully does not make the app trustworthy.
Device-code phishing: A message can supply a code that authorizes someone else’s sign-in session when you enter it at a genuine provider page. Only complete a device-code flow that you deliberately started for an approved device or application.
If you approved an unfamiliar app or entered an unexpected code, report it immediately. The authorized administrator should investigate permissions, sessions and account activity and revoke inappropriate access using current provider guidance. A password change alone may leave an app’s permission intact. Keep phishing-resistant authentication: these examples show why access approval and recovery controls matter too.
Further reading: FBI: Consent phishing advisory (1 September 2026); Microsoft: Inside an AI-enabled device code phishing campaign (6 April 2026).
There are no comments for now.