coreauthd Is Asking for Your Password. Now What?

The process is Apple’s authentication broker, not a mystery intruder. The useful question is which app triggered it—and why it keeps asking.

By CoreGuard · Jul 11, 2026 · 11 min read

What is coreauthd on Mac?

coreauthd is Apple’s LocalAuthentication daemon: the system broker behind many Touch ID, Apple Watch, and password authentication prompts on a Mac. It maintains authentication contexts and presents the system-controlled interface; it is not an app you installed and not a process you should run directly.

That definition comes from Apple’s supplied coreauthd(8) manual, whose description is unusually concise for macOS plumbing. Apple’s LocalAuthentication documentation fills in the user-facing part: an app can ask macOS to authenticate the device owner, and macOS may use Touch ID, a paired Apple Watch, or the user’s password.

Think of coreauthd as the desk between an app and the authentication mechanisms. The app makes a request. The operating system decides which approved method is available, displays trusted UI, evaluates the result, and returns success or failure. The app should not receive your fingerprint data. It receives the outcome of the policy evaluation.

That is why coreauthd appears in Activity Monitor around actions such as revealing a saved password, changing a protected setting, authorizing an app operation, or unlocking something guarded by LocalAuthentication. Its presence is normal. Its context is what matters.

What does a coreauthd password or Touch ID prompt mean?

A standard LocalAuthentication prompt means some software asked macOS to confirm that you are the device owner. It does not automatically mean the requesting app wants your Mac login password as data.

Apple’s documentation for evaluatePolicy says the app supplies the short reason shown in the authentication dialog. On macOS, the app name also appears in the dialog title. Read both. “Unlock saved passwords” after clicking a password field makes sense. “Approve account change” while you are doing nothing deserves Cancel.

The system may offer different methods for the same request. Apple reports that its device-owner policy can try Touch ID and a paired Apple Watch, then fall back to the user’s password when those methods are unavailable. Apple Support also reports that macOS requires the password periodically—including after a restart, after a reported 48 hours, and after five incorrect fingerprint attempts—so a password fallback is not evidence that Touch ID has been compromised.

There is an important distinction:

• A LocalAuthentication dialog asks you to prove you are the Mac’s user.
• A Keychain Access dialog asks permission to retrieve or unlock something stored in a keychain.

They may appear near the same action, but they are not interchangeable. Read the nouns before entering a password. macOS has several security dialogs, and vague pattern-matching is how people train themselves to approve the wrong one.

What does a “wants to use the login keychain” prompt mean?

That wording is a Keychain Access prompt — one of a family that reads “…wants to use the login keychain,” with macOS filling in the requester’s name. Apple’s Keychain Access guide says such a dialog appears when an app, server, or other item tries to retrieve a password from the keychain and macOS needs your permission. In reports of this dialog, examples of the named requester include system processes such as accountsd and assistantd.

If the requester shown is coreauthd, the immediate requester is Apple’s authentication broker. Either way, the dialog names only the immediate requester; it does not tell you which front-end app or action caused that process to ask.

The timing is therefore valuable evidence. Ask three dull questions:

1. What did I click immediately before the prompt?
2. Does the prompt’s reason match that action?
3. Does it stop when I cancel the action or quit the app that initiated it?

If you deliberately asked a password manager to reveal a secret, “Allow Once” is a cautious test. Apple defines that choice as access for the current request only. “Always Allow” changes future behavior, so I would not use it merely to make a confusing prompt disappear.

If the prompt arrived without an action you recognize, choose Deny or Cancel. The requested operation may fail. Your Mac will survive the disappointment.

Why does coreauthd use high CPU?

CPU activity during authentication is not surprising. coreauthd is evaluating a policy, coordinating available authentication methods, presenting UI, and returning a result. A short appearance near the top of Activity Monitor while a prompt is open tells you the process is working, not that it is malicious.

The suspicious pattern is not one isolated percentage. It is persistence and repetition:

• coreauthd remains busy after the prompt has closed.
• The same prompt returns without a new user action.
• CPU rises each time one particular app becomes active.
• Canceling the prompt causes that app to request it again.
• The behavior began after an app or macOS update.

Apple says LocalAuthentication policy evaluation is asynchronous and can present authentication UI on each attempt. From that documented behavior, the practical inference is straightforward: repeated prompts can mean a caller is creating or retrying authentication requests in a loop.

That caller may be a third-party app, an Apple app, a browser handling a passkey, a password manager, or a system setting. High CPU does not identify which one. It only gives you a clock: something is asking the authentication layer to work right now.

Do not invent a threshold such as “anything over 20% is malware.” Activity Monitor percentages depend on workload and CPU topology, and a momentary sample is a lousy diagnosis. Correlation beats a magic number.

Repeated prompts usually make the caller more interesting than the daemon

When one prompt becomes six, I stop staring at coreauthd and start looking at what keeps summoning it.

First, cancel the prompt once and write down the foreground app and exact action. Then reproduce the action deliberately. If the prompt returns only when that app opens a protected view, you have a useful lead. If it appears at login before you open anything, inspect login items and background items in System Settings.

Activity Monitor can show whether the CPU spike tracks the prompt. Terminal gives you a timestamped snapshot:

pgrep -x coreauthd
ps -axo pid,ppid,%cpu,etime,command | grep '[c]oreauthd'

Next, inspect recent LocalAuthentication logging:

log show --last 10m --style compact \
  --predicate 'process == "coreauthd" OR subsystem BEGINSWITH "com.apple.LocalAuthentication"'

The unified log may expose a bundle identifier, connection lifecycle, cancellation, or repeated evaluation. It may also redact the detail you wanted. That is an honest limit, not permission to guess.

