I wonder what secd process does under OSX Yosemite. I am pretty sure I have seen this process running in earlier MacOS versions, but I don't remember it gobbling up all the available memory so boldly...

I have three computers running Yosemite, each with a different config. All three have been up for a duration of three days to one week. Here is a run down of what secd has achieved:

  • On MacBookAir 2011 with 4GB of memory, 700MB allocated to secd
  • On iMac 2008 with 6GB of memory, 2GB allocated to secd
  • On iMac 2011 with 12GB of memory, 4GB allocated to secd

On all three computers secd is the largest process in memory (larger than kernel task) and I suspect it plays a role in the slowdown I have recently experienced with the arrival of Yosemite. I know for sure that the process expands in memory to inordinate sizes and frees up memory when I need it somewhere else. The only issue is that it is not as quick in freeing up memory and most of the time performance suffers before the process realizes it has to retreat.

My search around the web didn't come to a solid conclusion as for what the process is, and why it should be so huge. I guess I am not the only one experiencing this. Any tip is appreciated.

As suggested below secd has to do with Apple Keychain. Here are the files and ports that the process keeps open when active (on MacBookAir):

count=2, state=0x2

What is not clear is what the process does to all the memory it occupies, and why it inflates so much.

  • 2
    Your memory is right. secd runs on Mavericks. On fast analysis, this daemon isn't documented, this is bad, this might be a piece of crapware. This daemon is in /usr/libexec/secd.
    – dan
    Commented Dec 7, 2014 at 21:33
  • @danielAzuelos Does it show the same cancerous behavior on Mavericks? Commented Dec 7, 2014 at 22:09
  • 2
    According to the Plist secd is used to manage the cloud keychain not the local one.
    – Ruskes
    Commented Dec 8, 2014 at 0:29
  • 3
    Just discovered: Without secd running, Messages asks me for a password every time. Commented Dec 8, 2014 at 23:05
  • 1
    → Mah: on Maveriskc, secd has a VSZ = 2.4 GB, and a RSS = 3 MB. secd ran for 84 s on a system which is up and running since 5 days.
    – dan
    Commented Dec 8, 2014 at 23:18

4 Answers 4


If it's not apparent, this is just a guess. But hopefully it gives you some leads.

First, here's what you can figure out just from the program name. If you run the command /bin/ls /usr/libexec | sort -f | egrep '.*d$' (this print all files in /usr/libexec ending in d), you'll find ftpd, hidd, networkd, systemstatsd, and a lot of programs ending in d. The "d" stands for "daemon", which basically means a helper process that always runs in the background. The sec very likely stands for "security". So secd is the "security daemon". Which makes sense because you said it looks like it works with keychain stuff.

What's the point of daemons? Some daemons stay running to either do some ongoing task. hidd ("human interface device daemon"), for example, is the process responsible for handling mouse/keyboard/trackpad input. Some other daemons do some common tasks that many other programs need. Apps can simply tell the daemon to do something instead of having code to do it themselves. So secd probably does something like this, but related to the keychain.

But what exactly? It looks like it doesn't actually handle normal use of the keychain, since I was still able to use the keychain after I disabled the secd LaunchAgent.

Inspecting the LaunchAgent gives us a clue:

It looks like secd is responsible for syncing the keychain with iCloud?

So what should you do? Try one or more of these:

  1. If you don't need iCloud keychain syncing, turn it off in iCloud preferences.
  2. Use launchctl to disable secd if it doesn't seem to adversely affect anything.
  3. If you need iCloud keychain syncing, see if you have a ton of keychain items, and remove the ones you don't need.
  4. Perhaps rebuild your keychain (make a new keychain, move items you need into it, and move it over the older one), in case there are unnecessary artifacts left over in the old keychain.
  • This is awesome detail. Step 2 should have an asterisk - make a note that you disabled this since Apple will usually add some new feature to this and your Mac will break when that happens, so remember to turn it back on from time to time and revisit the decision to disable a system daemon.
    – bmike
    Commented Mar 2, 2018 at 14:26
  • Again - fantastic answer that explains how to reverse engineer any daemon and not just this one that’s not documented well.
    – bmike
    Commented Mar 2, 2018 at 14:27

The program /usr/libexec/secd is shipped as part of OS X and is a normal security process. The documentation says it relates to "runtime security policies for processes". You can inspect the associated processes with this command: ps -ef|grep sec[iud]

On my Mac, I'm user 501 so you have this output for one user logged in:

Mac:~ bmike$ ps -ef|grep sec[iud]
    0    58     1   0 Sat12PM ??         0:56.51 /usr/sbin/securityd -i
    0   117     1   0 Sat12PM ??         0:00.15 /usr/libexec/secinitd
    0   171     1   0 Sat12PM ??         0:02.24 /usr/libexec/securityd_service
  501   205     1   0 Sat12PM ??         0:11.74 /usr/libexec/secinitd
  501  2634     1   0 Tue08PM ??         0:08.26 /usr/libexec/secd

You can see that securityd is started as root (PID 58) and then as a user (PID 205) process when you log in. The actual secd carries out the "work" and can get respawned even when you do not log out and in. As to deciphering why yours is using extra resources, it will be quite hard without digging into fsusage and some other commands to peek at running processes as well as looking over your log files. Your best bet would be to file a bug with Apple and then document how you can get it to misbehave - especially if you can reproduce it after a reboot.

There isn't currently a "man page" for secd and the one for secinitd is meager at best. Filing documentation bugs against Apple is one way to ask that the lack of documentation be remedied.


From what I know about that process (which really isn't a ton) is that it has something to do with the Mac's Keychain. What you can do is find in in the Activity Monitor and click Cmd+I to get the info about it.

One tip you can try to do is run the Keychain First Aid by going to Keychain Access in Spotlight, opening the "Keychain Access" menu, and selecting the "Keychain First Aid" option from there and follow the directions.

Hope that tip works!

  • Keychain First Aid says my keychain is fine! On all three computers. Commented Dec 7, 2014 at 22:06
  • There is an option in El Capitan (at least, may be there in previous versions as well) under Keychain Access - Preferences to Reset My Default Kechain "Reverts to factory defaults and creates a new empty "login" keychain. Your current default keychain will be moved aside, but not deleted". As soon as I did this the securityd_service went from 51-53% CPU to 0-1.5%. As soon as you do you're required to re-sign in to iCloud - I haven't yet discovered other ramifications. Commented Aug 13, 2016 at 22:23
  • 1
    I just upgraded from Mavericks to Sierra and found that the secd CPU went from near 100% after resetting the keychain as you suggested. Lost all my saved website passwords, had to re-login to my calendar sync, etc., but at least I can use the computer again. Thanks. Commented Oct 27, 2016 at 17:48

Start turning on the Keychain iCloud sync but cancel on another dialog window.

source: https://www.reddit.com/r/hackintosh/comments/54gpmo/process_secd_always_at_95100_cpu_usage_sierra/d88v542/

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .