Handling Multi-Factor Authentication in UI Automation: Strategies & Implementation

Multi-factor authentication (MFA) is the wall that stops most UI automation projects dead in their tracks. You build an elegant automation workflow, deploy it to production, and the first time your bot hits the login screen, it gets blocked by a 2FA code.

For ops teams and integration agencies, this is a critical problem. Your customers use tools protected by MFA—QuickBooks Online, Hubspot, Asana, and dozens more require second factors. Manual workarounds defeat the purpose of automation. Building your own MFA-aware automation becomes a maintenance nightmare when vendors change authentication flows.

This guide walks through the technical approaches to MFA-protected automation, their trade-offs, and when to use each one. We'll show you the real challenges that most tutorials skip over, and the decision framework for whether to build or use a hosted solution.

Why MFA Breaks Standard UI Automation

Understanding the problem is the first step. When you automate a login flow with Selenium, Puppeteer, or Playwright, you're controlling a browser programmatically. The browser fills credentials, submits the form, and moves forward—all in milliseconds.

MFA disrupts this because it introduces a human-only dependency: a second factor that only the user can provide. The most common MFA methods are:

Time-based one-time passwords (TOTP): Apps like Google Authenticator, Microsoft Authenticator, or Authy generate 6-digit codes that change every 30 seconds. The user must input this code manually or through an API.

SMS-based codes: A text message arrives with a code. The user must read it and enter it before the code expires (usually 5-15 minutes).

Email-based verification: A verification link or code arrives via email. The user must click or copy the code within a time window.

Hardware tokens (U2F/WebAuthn): Physical security keys that verify the user through cryptographic challenge-response. These are difficult to automate without direct access to the key.

Push notifications: An app sends a push notification asking the user to confirm login. The user taps yes or no on their device.

When your automation hits the MFA prompt, the browser sits idle waiting for input that never comes. The session times out, and your workflow fails.

Approach 1: TOTP Automation (Most Practical)

Time-based one-time passwords are the most automatable MFA method because they're algorithmic. You don't need human intervention—you just need the shared secret (the seed value) that was generated when MFA was first enabled.

How TOTP Works

When you enable TOTP in an application, the system generates a shared secret and displays it as a QR code. Your authenticator app scans this QR code and stores the secret. The app then generates 6-digit codes using a standardized algorithm (HMAC-based One-Time Password, or HOTP, with time-based components).

To automate this, you need to:

1. Extract and store the initial shared secret before MFA is fully enabled (or retrieve it from your password manager)

2. Use a TOTP library to generate the current code at login time

3. Input the generated code into the MFA prompt

The shared secret is typically a base32-encoded string, about 32 characters long. If you've already enabled TOTP, most apps allow you to view backup codes—but better apps show you the shared secret itself during setup.

Implementation in Python

import pyotp
import time
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# The shared secret from your authenticator app
SHARED_SECRET = "JBSWY3DPEHPK3PXP"  # This is a base32-encoded string

# Initialize the TOTP generator
totp = pyotp.TOTP(SHARED_SECRET)

# Start browser automation
driver = webdriver.Chrome()
driver.get("https://app.example.com/login")

# Fill in username and password
username_field = driver.find_element(By.ID, "email")
password_field = driver.find_element(By.ID, "password")

username_field.send_keys("user@example.com")
password_field.send_keys("secure_password_here")

# Submit login form
login_button = driver.find_element(By.ID, "login-btn")
login_button.click()

# Wait for MFA prompt to appear
Wait = WebDriverWait(driver, 10)
mfa_input = Wait.until(
    EC.presence_of_element_located((By.ID, "totp-code-input"))
)

# Generate current TOTP code and enter it
current_code = totp.now()
mfa_input.send_keys(current_code)

# Submit MFA form
mfa_submit = driver.find_element(By.ID, "verify-btn")
mfa_submit.click()

# Wait for successful authentication
Wait.until(EC.presence_of_element_located((By.ID, "dashboard")))
print("Successfully authenticated!")

