What is accountsd on Mac, and why is it using the network?

Last updated: 2026-07-31

What it is

accountsd is an Apple per-user launch agent that supports account storage and account-access services in macOS. Its genuine executable is identified as com.apple.accountsd and is found at /System/Library/Frameworks/Accounts.framework/Versions/A/Support/accountsd.

The agent manages account records and credential-related operations for Apple and Internet Accounts. It also brokers account access for macOS components and permitted apps. “Brokers” is important here: account access is mediated and depends on the account and provider involved. This is different from giving every application unrestricted access to every credential stored on the Mac.

The limits of the public documentation matter too. Apple documents an Accounts database, mediated account access, account credentials, and credential renewal. However, Apple does not publicly describe accountsd as the sole manager of every signed-in account, every login operation, or all network traffic connected with those accounts. The public Accounts framework documentation is deprecated and should not be treated as a complete specification of the daemon’s current private implementation.

accountsd concerns Apple and Internet service accounts. It is not the component that manages local macOS login users.

Why it talks to the network

Network connections from accountsd can be part of account authentication and credential maintenance. Activity may occur after an account is added or changed, when stored credentials expire or become invalid, or when another component requests that a credential be renewed.

The destination depends on the account involved. Possible categories include Apple Account or iCloud identity services, as well as authentication or token endpoints operated by configured providers such as Google, Exchange, or Yahoo. These are categories, not a verified list of hosts. Apple does not publish an endpoint list for accountsd, so a specific domain should not be assigned to the process without observing and verifying the connection.

Process ownership also has an important uncertainty. A connection associated with an account operation might be made directly by accountsd, but a provider-specific helper might perform it instead. Public information does not establish which process makes every provider request. A network event should therefore be attributed to accountsd only when the available process-level evidence actually identifies it.

The traffic should likewise not be assumed to represent the full contents of Mail, Photos, or iCloud synchronization. Service-specific apps and daemons commonly handle those larger payloads, although the exact division of work can vary with Apple’s private implementation.

How much traffic is normal

Apple publishes no normal traffic baseline or reliable byte range for accountsd. Any precise claim that the process should use a particular number of kilobytes or megabytes would be unsupported.

Based on its verified role, expected activity is intermittent control traffic for account operations, authentication, and credential renewal. It would generally be smaller than bulk transfers performed for Mail, Photos, or iCloud Drive, but that is a description of its expected role rather than a measured allowance. It cannot be converted into a trustworthy daily or monthly threshold.

A short period of activity can coincide with adding or changing an account, an expired credential, or a renewal request. Sustained activity deserves investigation for repeated authentication attempts or continuing account changes. It should be examined alongside those events rather than declared abnormal merely because it exceeds an invented MB limit.

Can you turn it off

The practical verdict is to keep accountsd running. Apple provides no supported System Settings switch for disabling the launch agent itself, so there is no daemon-level settings path to follow.

Force-disabling it can disrupt account discovery and account changes. It can also interfere with access authorization, credential renewal, authentication, and synchronization in apps that rely on Apple or Internet Accounts. Because its work is shared by account-dependent system components and permitted apps, the visible symptom may appear in another application rather than as an error bearing the accountsd name.

Individual external accounts can be controlled without disabling the agent. The supported path is System Settings > Internet Accounts > [account], where a feature can be turned off or the account can be removed with Delete Account. That changes the selected account or its enabled features; it does not turn off accountsd.

What people get wrong

• “accountsd is malware.” The name alone is not evidence of malware. The genuine Apple executable is code-signed with the identifier com.apple.accountsd and resides at /System/Library/Frameworks/Accounts.framework/Versions/A/Support/accountsd. A similarly named executable elsewhere is not automatically genuine and needs its own verification.

• “It is just a disposable performance service.” There is no Apple-supported global off switch for the daemon. Force-disabling it can break account authentication, credential renewal, account changes, and applications that depend on Apple or Internet Accounts.

• “It manages the users who log in to this Mac.” It does not manage local macOS login users. Its documented framework context is Apple and Internet service accounts.

• “It hands every saved password to every app.” Account access is mediated and specific to the account and provider. That does not mean all credentials are exposed indiscriminately. At the same time, Apple has not publicly documented the daemon’s complete private credential-handling design, so claims about every internal step would go beyond the available evidence.

• “All traffic assigned to accountsd is complete Mail, Photos, or iCloud content synchronization.” That attribution is too broad. Large content payloads are commonly handled by service-specific apps and daemons. Exact ownership remains implementation-dependent, and a provider-specific helper may make some account-related connections instead of accountsd itself.

Seeing what it actually used

The next step is to check real per-process usage instead of comparing accountsd with a generic MB rule. In Bytetally’s per-process statistics, find accountsd and review its measured activity around account changes, credential failures, or renewal requests. Sustained usage can then be investigated in its actual context rather than judged against a baseline Apple has never published.

Related processes

Common questions