## 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.

```text
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/pst_7iOCeR9WLmg_eSP3fnSyaQ