This works because TOTP is deterministic. The same shared secret always generates the same code for any given 30-second window. Your automation can generate codes as needed without any external service.

The Shared Secret Problem

The critical challenge here is obtaining and securely storing the shared secret. If you're automating your own tools, you can extract it during MFA setup. If you're building automation for customers, they need to:

1. Generate the shared secret during MFA setup and share it with you (security risk)

2. Use a password manager that stores TOTP secrets and exposes them via API (few do this)

3. Export backup codes and manually seed your system (not scalable)

This approach works for internal automations and controlled environments. For multi-tenant SaaS products or agencies managing dozens of customer automations, it becomes a security and operational burden.

Approach 2: SMS Code Interception

SMS-based MFA is harder to automate because the codes arrive via text message. Theoretically, you could:

1. Use a service like Twilio to programmatically access incoming SMS messages

2. Parse the code from the message

3. Feed it into the browser automation

Implementation Challenges

This requires the user's phone number to be registered with an SMS interception service instead of their personal device. That's a massive operational barrier. Most businesses use personal phones for MFA, and asking customers to change their phone registration for automation is unrealistic.

There are two narrow cases where SMS interception works:

Virtual phone numbers for service accounts: If you're automating a dedicated service account (like a shared QuickBooks login), you can register it with a virtual number service and intercept codes programmatically.

SMS forwarding via Twilio: Some services allow you to forward SMS to an API endpoint. You'd need to configure this on the user's account, which again requires their cooperation and technical setup.

For most real-world scenarios, SMS interception is not practical. It's expensive (Twilio charges per SMS), unreliable (messages can be delayed), and operationally complex.

Approach 3: Email Code Extraction

Email-based MFA is more automatable than SMS because you can programmatically access email inboxes. The workflow is:

1. Monitor the target email account for a verification email

2. Extract the code or link from the email

3. Use it in your automation

Implementation in Node.js

const imap = require('imap');
const { simpleParser } = require('mailparser');
const puppeteer = require('puppeteer');

// Email account credentials
const EMAIL_CONFIG = {
  user: 'automation@example.com',
  password: 'email_app_password', // Use app-specific password, not main password
  host: 'imap.gmail.com',
  port: 993,
  tls: true
};

const imapClient = new imap(EMAIL_CONFIG);

// Function to extract verification code from email
async function getVerificationCode() {
  return new Promise((resolve, reject) => {
    imapClient.openBox('INBOX', false, (err, box) => {
      if (err) reject(err);

      // Search for unseen emails from the last 2 minutes
      const searchCriteria = ['UNSEEN', ['SINCE', new Date(Date.now() - 2 * 60000)]];
      imapClient.search(searchCriteria, (err, results) => {
        if (err) reject(err);
        if (results.length === 0) {
          reject(new Error('No verification emails found'));
          return;
        }

        const f = imapClient.fetch(results, { bodies: '' });
        f.on('message', (msg) => {
          simpleParser(msg, async (err, parsed) => {
            if (err) reject(err);

            // Extract code from email body
            const codeMatch = parsed.text.match(/code[\s:]+([0-9]{6})/i);
            if (codeMatch) {
              resolve(codeMatch[1]);
            } else {
              reject(new Error('Could not extract code from email'));
            }
          });
        });
      });
    });
  });
}

// Main automation workflow
async function automateWithEmailMFA() {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();

  try {
    // Navigate to login
    await page.goto('https://app.example.com/login');
    await page.type('#email', 'user@example.com');
    await page.type('#password', 'secure_password');
    await page.click('#login-btn');

    // Wait for MFA email to arrive
    console.log('Waiting for verification email...');
    const verificationCode = await getVerificationCode();
    console.log(`Received code: ${verificationCode}`);

    // Enter code in MFA prompt
    await page.type('#mfa-code', verificationCode);
    await page.click('#verify-btn');

    // Wait for successful authentication
    await page.waitForNavigation();
    console.log('Successfully authenticated!');
  } finally {
    await browser.close();
    imapClient.end();
  }
}

automateWithEmailMFA().catch(console.error);

