RPA tools were a genuine breakthrough when they arrived. The core idea: record what a human does on a desktop screen (click this button, read this field, enter this value), then replay it automatically. For internal enterprise software with fixed layouts and predictable state, this works. A payroll clerk processing expense reports inside SAP follows the same sequence of clicks every time. Record once, replay many times.
The structural assumption behind RPA is that the interface is stable and the session state is implicit. The user is already logged in. The application is installed on a managed corporate machine. The layout does not change between runs. When any of these assumptions break, the recording falls apart.
What Changed When Work Moved to the Web
The shift to web-based vendor portals, supplier management platforms, and SaaS tools introduced a new class of authentication problem. These portals live on the public internet. They require login at the start of every session. An increasing number require multi-factor authentication: a password plus a TOTP code, a push notification, or an email link. Sessions expire after periods of inactivity, sometimes as short as 15 minutes on sensitive financial portals.
Traditional RPA bots handle this poorly, because the authentication problem was not part of the original design target. Some RPA platforms added web automation capabilities as extensions to their core product. These extensions can navigate a browser and click elements, but they share the same underlying model: screen coordinates or brittle selectors, no real understanding of session state, and no mechanism for handling the authentication flow when a TOTP prompt appears mid-workflow.
In practice, this creates a class of workflows that RPA practitioners categorize as "attended" automation: a human has to sit nearby, watch the bot run, and jump in when authentication fails. The value proposition of unattended automation (runs while the human is doing something else) breaks down at the first MFA challenge.
Session State as a First-Class Concern
Browser agents built specifically for authenticated portal workflows treat session state as a first-class architectural concern rather than an afterthought. The differences are structural.
A browser agent maintains a persistent session context: the cookie jar, the sessionStorage values, the CSRF tokens, and any other state the portal set during login. It monitors for session expiration signals (redirect to login page, specific HTTP status codes, DOM elements that indicate the session has ended) and handles them without aborting the workflow. When re-authentication is required, it has a path: re-run the authentication flow, including MFA resolution, and then resume the workflow from its current position.
This is not just a convenience feature. For portal workflows that process dozens or hundreds of records in a single run, a session expiration that aborts the workflow and requires manual restart eliminates most of the value of automation. The session management layer has to be reliable enough that it simply works, across every run, without requiring a human to monitor it.
The TOTP Problem: Solvable and Not Solvable
Time-based one-time passwords (TOTP) are the most common MFA mechanism on vendor portals. The standard: a shared secret between the portal and the authenticator app generates a six-digit code that changes every 30 seconds. In TOTP-secured workflows, the browser agent needs access to the same shared secret so it can compute the current code independently and inject it when the login flow requests it.
This is solvable. TOTP is a standard algorithm (RFC 6238). Given the secret (typically the QR code value stored at enrollment time), a library like pyotp generates the current code on demand. The agent computes the code, injects it into the MFA field, and the login proceeds. The session is established. The workflow runs.
Email-based codes are solvable with additional integration: the agent triggers login, waits for the verification email to arrive in a designated inbox, reads the code, and injects it. More moving parts, but mechanically deterministic.
Push-notification MFA (the "approve this login" prompt on a mobile device) is a different category. It requires an out-of-band human action. There is no programmatic path to approving a push notification without access to the registered device. For portals that mandate push-only MFA with no fallback to TOTP or email, unattended automation has a hard limit. We are direct about this: if a portal's MFA strategy requires a physical device approval with no fallback, the authentication step cannot run unattended regardless of how sophisticated the automation layer is.
CAPTCHA: A Spectrum, Not a Binary
CAPTCHA handling is similarly a spectrum rather than a yes/no. Most portals that use CAPTCHA deploy it on the login page as a bot deterrent, not as a per-action challenge throughout the workflow. Modern CAPTCHA implementations (reCAPTCHA v3 in particular) work by behavioral scoring rather than explicit visual challenges: they observe mouse movement, interaction patterns, and browsing history to assign a trust score. A browser session that navigates naturally, with realistic timing between actions, passes behavioral scoring far more reliably than a session that moves at machine speed.
Explicit visual challenges (the "click all squares containing a traffic light" type) require different handling. Some use third-party CAPTCHA resolution services that pass challenges to human solvers and return the answer within a few seconds. This adds latency and cost per challenge. For portals where CAPTCHA appears only at login, this is an acceptable overhead. For portals that present visual challenges on every significant action, it makes the economics of automation questionable.
The honest answer is that CAPTCHA is a real constraint, and workflows that encounter heavy visual CAPTCHA throughout their execution path are harder to automate reliably. Our approach is to assess this per portal before building a workflow, not to claim CAPTCHA is always solvable.
Layout Stability and the Selenium Generation
Older RPA web automation tools were built on Selenium, which was originally a testing framework, not an automation layer. Selenium operates through the WebDriver protocol: it sends commands to a browser and receives responses. It works. But it carries the assumptions of its testing origins: brittle CSS selectors, synchronous command execution that does not handle asynchronous page rendering well, and no native concept of persistent sessions across separate runs.
Playwright (and to a lesser extent Puppeteer) represents a generational improvement. It uses the Chrome DevTools Protocol directly, which gives it access to network interception, browser console events, and precise control over timing and waiting strategies. Importantly, it can persist browser context to disk (cookies, storage, and session state) and resume from a saved context, which is the foundation for long-running authenticated sessions that survive across multiple workflow runs without re-authenticating from scratch.
Where RPA Still Makes Sense
This is not an argument that RPA is obsolete. For the original RPA use case (desktop application automation, attended or lightly supervised, on stable internal software), RPA tools are still the right choice. They have mature ecosystems, enterprise integrations, audit logging, and governance features that specialized browser agents do not need to replicate for the vendor portal use case.
The category distinction matters: RPA was designed for internal, managed, session-persistent desktop environments. Browser agents designed around web session authentication are a different category, addressing a different problem. The mistake is assuming that because RPA can open a browser, it handles authenticated web sessions as well as a purpose-built layer does. The authentication and session management requirements of modern vendor portals are distinct enough that they need to be a design center, not an edge case handled through workarounds.
What Good Session Architecture Looks Like
A browser agent that handles authenticated portal workflows reliably in production needs to get a few things right at the architecture level. First: credential storage that is not embedded in workflow code. Credentials change. Portal passwords rotate. MFA secrets get re-enrolled. The workflow should reference a credential by name from a secure store, not embed it as a string literal. Second: session health monitoring that detects expiration before it causes a mid-workflow failure, not after. Third: clean separation between the authentication layer and the workflow execution layer, so that an authentication failure triggers a retry of the auth flow, not a restart of the whole workflow from the beginning. Fourth: a retry budget with backoff and alerting, so that persistent failures surface to a human rather than silently failing after exhausting retries.
None of this is conceptually difficult. It is engineering discipline applied to a problem that most general-purpose automation tools treat as secondary. When you are building specifically for vendor portal automation, session authentication is the primary constraint, and the architecture has to reflect that.
