A single compromised employee credential is the most common starting point for a corporate data breach. Two-factor authentication closes this attack vector across your entire organisation.
Why 2FA Is Essential for Businesses
Business email compromise (BEC) costs billions annually. Attackers target employee email accounts to redirect payments, steal data, or pivot into internal systems. 2FA makes credential theft effectively useless — even if an attacker has the password, they can't log in.
Enforcing 2FA in Google Workspace
- Go to admin.google.com
- Navigate to Security → Authentication → 2-step verification
- Click Allow users to turn on 2-step verification
- Set enforcement: choose On to require 2FA for all users
- Set a grace period (recommended: 2 weeks) to allow employees to enrol
- Choose allowed 2FA methods — authenticator app recommended; SMS optional as backup
Enforcing 2FA in Microsoft 365
- Go to admin.microsoft.com
- Navigate to Security → Identity → Conditional Access
- Create a new policy requiring MFA for all users or specific groups
- Alternatively, use Security Defaults for simpler enforcement
Choosing the Right 2FA Method for Teams
Authenticator apps: Best for most businesses. Low cost, works on personal devices (BYOD), no hardware to manage.
Hardware security keys: Best for executives, IT admins, and employees with access to sensitive systems. Phishing-proof. Higher cost (~$25–$50 per key).
SMS: Acceptable for lower-risk roles but not recommended as the primary method for business accounts due to SIM swapping risk.
Employee Onboarding for 2FA
- Provide clear written instructions for the authentication method you've chosen
- Set a 2-week onboarding window before enforcement kicks in
- Identify and support employees who may not have a personal smartphone
- Provide backup code retrieval procedures so IT isn't flooded with lockout requests
What to Do When an Employee Loses Their Authenticator
- Verify the employee's identity via an out-of-band method (video call, manager confirmation)
- IT admin temporarily disables 2FA on the account
- Employee logs in and re-enrolls 2FA with their new device
- Re-enable 2FA requirement
Document this process in your IT runbook so it's handled consistently.
The Business Case for Mandatory 2FA
According to the Verizon Data Breach Investigations Report, over 80% of hacking-related breaches involve compromised credentials. For businesses, a single compromised employee account can expose customer data, internal communications, and critical systems. Two-factor authentication is the single most impactful control for preventing credential-based attacks. It is also increasingly required for compliance: many cyber insurance policies, SOC 2 audits, and regulations like HIPAA and PCI-DSS treat MFA as a baseline requirement.
Choosing a 2FA Method for Your Organisation
For most businesses, the choice comes down to TOTP authenticator apps versus push notification MFA (like Microsoft Authenticator or Duo). TOTP apps work offline and are familiar to technical users but require manual code entry. Push notification MFA is more user-friendly but requires internet on both the computer and phone. For high-privilege accounts (admins, finance, C-suite), hardware security keys provide the strongest protection and resistance to phishing.
Enforcing 2FA Across Your Team
Most identity providers make enforcement straightforward. In Google Workspace, go to Admin console → Security → 2-Step Verification and set enforcement to "On (mandatory)". In Microsoft 365/Azure AD, use Conditional Access policies or Security Defaults to require MFA for all users. GitHub organisation owners can require 2FA for all members under Organisation Settings → Authentication security. Slack admins can require 2FA under Settings → Authentication → Two-factor authentication.
Handling New Employee Onboarding
Make 2FA enrollment part of day-one onboarding. Create a written procedure: new employees set up their authenticator app before being given access to company systems. Provide clear documentation or a short setup guide tailored to the apps and systems you use. Have a nominated IT contact for 2FA issues. Employees are much more likely to comply if the process is clear and supported rather than dropped on them as an afterthought.
Recovery and Lost Device Procedures
Document and communicate a recovery process before someone needs it. Typical elements: a backup phone number on file for emergency SMS recovery, IT-held backup codes stored securely (not in email), a clear policy for re-enrolling 2FA after device loss. For federated identity (SSO through Okta, Azure AD, etc.), admin-initiated 2FA reset is usually possible without user backup codes. Test your recovery process periodically — a recovery procedure you have never tested may not work when it matters.
Measuring Whether Your 2FA Rollout Is Working
Track enrollment as a metric, not a one-off checkbox. Both Microsoft 365 and Google Workspace expose per-user MFA status in their admin reports, so you can see exactly who has enrolled and who is still inside the grace period. Schedule a weekly review during rollout and set a hard deadline after which accounts without 2FA are suspended rather than merely reminded. Enforcement without a deadline typically produces 60–80% adoption; enforcement with a deadline and a support path consistently produces 95% or more.
Complement enrollment numbers with a second signal: how many 2FA support tickets arrive per week. A spike in lockout requests usually means your onboarding instructions are unclear or your backup-code process is not understood — both are fixable documentation problems, not user problems.
Common Implementation Mistakes to Avoid
The most frequent failures are: allowing SMS as the only method (SIM swapping applies to employees too), sending backup codes by email (email is usually the first account attackers compromise), and forgetting service accounts and shared mailboxes — these rarely get 2FA because nobody logs into them, and attackers know it. A compromise of a shared mailbox is often how a targeted business email compromise begins.
Plan for employees who change devices mid-rollout: re-enrollment generates most of the support load, so write a short "new phone, new laptop" guide before you need it. Keep at least one break-glass admin account with a hardware key and a documented offline recovery path, and verify once a quarter that it still works.
Role-Based 2FA: Who Gets Which Method
Not every employee needs the same level of protection. A sensible default is a TOTP authenticator app for everyone, then upgrade specific groups to hardware security keys: finance and payroll staff, IT administrators, executives, and anyone with access to customer databases or code repositories. These roles concentrate the damage a single stolen session can cause, and a phishing-resistant key removes the one remaining attack that apps cannot stop. Support agents who sign in dozens of times a day benefit more from push notification MFA with number matching, which accepts or rejects a login with one tap while still preventing prompt-fatigue attacks.
Contractors and consultants deserve their own category: grant them temporary accounts with TOTP only, put an expiry date on the access itself, and never issue a shared login "so it is easier for the agency". When the engagement ends, the account — and its enrolled authenticator — is simply deleted. Document the mapping of roles to methods in your security policy so the choice is a rule, not a decision made fresh at every hire.
Vendors, Shared Accounts, and Service Accounts
Your employees are not the only people logging into your systems. Vendor portals, agency platforms, and partner integrations all carry credentials, and a vendor's weak authentication becomes your breach. Where you control the system, enforce MFA on vendor-facing accounts in the same way as internal ones; where you do not, ask the vendor directly whether MFA is mandatory for their staff in your security questionnaire, and treat a "not yet" answer as a risk that needs a compensating control such as read-only access or quarterly credential reviews.
Shared mailboxes and service accounts are the classic blind spot because no single human "owns" them, so enrolment never happens. Prefer managed identities or per-application credentials where the platform supports it; where a shared mailbox is unavoidable, require that the people who use it authenticate with their own personal MFA on top, and review who has delegate access twice a year. A service account used by an API should use a machine credential with rotation, not a password with 2FA attached to a phone that sits on a desk.
What Auditors, Insurers, and Regulators Actually Ask For
2FA is not only a technical control; it is an audit and insurance requirement with paperwork attached. PCI DSS requires multi-factor authentication for remote access into the cardholder data environment and for all administrative access to it, and expects evidence — policy screenshots, enrollment reports, and exception lists. HIPAA treats MFA as part of the administrative and technical safeguards for access control, and SOC 2 reviewers check it under CC6.1. Cyber insurance applications routinely ask whether MFA is enforced, how (app, SMS, hardware key), and for which systems, and a "partially" answer can raise premiums or remove coverage for account-takeover losses.
Build the evidence trail before the auditor asks: export per-user MFA enrollment reports from your identity provider every quarter, keep a dated record of which groups use which method, and document every exception with an owner and an expiry date. The easiest way to fail an audit is not a missing control but an unmanaged exception — a single admin account on SMS-only with no review date can sink an otherwise clean report.