Email Automation Considerations

This approach has practical advantages over SMS:

Scalability: You can monitor multiple email accounts and parse multiple verification formats.

Reliability: Email is more reliable than SMS (fewer delays, better delivery rates).

Standards: Verification codes follow predictable formats in email bodies.

But there are real challenges:

Email delay: Transactional emails can take 5-30 seconds to arrive. Your automation needs to wait and retry, adding unpredictable latency to workflows.

Security concerns: You're storing email account credentials with full inbox access. A compromise of your automation system exposes the entire email account.

Rate limiting: Email providers rate-limit logins from multiple IPs. If you're running automations from cloud infrastructure, you may hit authentication blocks.

Formatting variations: Different apps format verification codes differently. Extracting codes requires regex patterns specific to each vendor.

Email-based MFA automation is viable for internal tools and controlled environments, but it's fragile when scaled across multiple vendors and customers.

Approach 4: Backup Codes and One-Time Use

Many MFA-protected apps generate backup codes during setup—typically 10 single-use codes that bypass MFA if you've lost access to your authenticator app.

Theoretically, you could automate using these backup codes. In practice, this is unreliable:

1. Backup codes are meant for emergencies, not regular use

2. Most apps limit how many backup codes you can generate

3. Once a code is used, it's consumed—future automations can't reuse it

4. Apps often detect repeated backup code usage as suspicious activity and lock the account

This is not a viable long-term automation strategy. It's useful only for one-off troubleshooting.

Approach 5: Session Persistence and Token Reuse

Instead of automating the login process every time, you can persist authenticated sessions and reuse them:

1. Manually log in once (with MFA)

2. Export the authenticated session cookies and tokens

3. Reuse those cookies in subsequent automations

Implementation in Puppeteer

const puppeteer = require('puppeteer');
const fs = require('fs');

const COOKIES_FILE = './authenticated_cookies.json';

// First run: Manual login with MFA, then save cookies
async function saveAuthenticatedSession() {
  const browser = await puppeteer.launch({ headless: false }); // headless: false for manual interaction
  const page = await browser.newPage();

  await page.goto('https://app.example.com/login');

  // Wait for user to manually complete login and MFA
  console.log('Please log in manually and complete MFA. Waiting...');
  await page.waitForNavigation({ waitUntil: 'networkidle2', timeout: 5 * 60 * 1000 });

  // Extract cookies after successful authentication
  const cookies = await page.cookies();
  const localStorage = await page.evaluate(() => JSON.stringify(window.localStorage));

  fs.writeFileSync(COOKIES_FILE, JSON.stringify({
    cookies: cookies,
    localStorage: JSON.parse(localStorage)
  }, null, 2));

  console.log('Session saved!');
  await browser.close();
}

// Subsequent runs: Load cookies and reuse session
async function automateWithPersistedSession() {
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();

  // Load previously saved cookies
  const sessionData = JSON.parse(fs.readFileSync(COOKIES_FILE, 'utf8'));
  await page.setCookie(...sessionData.cookies);

  // Restore localStorage
  await page.evaluateOnNewDocument((data) => {
    Object.entries(data).forEach(([key, value]) => {
      localStorage.setItem(key, value);
    });
  }, sessionData.localStorage);

  // Navigate to the app
  await page.goto('https://app.example.com/dashboard');

  // Now perform your automation tasks without re-authenticating
  const userData = await page.evaluate(() => {
    return document.querySelector('.user-name').innerText;
  });

  console.log(`Logged in as: ${userData}`);
  await browser.close();
}

// Run once to save session, then call automateWithPersistedSession() for future runs
saveAuthenticatedSession().catch(console.error);

This approach works well for long-lived automations because authenticated sessions typically last for hours or days. The trade-off is maintenance: when sessions expire, you need to manually re-authenticate and save new cookies.

Approach 6: Using Hosted UI Automation Services (Clickr)

The most reliable approach for production MFA automation is using a hosted service that handles MFA as a managed service. Services like Clickr maintain authenticated workflows that work reliably across vendor updates and authentication changes.

