What Is trustd on Mac? The Certificate Trust Daemon Explained

trustd is the certificate trust evaluation daemon built into macOS. It is a system process shipped and code-signed by Apple, and its job is to decide whether the digital certificates presented by servers your Mac connects to should be trusted.

Every time something on your Mac makes an HTTPS or TLS connection, the server presents a certificate chain: its own certificate, usually one or more intermediates, and ultimately a root certificate that is supposed to be one your system already trusts. Somebody has to check that chain. That somebody is trustd. It evaluates whether the certificate is validly signed, whether it has expired, whether it has been revoked, and whether the chain terminates at a root your Mac genuinely trusts.

This work is not done per app. Rather than every browser, mail client, updater and Electron app implementing its own certificate logic and getting it subtly wrong, macOS centralises trust evaluation in one system service. That is why trustd looks busy: it works on behalf of essentially every network-capable process at once. A page load in Safari, a Mail check, a file sync and a background update can all trigger trust evaluations in the same second.

You will usually see it as trustd running as a system-level process, sometimes alongside a per-user instance. Both are normal. It is not something you installed and not something you can meaningfully remove.

This is the part that alarms people, so it is worth explaining plainly. Checking whether a certificate is validly signed can be done offline, using math alone. Checking whether a certificate is still valid right now cannot.

Certificates get revoked. A server's private key is stolen, a certificate authority issues something in error, a company loses control of a domain. In all of those cases the certificate is still cryptographically well-formed and still inside its stated validity dates, but it should no longer be trusted. The only way your Mac can know that is to consult data published elsewhere, and that means a network request.

So trustd contacts Apple infrastructure for certificate revocation and validity information, in the general family of OCSP-style status checking, along with Apple's own validation services and certificate-transparency-related data used to detect certificates that were issued but never should have been. When you see trustd connecting to Apple domains repeatedly, that is what those connections are. It is a security lookup, not a report about you.

Apple also caches this data, which is why the pattern is bursty rather than perfectly proportional to your browsing. Expect a cluster of connections after a reboot, after a long idle period, or when you visit sites you have not seen recently, and comparatively little in between. The same underlying trust and validation stack also supports other macOS checks around signed and notarized software, though the specifics of how those pieces interact are Apple's to document.

No. trustd is a first-party Apple system daemon and a documented part of macOS security. There is no version of a healthy Mac that lacks it.

That said, taking an article's word for it is exactly the reasoning malware relies on, so it is reasonable to verify on your own machine. Two things are worth confirming, and neither needs special tools.

The first is location. Apple's system daemons live inside protected system paths; trustd's executable sits in the system usr/libexec area, which on modern macOS is on the read-only signed system volume that malware cannot write to. In Activity Monitor, select the process and open the inspector to see its reported path. Something named trustd running from your home folder, a downloads directory or an unfamiliar app bundle would be a genuine red flag. Running from the system volume, it is the real one.

The second is the signature. macOS can tell you who signed a running binary, and Apple's daemons are signed by Apple with system entitlements. Right path plus Apple signature means you are looking at the operating system. It also helps to read the process name carefully rather than glancing at it, since impostors typically choose names that are close but not identical.

One more reassurance: high CPU or steady network activity from trustd is not evidence of compromise. It means a lot of TLS connections are being evaluated, which on a normal Mac is simply what happens.

You can technically block trustd with a firewall. You should not. Of all the background macOS processes people are tempted to silence, this is one of the few where blocking actively makes your Mac less safe rather than more private.

Certificate validation is a core security control. It is the mechanism that stops your Mac from silently accepting a revoked certificate or a chain that leads nowhere trustworthy. Degrade it and you degrade the guarantee that the encrypted connection you think you have with a server is actually with that server.

The practical consequences arrive quickly: HTTPS connections that fail outright, connections that hang while the system waits on a validation lookup that will never arrive, vague certificate errors in unrelated apps, sign-in flows that stop working. Because trustd sits underneath almost everything, the symptoms rarely point back to the cause. You get a Mac that feels broken in scattered ways rather than an obvious warning.

The honest privacy nuance is this: revocation and validity checking does inherently tell the service performing the check that some certificate was validated at some point in time. That is a real property of how this class of mechanism works, not a hidden one. Apple has published information about how it handles this traffic, and that documentation is the right source for specifics rather than speculation. It is also worth noting that certificate and notarization-related checking on macOS drew broad public attention some years ago when an Apple service problem caused noticeable slowdowns when launching apps, after which Apple changed aspects of how these checks operate. The takeaway is not that the mechanism is sinister, but that it is load-bearing enough that everyone notices when it struggles.

So monitor trustd if you want to understand your machine. Do not block it.

The anxiety trustd generates has very little to do with trustd. It is that a raw connection log is nearly unreadable. A process you did not start is contacting a domain you do not recognise at a frequency you cannot explain, and that description fits certificate validation, crash reporting, update checks and analytics SDKs equally well.

So people either ignore everything, which means real tracking goes unnoticed, or block on instinct, which is how machines end up with mysterious HTTPS failures. Both come from the same missing piece: context about which process is talking, where to, and whether that destination is known infrastructure or a known tracker.

That context is what NetMute provides. It shows real-time per-app and per-process traffic, so a connection is attributable to trustd rather than anonymous. Domain-level logging records which domains a process contacted, when, and how much data moved, turning "something is talking to Apple" into a checkable record. Tracker Shield maintains a categorised list of over 1,100 known tracker domains, so genuine tracking is distinguishable from ordinary system traffic instead of buried in it. And when you do find something that should not be talking, the per-app firewall offers one-click blocking plus self-expiring temporary rules, so you can test whether blocking breaks anything before committing.

Applied here, the workflow is short. Look at trustd, see it contacting Apple validation infrastructure, confirm it is on no tracker list, leave it alone. Then point the same view at the app you actually had a question about, because it is rarely the system daemon.