Do not paste the raw log into a public forum without reading it. Authentication logs should not contain your password, but they can reveal app identifiers, usernames, account context, or other machine-specific metadata.

A useful test is to close suspected third-party apps one at a time and repeat the original action. If the prompt storm stops after one app is gone, update that app and report the reproduction to its vendor: macOS version, app version, action, whether Touch ID or password was offered, and whether the loop survives a reboot. Evidence travels better than “coreauthd is broken.”

How to verify that coreauthd is Apple’s process

On a current macOS installation, Apple places the binary here:

/System/Library/Frameworks/LocalAuthentication.framework/Support/coreauthd

Check the running command rather than trusting the name:

PID="$(pgrep -x coreauthd | head -n 1)"
ps -p "$PID" -o pid=,ppid=,%cpu=,etime=,command=

A copied executable can call itself coreauthd. The signature is the stronger check. Apple’s Code Signing Guide documents codesign verification and says the requirement anchor apple means code signed by Apple.

Verify the running process against both Apple’s signature anchor and the expected identifier:

codesign -vvvv \
  -R='identifier "com.apple.coreauthd" and anchor apple' \
  "$PID"

Then inspect the installed binary’s designated requirement:

COREAUTHD=/System/Library/Frameworks/LocalAuthentication.framework/Support/coreauthd
codesign -d -r- "$COREAUTHD" 2>&1

The requirement should identify com.apple.coreauthd and contain anchor apple. Apple’s code-signing documentation explains that the identifier and signing requirement—not a friendly filename—are how macOS distinguishes genuine code from an imitation.

You can also look for the service in your launchd domain:

launchctl print "gui/$(id -u)" | grep -i -B 4 -A 12 coreauth

Do not overread an empty result — it usually means you searched the wrong string. launchd registers the service as com.apple.CoreAuthentication.daemon (system domain) and com.apple.CoreAuthentication.agent (per-user gui domain); the literal name coreauthd never appears in the listing, and the process typically runs continuously rather than on demand.

These tests answer one narrow question: is this the Apple-signed coreauthd binary? They do not prove that the app requesting authentication deserves approval. A legitimate security broker can still be carrying a request you did not expect.

If the path is outside Apple’s framework directory, or dynamic signature verification does not satisfy the explicit Apple requirement, stop entering credentials. Do not download a replacement binary from a search result. Apply macOS updates and take the evidence to Apple Support or a qualified administrator.

Check the login keychain before blaming LocalAuthentication

Repeated keychain prompts have another common explanation: the login keychain is locked, or its password is no longer synchronized with the user account password.

Apple’s current troubleshooting guide reports both conditions. Apple also says the login-keychain password normally matches the Mac login password. After certain password resets or migrations, the old keychain may still expect the previous password.

That produces an ugly loop: an authentication-related action needs a keychain item, the keychain remains locked, and the next attempt asks again. The repetition can look like a runaway daemon even though the underlying problem is a credential mismatch.

Open Keychain Access and inspect the login keychain’s lock settings. If you recently changed or reset the account password, follow Apple’s keychain-password guidance rather than trying random passwords indefinitely.

Do not casually choose “Reset Default Keychains.” Apple warns that resetting deletes the passwords stored in the old default keychain and recommends doing it manually only when advised by Apple Support. That is not a first diagnostic step. It is the option with consequences.

Why I do not tell you to kill coreauthd

CoreGuard’s July 11, 2026 search review found a How-To Geek article dated December 13, 2017 still holding the first result. To be fair to it: the article calls coreauthd not nefarious, and its only concrete remedy is conditional — “If you suspect it’s crashed you can try killing it using Activity Monitor.”

Even on those conditional terms, killing the broker may dismiss a stuck prompt. It also destroys the live evidence, interrupts legitimate authentication, and leaves launchd free to start the service again. That is symptom removal dressed as diagnosis.

Apple’s coreauthd(8) manual explicitly says the command should not be run directly. I would extend the same restraint to sudo pkill coreauthd: do not make the system authentication daemon your first target when the interesting defect may be the app repeatedly calling it.

Find the caller. Check the keychain state. Verify the signature. Keep the evidence.

What CoreGuard can show—and what it cannot

This is the sort of problem that pushed me toward CoreGuard: a system process becomes visible only after it is already noisy, while the actual pattern is spread across CPU activity, time, and user context.

CoreGuard’s free tier shows live CPU, GPU, RAM, temperature, and fan readings; names the top resource-consuming app or process in plain English; and keeps basic history with threshold alerts. Every danger warning stays free. If coreauthd suddenly becomes the top CPU process, you can see the event and when it started without buying the right to know something is abnormal.

The limit matters: CPU attribution can name coreauthd, but it cannot honestly infer the originating app from CPU usage alone. Authentication boundaries and redacted logs exist for good reasons. CoreGuard does not manufacture a culprit or display a fake verdict when macOS has not exposed enough evidence.

Pro adds per-app energy detail, CSV/JSON sensor-log export, and the ability to quit runaway processes. That last tool is not an invitation to terminate coreauthd; use it on a confirmed misbehaving third-party caller, not Apple’s authentication broker. Pro is a one-time $29 purchase, while the abnormal condition and basic history remain visible for free.

CoreGuard is local-only and makes zero network connections. It observes and explains; it never cleans, optimizes, or changes your authentication configuration. The app is pre-launch for macOS 13 and later on Apple Silicon and Intel, and will be distributed as a Developer-ID-signed and Apple-notarized .dmg.

For now, the honest CTA is to get notified or review the pricing. Meanwhile, Activity Monitor, codesign, launchd, and a notebook are enough to answer the useful question: not “How do I kill coreauthd?” but “Who keeps asking it to authenticate me?”