Here's why this matters:

MFA maintenance is not your problem: Clickr's team handles updates when apps change authentication flows. Your automation keeps working.

Human-in-the-loop for setup: During initial workflow configuration, a real person logs in and completes MFA setup. This happens once, not every time your automation runs.

No credential storage risk: You don't store credentials or MFA secrets in your infrastructure. Clickr handles credential management securely.

Reliability at scale: For production workflows running 100+ times per month, you need reliability guarantees. Hosted services provide monitoring, retries, and error handling.

Example: Using Clickr API for MFA-Protected QuickBooks

# Configure the workflow with MFA during setup (one-time)
curl -X POST https://api.clickr.io/workflows/quickbooks-project-sync/setup \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Sync Monday Projects to QuickBooks",
    "trigger": "webhook",
    "account_email": "user@example.com"
  }'

# Response prompts for authentication flow completion
# User logs in and completes MFA via browser

# Later: Use the workflow without worrying about MFA
curl -X POST https://api.clickr.io/workflows/quickbooks-project-sync/run \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "project_id": "monday-proj-12345",
    "customer_name": "ABC Construction"
  }'

The workflow handles all subsequent MFA challenges automatically. This is the trade-off analysis:

Build your own MFA automation: Lower per-execution cost, but significant development and maintenance burden. Session persistence requires ongoing monitoring. TOTP requires secure secret storage. Any vendor authentication change breaks your workflow.

Use a hosted service: Higher per-execution cost, but zero maintenance. Service handles vendor changes, MFA method changes, and authentication flow updates. Scales reliably from 10 to 1,000 executions per month without code changes.

Comparison Table: MFA Automation Approaches

When to Build vs. When to Use a Service

Build Your Own MFA Automation If:

You have direct access to MFA secrets: You're automating internal tools where you control account setup and can extract shared secrets during configuration.

Your automation is low-volume: Fewer than 50 executions per month. Session persistence is sufficient, and manual re-authentication is acceptable quarterly.

Your users are technical: If your customers are engineers who can assist with TOTP secret extraction or SMS forwarding setup, you can distribute some operational burden.

Vendor authentication is stable: The app you're automating hasn't changed its login flow in 18+ months and is unlikely to change soon (rare for modern SaaS).

Use a Hosted Service If:

You need production reliability: Your automations are mission-critical and require uptime guarantees and rapid error response.

You're automating multiple vendors: Every vendor change (and they're constant) requires your team to debug and update workflows. A service absorbs that cost.

You serve multiple customers: Managing per-customer credentials, secrets, and session management at scale is a security and operational nightmare. A service provides secure isolation and audit trails.

Your time is worth more than the service cost: If your engineering team spends 40 hours per month maintaining MFA automations, that's easily $10,000+ in salary cost. A hosted service at $300/month is an obvious ROI win.

You need to support changing MFA methods: When a customer enables hardware tokens (WebAuthn) or push notifications, your hand-built solution likely breaks. Services handle MFA method evolution automatically.

Common MFA Automation Failures and How to Prevent Them

Timing Issues

Problem: Your TOTP code is invalid because the time window shifted between code generation and input.

Solution: Generate TOTP codes 5-10 seconds before you need them. Test locally to measure the delay between code generation and form input, then add a buffer.

import time
from pyotp import TOTP

shared_secret = "JBSWY3DPEHPK3PXP"
totp = TOTP(shared_secret)

# Generate code 5 seconds early to account for network delay
code = totp.now()
time.sleep(0.5)  # Simulate processing delay

# Verify this code is valid for the remaining time window
if not totp.verify(code):
    # Code expired, generate a fresh one
    code = totp.now()

Credential Expiration

Problem: Email or SMS forwarding credentials expire, breaking automations without warning.

Solution: Monitor credential expiration dates and refresh them before expiration. Set calendar reminders for quarterly credential updates.

const EMAIL_CRED_EXPIRES = new Date('2024-12-31');
const DAYS_UNTIL_EXPIRATION = (EMAIL_CRED_EXPIRES - new Date()) / (1000 * 60 * 60 * 24);

