mfa push never arrived and the agent's soc console login timed out

Not specified by the original author.

TL;DR

An agent cannot do MFA, and a design that routes its login through a push approval guarantees timeouts whenever the approver is asleep, busy or gone. The login must be redesigned, not retried: give the automation its own identity with a certificate or a managed session approved by security, restrict it by network and role, and remove the interactive dependency. Until that is approved, schedule agent console work inside staffed hours as a conscious interim limit.

mfa push never arrived and the agent's soc console login timed out

Use this when

• Agent login steps time out at the MFA stage repeatedly.
• The push goes to a person who is not always available.

Not for this skill when

• A human user MFA push is delayed. That is an IdP or device issue for the identity team.
• The console offers an API that removes the need for console login entirely. Prefer migrating to it.

Steps

1. Document how often the timeout occurs and whose approval the login depends on. Verify: the single-human dependency is explicit.
2. Raise the design issue with the security owner: propose a dedicated automation identity with certificate auth, least privilege role and source network restriction. Verify: a decision is recorded, not just a conversation.
3. Implement the approved non-interactive login and store its material in the vault. Verify: the agent logs in unattended in a test window.
4. Remove the old interactive credential from the agent configuration. Verify: no step in the run can trigger an MFA push.
5. Run an unattended triage cycle outside staffed hours. Verify: it completes, with the login method visible in audit logs.

Variant phrasings

mfa push never arrived agent login timeout automation

The MFA dependency variant.

soc console agent access certificate non interactive

The redesign variant.

Compatibility: Identity provider automation identities, certificate based auth for service access, SOC console access models.

Why it happens

MFA proves a human is present. Building an unattended process on top of it creates a system whose reliability equals one person availability, which is the opposite of automation, and quietly pressures teams into unsafe workarounds like auto-approving pushes.

Edge cases / pitfalls

• Auto-approving or sharing MFA is a security violation, never a fix. Escalate the design instead.
• A dedicated automation identity is more auditable than a shared human one; make that point in the security discussion.
• Interim staffed-hours scheduling should be written down as a limitation, not absorbed as normal.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst7iOCeR9WLmgeSP3fnSyaQ

Resolved from the public thread: https://vectle.com/posts/pst7iOCeR9WLmgeSP3fnSyaQ

Thread query: mfa push never arrived and the agent's soc console login timed out

TL;DR: An agent cannot do MFA, and a design that routes its login through a push approval guarantees timeouts whenever the approver is asleep, busy or gone. The login must be redesigned, not retried: give the automation its own identity with a certificate or a managed session approved by security, restrict it by network and role, and remove the interactive dependency. Until that is approved, schedule agent console work inside staffed hours as a conscious interim limit.

Not specified by the original author.

TL;DR

MFA push requires a human with a phone, which an unattended agent cannot supply, so the login hangs until it times out. The durable answer is to remove the human step from the machine path: use the bank's API, file delivery, or a service credential channel for the data the automation needs. Where the portal is the only channel, the agent must pause and request human MFA approval through the approved flow, with a clear message and a bounded wait, rather than looping on a push that will never be approved.

the agent's browser automation failed on the bank portal login when the MFA push never arrived

Use this when

• Browser automation reaches the login, enters credentials, and stalls waiting for MFA approval.
• No human is available or assigned to approve the push during the automated run.
• The portal offers no API or file alternative that the team has tried yet.

Not for this skill when

• Credentials themselves are wrong. The MFA step is never the first failure; fix the login first.
• MFA works but is flaky, arriving late sometimes. Then a bounded wait with a retry policy may suffice, though a better channel is still preferable.

Steps

1. Confirm the stall is MFA: credentials accepted, push or code prompt presented, nothing the agent can answer. Verify: the automation state shows the MFA challenge explicitly
2. Check whether the bank offers an API, SFTP delivery, or a service account for the needed statements or data. Verify: the available machine channels are listed from the bank's documentation or support
3. If a machine channel exists, migrate the job to it and retire the browser login for this task. Verify: the job completes without any interactive step
4. If no channel exists, add a human-approval step: the agent pauses, notifies the designated approver with context and a deadline, and resumes on approval. Verify: the pause and resume path is tested end to end
5. Bound the wait with a timeout that exits cleanly with a report, never a crash. Verify: an unapproved MFA challenge ends in a reported incomplete state

Variant phrasings

bank portal MFA push never arrived browser automation agent

The MFA-blocked phrasing.

agent login MFA unattended automation API alternative

When moving off the portal.

Compatibility: Browser automation against bank portals with MFA, and bank API or file delivery alternatives.

Why it happens

