## TL;DR
Service accounts and MFA prompts do not mix: an unattended run cannot answer a push or a code. The correct resolution is policy design, not automation of the second factor: work with the identity team to place the service account under the right conditional access treatment for non-interactive automation (for example a policy scoped to the agent source network and a strong first factor such as a certificate), or move the automation to a workload identity that does not use interactive sign-in at all. Never script around MFA with a human personal factor.

```text
agent failed on mfa prompt during scheduled service account run
```

## Use this when
- The scheduled run fails at authentication with an MFA requirement message, after previously working.
- The IdP sign-in log shows the run blocked by a conditional access policy requiring a second factor.
- The change coincides with an identity policy rollout.

## Not for this skill when
- An interactive admin is prompted for MFA. That is the policy working as intended for humans.
- The run fails before any policy evaluation (wrong credential). MFA is not yet the issue.

## Steps
1. Capture the sign-in log entry for the failed run showing the policy and requirement that blocked it. Verify: the exact policy name and condition are identified
2. Stop any retries: repeated challenged attempts add noise and risk lockout. Verify: the agent is configured to treat an MFA challenge as a terminal, alerting failure
3. Engage the identity team with the evidence and the automation requirements (source hosts, schedule, scope of access). Verify: a ticket or change record exists describing the service account non-interactive design
4. Implement the agreed design: scoped policy exception with compensating controls (network restriction, certificate-based first factor, least-privilege scope), or migration to workload identity. Verify: the change is made by the identity team in the IdP, not by the agent
5. Test the scheduled run end to end and document the arrangement in the runbook with its review date. Verify: the run succeeds unattended and the policy exception has an owner and an expiry or review

## Variant phrasings
### service account mfa prompt scheduled run conditional access design
The main phrasing.
### non interactive automation workload identity instead of mfa
The structural-fix phrasing.
### never automate second factor service account rule
The safety-rule phrasing.

Compatibility: Compatibility: Microsoft Entra ID conditional access, Okta, and other IdPs with policy engines; workload identity options vary by cloud.

## Why it happens
MFA exists to prove a human presence, so an automation account hitting an MFA wall means the identity architecture has not decided how this automation should authenticate. The tempting hacks (a phone left logged in, a shared TOTP seed in a script) destroy the assurance MFA provides and usually violate policy. The legitimate patterns are well established: strong certificate or key-based first factors, tight network scoping, least privilege, and full logging, approved and owned by the identity team.

## Edge cases / pitfalls
- Policy exceptions for service accounts should be as narrow as the automation footprint: named source addresses, named applications, named times if the platform supports it.
- If the IdP offers phishing-resistant workload credentials, prefer them over password plus exception.
- Review the exception when the automation scope changes; yesterday narrow exception around today broader agent is a common audit finding.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0L7RwzjCekqigIBZrhe1-A