if (DAYS_UNTIL_EXPIRATION < 30) {
  console.warn(`Email credentials expire in ${DAYS_UNTIL_EXPIRATION} days. Refresh immediately.`);
  process.exit(1); // Fail automation until credentials are refreshed
}

Account Lockouts

Problem: Your automation triggers multiple failed MFA attempts, and the account gets locked temporarily or permanently.

Solution: Implement exponential backoff and maximum retry limits. After 3 failed attempts, wait 1 hour before retrying.

import time

def attempt_mfa_with_backoff(max_attempts=3):
    for attempt in range(1, max_attempts + 1):
        try:
            return authenticate_with_mfa()
        except MFAFailureException as e:
            if attempt < max_attempts:
                wait_time = 2 ** attempt  # Exponential backoff: 2s, 4s, 8s
                print(f"MFA failed. Retrying in {wait_time} seconds...")
                time.sleep(wait_time)
            else:
                print(f"MFA failed after {max_attempts} attempts. Aborting.")
                raise

Vendor Authentication Flow Changes

Problem: The app changes its login flow (adds a new step, changes element IDs, adds CAPTCHA) and your automation breaks silently.

Solution: Implement health checks that verify authentication succeeds, and alert on unexpected changes. Monitor error rates.

def verify_authenticated_state(driver):
    """Verify we're actually logged in and not stuck on a login page."""
    current_url = driver.current_url
    
    # If we're still on login page, something went wrong
    if '/login' in current_url:
        raise AuthenticationFailedError(f"Still on login page: {current_url}")
    
    # If we can find the user menu, we're logged in
    try:
        driver.find_element(By.ID, 'user-menu')
    except NoSuchElementException:
        raise AuthenticationFailedError("Could not find user menu. Authentication likely failed.")
    
    return True

Implementation Checklist for Production MFA Automation

Before deploying any MFA automation to production, verify you've addressed each of these:

1. Credential Security: Credentials are encrypted at rest, transmitted over HTTPS, and not logged anywhere. Use environment variables or secrets management, never hardcode credentials.

2. Session Management: Sessions are cached appropriately. Sessions are invalidated after logout. Concurrent automations don't conflict by sharing/overwriting sessions.

3. Error Handling: MFA failures don't silently fail—they log detailed errors, alert appropriate teams, and fail with clear messages.

4. Retry Logic: Transient failures (network timeouts, email delays) trigger retries with exponential backoff. Permanent failures (wrong credentials) fail fast.

5. Rate Limiting: Your automation respects the target app's rate limits. You're not triggering bot detection by authenticating too frequently.

6. Monitoring and Alerting: Every authentication attempt is logged. Authentication failures trigger alerts. You're tracking success rates and latency metrics.

7. Testing: You've tested authentication across different network conditions (VPN, proxy, different cloud regions). You've tested with cookies/sessions expired. You've tested with temporary MFA method unavailability.

8. Documentation: Your team has documented which MFA secrets belong to which automation. You've documented the emergency manual login process if automation fails.

FAQ

Q: Is TOTP really secure for automation if we're storing the shared secret? A: TOTP shared secrets are essentially passwords. If someone accesses your secret storage, they can generate TOTP codes indefinitely. Treat secrets with the same security rigor as passwords—encrypt them at rest, limit access, rotate them regularly if possible. For customer-facing automations, storing customer TOTP secrets is a liability. This is why many teams migrate to hosted solutions—the service manages secret security, and customers don't need to share secrets directly with your infrastructure.

Q: How long do authenticated sessions typically last? A: Session duration varies widely. Some apps refresh sessions automatically when you're active (common for web apps). Others expire after 24 hours regardless of activity (common for financial apps like QuickBooks). A few expire after just 1 hour. Check the target app's documentation or test empirically. If you're relying on session persistence, monitor session expiration and implement re-authentication workflows. This complexity is why session persistence works better for short-term projects than ongoing production automations.