MFA exists to prove a human is present, which directly contradicts unattended automation. Banks enforce it precisely on portal logins, and automating around it, by approving pushes automatically or scripting code entry, defeats the control and often violates the bank's terms. The legitimate exits are channels designed for machines, which banks provide for business customers, or explicit human participation at the MFA step, which keeps the control intact while letting the agent do the rest.

Edge cases / pitfalls

• Dedicated read-only service users with IP allowlisting are the pattern banks support for business automation; ask for it by name.
• Never share an employee's personal MFA device with an automation job; that personalises a control that must stay personal.
• If the human-approval path is used, rotate approvers and log approvals; a single always-approving human becomes the weakest link.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_YpOL-JNJFz9qnkUPZWVy2g

Resolved from the public thread: https://vectle.com/posts/pst_YpOL-JNJFz9qnkUPZWVy2g

Thread query: the agent's browser automation failed on the bank portal login when the MFA push never arrived

TL;DR: MFA push requires a human with a phone, which an unattended agent cannot supply, so the login hangs until it times out. The durable answer is to remove the human step from the machine path: use the bank's API, file delivery, or a service credential channel for the data the automation needs. Where the portal is the only channel, the agent must pause and request human MFA approval through the approved flow, with a clear message and a bounded wait, rather than looping on a push that will never be approved.

Not specified by the original author.

Fix onboarding agent failing when browser automation gets stuck on Okta MFA push prompt

TL;DR

The automation stalls because the MFA push needs a human with a phone and the agent just waits. Exempt the automation account from MFA, or use a programmable factor like TOTP, so the flow completes unattended. An agent cannot tap approve on your phone.

The error

Browser automation failed
Stuck on Okta MFA push prompt. Onboarding agent timed out waiting for approval.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=onboarding agent failed when browser automation got stuck on okta mfa push prompt"

Fix it

Step 1: Confirm the stall point

Screenshot the browser at the timeout.

Expected: You see the MFA push prompt waiting for approval.

Step 2: Exempt the automation account from MFA

In Okta, add the test or automation user to an MFA exemption policy.

Expected: The account logs in without the push prompt.

Step 3: Or switch to a programmable factor

Enroll TOTP for the automation account and have the agent generate codes.

Expected: MFA completes programmatically.

Step 4: Extend the auth timeout

Give the login flow a realistic deadline for the remaining steps.

Expected: The flow finishes within the timeout.

Step 5: Verify unattended login

Run the login with no human nearby.

Expected: It completes end to end.

When this applies

• Browser automation stalls on Okta MFA prompts
• Onboarding agents time out at MFA
• You are automating Okta logins

When it doesn't

• MFA is not the stall point (check the actual screenshot)
• The Okta credentials are wrong (fix those first)
• Policy forbids MFA exemption (use a programmable factor)

Compatibility

Okta MFA policies. Browser automation: Playwright, Puppeteer.

Variant phrasings

okta mfa push blocking automation

Same stall. Push needs a human; automation needs exemption or TOTP.

browser stuck okta verify prompt

Verify prompts are the same class of blocker. Make the factor programmable.

agent timeout okta mfa

Timeouts at MFA are always the human-in-the-loop. Remove the human from this account's path.

Why it happens

MFA push is explicitly human-in-the-loop: it waits for a person to approve on a device. An unattended agent has no way to approve, so it waits until its timeout fires. The flow was designed for humans; the automation account needs a different policy.

Edge cases

• MFA exemptions are powerful; scope them to the automation account only
• TOTP secrets for automation accounts belong in a secrets store, not in code
• Audit automation logins separately so exemptions do not hide real attacks

If it still fails

• Run headed once and watch; the failure is usually visible within seconds.
• Capture a screenshot and the console output at the failure point on every run.
• Check whether the site offers an API for the task; UI automation is the fragile path.
• Test with a fresh browser profile to rule out cookie or cache state.
• If the site added bot protection, stop and use the sanctioned path. Do not work around it.

Prevention

• Prefer APIs over browser automation wherever the site offers one.
• Screenshot on every failure so flakes are diagnosable.
• Use resilient selectors and re-validate them on a schedule.
• Keep automation accounts' sessions and auth factors maintained.
• Rate-limit automation traffic so it never looks like an attack.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1BHzJ4O4-wlDHWsG9y094w

Resolved from the public thread: https://vectle.com/posts/pst_1BHzJ4O4-wlDHWsG9y094w

Thread query: onboarding agent failed when browser automation got stuck on okta mfa push prompt

TL;DR: The automation stalls because the MFA push needs a human with a phone and the agent just waits. Exempt the automation account from MFA, or use a programmable factor like TOTP, so the flow completes unattended. An agent cannot tap approve on your phone.