How AI Workflows Can Use Two-Factor Authentication Without Removing It

At 6:40 on a Monday morning, an invoice-review workflow at a made-up promo distributor stops halfway through its queue. The ERP has asked for a fresh security-key sign-in, and the workflow can't provide one. Chris, who owns the connection, gets a notification naming the application and the paused job, taps the key at their desk a few minutes later, and the queue picks up where it left off.

Nobody suggested turning off MFA for the account so the overnight run would stop getting interrupted, which is the suggestion that tends to come up first. The interruption wasn't a bug. It was the login doing its job, and the workflow was built to expect it.

An AI workflow can keep two-factor authentication in place by working inside an approved interactive session and pausing for a person whenever the application asks them to sign in again. Where the application supports access built for software, IT can evaluate an authorized application identity with its own controls instead. Neither path involves disabling MFA on a user account to avoid interruptions.

Your acceptance test should cover the first login, session expiry, a secure handoff, revocation, and recovery of half-finished work. Whether the workflow can run unattended depends on which sign-in methods the application actually supports, not on how convenient unattended access would be.

Two kinds of access, two sets of rules

Interactive access means a person signs in to an application, usually through a browser. That login might involve a password plus another factor, a passkey, a security key, or your company's identity provider. A browser workflow can then work within the approved session that login created, subject to the application's own rules.

Application access uses an identity and authorization method designed for software. Depending on the system, that could be an approved OAuth flow, a service principal, or another mechanism the vendor supports. It has to be designed and approved as application access, with a defined scope, a named owner, and protected credentials.

The two don't carry identical controls. Microsoft's documentation notes that workload identities, unlike users, can't perform MFA, and that Conditional Access for workload identities has its own licensing and scope limits. That's a reason to review the supported setup with IT. It isn't a reason to exempt an ordinary shared user account from MFA. See Microsoft's Conditional Access for workload identities.

What the second factor actually asks for

"Supports 2FA" is too broad to plan around. An SMS code, a code from an authenticator app, a push approval, and a hardware-backed sign-in each ask for something different from the person and give different protection. Before anything gets built, write down which factor the application will request and who is able to complete it.

CISA urges organizations to implement phishing-resistant MFA, and describes number matching as an interim step for teams still using push notifications, not as equal protection. Pick the factor through your security policy, not by choosing whichever one looks easiest to automate. See CISA's fact sheets on phishing-resistant MFA and number matching.

Ask your automation provider which methods work in its actual browser environment, and don't assume an agent can complete every factor an employee can. If a login needs a person's security key or device approval, plan for that person to complete it through an approved handoff. Passwords, recovery codes, authenticator seeds, and session cookies should never travel through chat, email, task descriptions, or spreadsheets. A one-time code belongs only in the verified sign-in flow for which it was issued, and account recovery stays with your administrators.

Plan for the session to end

A remembered session can cut down on repeated logins, but it is never permanent access. Find out what ends the session, how a policy change affects it, and how the workflow will notice that the application wants a fresh sign-in.

The more important question is what happens to the work in progress. A good handoff records the affected job, the last action that was confirmed, and whether a change in another system might already have gone through. It alerts the right owner, then resumes only after access is back and the current state has been checked.

Take a made-up workflow that opens the ERP to prepare an overdue-balance review. If the login expires before any record is read, the job can simply pause. If it expires after a reminder was submitted but before the confirmation appeared, the workflow has to check the communication log before trying again. Recovering from an expired login and preventing duplicate actions belong in the same test plan.

A recovery runbook for an expired session

Here is how that should play out for a made-up invoice-review workflow that uses an approved browser session. It can prepare reminder drafts but can't send them. An invoice has been selected when the ERP asks for a fresh security-key sign-in.

A passing test leaves evidence behind: the pause event, the owner notification, the refreshed invoice state, and exactly one reviewed draft. This describes the behavior to ask for, not how any particular provider implements the handoff today.

Give the connection an owner

Use an approved identity with a named business owner and a named technical owner. Write down who can restore access, who can revoke it, and who covers when either is away. An automation tied to one employee's personal phone is a continuity problem waiting for a vacation, though the fix still has to follow your identity provider's supported model.

Check whether the application allows more than one session at a time. Some limit logins or end an existing session when a new one starts, so confirm the behavior in your environment before assuming the agent and your staff can share one account. The account should also hold only the permissions the workflow needs. An order-status reader doesn't need user administration or payment authority because those happened to make early testing easier.

Test the interruptions on purpose

Run a controlled pilot that goes further than the first successful login, and keep the evidence from each step. Cover at least these cases:

• Start with no active session and complete the approved sign-in.
• End a session during a safe test and check that the pause notification arrives.
• Require a fresh factor and confirm the right person can respond.
• Remove the account's permission and confirm the workflow stops.
• Restore access and check that pending work resumes exactly once.
• Confirm the logs hold enough detail to diagnose problems without exposing secrets.

Agree on a maximum wait and a fallback owner for time-sensitive work. If a workflow has to run unattended overnight but its supported login needs a person who won't be there, the operating plan isn't ready. Use a supported application-access option if one exists, narrow the schedule, or keep a human step in the process.

When a person still has to be there

MFA and automation can work together when sign-in is treated as a real dependency with an owner, a recovery path, and an honest description of when a person has to take part. That's a better outcome than a workflow that runs smoothly only because a protection was quietly switched off.