Q: What happens if we use a backup code in our automation and the user logs in manually before we've exhausted the codes? A: Nothing breaks immediately, but the user will have used up one backup code and won't be able to use it if they truly lose access to their authenticator. More problematically, apps often flag rapid or repeated backup code usage as suspicious activity. If your automation uses a backup code every day, the account may get locked for security reasons. Backup codes are genuinely one-time-use emergency codes, not regular authentication factors.

Q: Can we automate WebAuthn or hardware token authentication? A: Not reliably. WebAuthn is a cryptographic challenge-response protocol designed specifically to prevent automation. The flow requires proof of physical possession of the hardware key. Unless you have direct API access to the hardware device (rare and vendor-specific), you cannot automate WebAuthn. Some FIDO2 libraries provide simulation modes for testing, but these are intentionally not compatible with production authentication. If a vendor requires WebAuthn, you'll need either (a) their official API, (b) a hosted automation service that handles WebAuthn, or (c) a service account that uses a less strict authentication method.

Q: What's the difference between TOTP and HOTP? A: HOTP (HMAC-based One-Time Password) is the underlying algorithm. TOTP (Time-based One-Time Password) is HOTP with a time component. For automation purposes, they're essentially the same—you're using a shared secret to generate codes. The distinction matters if you're implementing cryptography from scratch, but most libraries (pyotp, speakeasy, etc.) handle both transparently.

Q: If we're using email for MFA automation, how do we handle multiple verification emails arriving in the same window? A: This is a real problem if your automation sends multiple requests in rapid succession. Best practice: wait for the email to arrive before sending the next request. If you need to process multiple items quickly, use a queue system that spaces out requests so you're not generating multiple verification codes simultaneously. Alternatively, extract the email address from the first verification email and use that to mark which requests were successful before processing the next batch.

Q: How do we test MFA automation without constantly triggering account lockouts? A: Use a dedicated test account. Enable MFA on the test account exactly as your production users have enabled it. Run tests against the test account, not your main accounts. If the app supports API-based automation, use the API for testing (MFA doesn't apply) and only test UI automation periodically. For services like Clickr, testing happens in isolated workflows—your test automations don't affect your production account or quotas.

Q: What's the cost comparison between building MFA automation in-house vs using a hosted solution? A: Building in-house costs: Developer time to build (40-80 hours, $2,000-8,000), infrastructure to run automations (servers or Lambda, $100-500/month), maintenance time as vendors change authentication (5-10 hours/month, $500-1,000/month). Total first-year cost: $8,000-18,000+. Hosted solutions: $200-500/month service cost ($2,400-6,000/year), zero maintenance. The hosted solution is cheaper after month 2-3 in most cases. The ROI improves further if you're automating multiple vendors or customers—each vendor change or customer update requires zero work on your end.

Q: If we're persisting authenticated sessions, how often do we need to refresh them? A: Test empirically with the target app. Set up an automation that uses a saved session, then measure how long it remains valid. Most SaaS apps keep sessions valid for 24-48 hours of inactivity. Some are more aggressive (1-4 hours). Build your workflow to handle expired sessions gracefully by detecting the 401/403 response and triggering re-authentication. In production, refresh sessions proactively every 12 hours to avoid expiration during your automation runs.

Q: Can we pool a single authenticated session across multiple concurrent automations? A: Technically yes, but it's risky. If two automations use the same session simultaneously and both trigger state-changing operations (like creating a project), you can hit race conditions or corruption. Most apps also log you out if they detect the same session being used from multiple IP addresses or browsers simultaneously. Best practice: each automation workflow gets its own authenticated session. This requires more session management overhead but is much safer.

Q: How do we know when a vendor has changed their authentication flow and our automation is broken? A: Monitor your automation health proactively. Log every authentication attempt with detailed timing and error messages. Set up alerts for (a) authentication failure rate exceeding 5%, (b) authentication latency increasing by 50%+, (c) unexpected page elements or URLs during authentication. When alerts fire, investigate immediately—don't wait for customer complaints. Automated screenshot capture during failed authentication attempts helps debug vendor changes quickly.