## TL;DR
E0000004 is Okta's generic "credentials presented but rejected" for the authentication pipeline. For service accounts, figure out which leg failed: the API token leg or the user auth leg. Fix that leg and re-run.

```text
"E0000004 authentication failed" Okta API service account
```

## Use this when
- The errorCode is E0000004 on a service account flow.
- You are unsure whether the token or the account itself is at fault.
- The failure appeared after a password rotation or policy change.

## Not for this skill when
- The errorCode is E0000011. That is specifically an invalid token.
- The call authenticates but is denied. That is authorization, not authentication.
- A human user fails interactive login. Check the user-focused login skills instead.

## Steps
1. Determine which leg failed: API token calls versus username and password auth. Verify: you can reproduce the failure on one leg only.
2. For the token leg, follow the E0000011 rotation path: verify the value, confirm it exists, rotate if needed. Verify: a test call returns 200.
3. For the user leg, check the account is active and unlocked in the admin console, then reset the password per policy. Verify: the account status is ACTIVE.
4. Confirm the service account holds the admin role the integration needs. Verify: role assignment is present.
5. Re-run the original flow end to end. Verify: no E0000004 anywhere in the System Log for the account.

## Variant phrasings
### Okta 401 authentication failed
The status-first search.
### service account locked out
One common underlying cause.
### E0000004 on token auth
The code-specific phrasing.

Compatibility: Okta authentication pipeline, Classic and Okta Identity Engine. Covers API token auth and service-account password auth.

## Why it happens
E0000004 is deliberately generic: it covers bad passwords, locked accounts, dead tokens, and policy-blocked auth without saying which. The System Log event around the timestamp names the actual failing check.

## Edge cases / pitfalls
- Password-expiry policies applied to service accounts that nobody monitors.
- Sign-on policies blocking the service account's source IP or network zone.
- MFA policies accidentally scoped to include the non-human account.
- The account deactivated by an offboarding workflow that did not know it was a service account.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_iunuf4-7G_EuQsYhqfCpPQ