If you have tried to automate a vendor portal workflow and it worked fine until the portal added two-factor authentication, you already know the specific way this failure mode feels. The workflow runs. It logs in. It gets to the TOTP prompt. It sits there. Your nicely built automation is waiting for a human to type a six-digit code into a field that changes every 30 seconds, and the entire value proposition of unattended automation evaporates.
This is the most common place where portal automation projects stall. It is also the most commonly misunderstood, because the headline framing ("MFA blocks automation") obscures a more useful distinction: some MFA mechanisms are programmable, and some are not. The appropriate response to MFA is not "abandon the automation" but "understand which category this portal falls into and architect accordingly."
TOTP: Solvable at the Protocol Level
TOTP (time-based one-time passwords, standardized in RFC 6238) is the mechanism behind Google Authenticator, Authy, and most authenticator apps. During enrollment, the portal generates a shared secret (usually displayed as a QR code). The authenticator app encodes that secret and generates a six-digit code by hashing the secret against the current Unix timestamp divided into 30-second intervals. The portal generates the same code server-side and checks that they match.
The key insight: "TOTP" is not inherently tied to a physical device. It is a deterministic algorithm. Anyone with the shared secret can generate the current valid code. When we integrate TOTP authentication for a portal workflow, we store the enrollment secret (the value encoded in the QR code, which is usually a base32 string) and compute the current TOTP code on demand using the same algorithm the authenticator app uses. When the login flow hits the TOTP prompt, the agent computes the code for the current 30-second window, injects it into the field, and the login succeeds.
This is well-understood cryptography, not circumvention of the security model. The organization that operates the portal gave you credentials and enrolled you in MFA. You are using those credentials and that enrollment. The automation is exercising the same authentication path you would exercise manually.
Timing Sensitivity in TOTP Flows
One practical detail that matters for reliable TOTP handling: the 30-second window means timing matters. A code generated at 29 seconds into the window expires in one second. If the automation computes the code and then takes two seconds to find and click the MFA input field, the code has expired and the login fails.
Our approach is to compute the TOTP code after the MFA prompt is visible in the DOM, not before. We also check the remaining time in the current window before using the code: if less than five seconds remain, we wait for the window to roll over and generate the fresh code. This adds at most 30 seconds to authentication time in edge cases but eliminates the failure mode of submitting an expired code.
Most portals also accept codes from the previous window (a grace period of one window before and after the current valid code), which provides additional tolerance. When available, this is worth knowing: it means a 3-second timing miss will not fail the login.
Email-Based Verification Codes
Some portals use email verification instead of or in addition to TOTP: login triggers an email to the registered address containing a short code, which the user must enter to complete authentication. This is mechanically solvable but requires an additional integration: access to the inbox where verification emails arrive.
The practical implementation involves monitoring the inbox for the verification email (matching on sender domain and subject line patterns), extracting the code from the email body (using regex against the standardized format most portals use), and injecting it into the verification field. The latency is usually 5-15 seconds for the email to arrive, which needs to be accounted for in the automation's wait strategy.
The reliability risk here is inbox access continuity. If the email account's password changes or the inbox access method breaks, the authentication flow stalls. This is operationally manageable but requires more monitoring than pure TOTP, where the only dependency is the stored secret.
Push Notification MFA: The Hard Limit
Push notification MFA (the "did you just sign in?" approval prompt on a mobile device) is categorically different from TOTP and email codes. There is no programmatic path to approving a push notification without physical access to the registered device. The security model is specifically designed to prevent this: the approval action requires human presence on a specific device that the account owner controls.
We are direct about this in conversations with operations teams evaluating portal automation: if a portal's primary MFA mechanism is push notification with no fallback to TOTP or email, unattended automation of the login step is not viable. Some portals that default to push notification offer TOTP as a fallback method during enrollment; when this is available, we enroll using TOTP and use that path. When push is the only option with no fallback, the authentication step requires a person.
This is a genuine limit, not a limitation of any particular tool. Anyone claiming push notification MFA is fully automatable without device access is either misstating the security architecture or proposing something that violates the portal's security model in ways that create organizational risk.
CAPTCHA: A More Nuanced Picture
CAPTCHA handling is often discussed as a binary (it works or it does not), but the practical picture is more varied. There are several distinct CAPTCHA mechanisms, and they have different implications for automation.
reCAPTCHA v2 (the checkbox "I am not a robot" and the image selection grids) presents explicit visual challenges. These are handled through third-party CAPTCHA resolution services, which pass the challenge to a human solver and return the solution token in a few seconds. The latency is 5-30 seconds per challenge. For portals that present this challenge only at login, the cost is a brief delay at the start of each workflow run. For portals that present it on every significant page action, the economics become less favorable and the reliability decreases.
reCAPTCHA v3 is a behavioral scoring system that observes interaction patterns without presenting an explicit challenge. A browser session that navigates realistically (with human-like timing between actions, natural mouse movement patterns, and a consistent session history) tends to score well. Pure bot behavior (machine-speed form submission, no cursor movement, no prior browsing history) scores poorly and may trigger additional verification. Playwright browser contexts that are configured to behave naturally generally handle v3 without needing external resolution services.
hCaptcha and Cloudflare Turnstile use similar behavioral models to v3 with varying sensitivity. The practical experience is similar: natural-behaving browser sessions pass more reliably than overtly mechanical ones.
Keeping Sessions Alive After Authentication
Clearing the MFA gate at login is only part of the problem. Portal sessions expire. The typical session timeout range on financial and procurement portals is 15-60 minutes of inactivity. For workflows that process large batches of records, session expiration mid-run is a common failure mode if not handled explicitly.
The session management approach we use has three components. First: periodic session health checks during the workflow. Rather than waiting for a page action to fail with a "session expired" error, the agent proactively pings a portal endpoint or checks for the presence of session-indicating DOM elements at configurable intervals. Second: re-authentication without losing workflow state. When the session check indicates expiration, the agent saves the current workflow position (which record it was on, what step it had completed), runs the full authentication flow again (including MFA), and then resumes from the saved position. Third: session persistence across runs. For portals where re-authentication is costly (either in time or in MFA overhead), we persist session cookies to disk and attempt to resume an existing session at the start of each run before falling back to a fresh login. Many portals keep session cookies valid for hours or days even after the in-browser session times out, which means the full login flow only runs when the cookie truly expires.
What to Assess Before Automating a Portal
Before committing to automating a specific portal, we do a brief authentication audit: what MFA mechanism does the portal use? Is TOTP available as an enrollment option? Does the portal use CAPTCHA, and if so, on login only or throughout the workflow? What is the session timeout? Does the portal have bot detection that goes beyond standard CAPTCHA (behavioral fingerprinting, device registration requirements, IP allowlisting for authenticated sessions)?
The answers determine whether the workflow is viable as unattended automation, viable with some human touch at the authentication step, or not viable for unattended automation given the current portal design. Most portals fall into the first category. A meaningful minority fall into the second. Very few fall into the third, but when they do, saying so accurately is more useful than overselling what is possible.
