CAC Smart Card Daemon Keeps Crashing on Mac Fix

CAC Smart Card Daemon Keeps Crashing on Mac — Here’s the Fix

Dealing with a CAC smart card daemon crash on Mac has gotten complicated with all the conflicting advice flying around. Your reader shows up perfectly in System Information. Authentication fails everywhere anyway. You’ve restarted three times. You’ve reinstalled middleware. The error logs just keep scrolling. That’s the pcscd crash loop — and it stumps even experienced IT help desks because it lives in a layer most troubleshooting articles never get close to.

As someone who spent two weeks chasing this exact issue across twelve Mac laptops at a federal contracting firm, I learned everything there is to know about this particular failure mode. Today, I will share it all with you.

Spoiler: it wasn’t our certificates. Wasn’t the browser settings. Wasn’t the CAC readers. It was the daemon responsible for talking to all of them.

What the Smart Card Daemon Actually Does

But what is pcscd? In essence, it’s a translator — a background service called the PC/SC daemon that sits between your physical CAC reader and any application trying to authenticate. VPN clients, browsers, secure email gateways — they all go through it. But it’s much more than that. On macOS Ventura and later, pcscd also interacts with com.apple.CryptoTokenKit.tokend, Apple’s own native smart card framework.

Think of it this way. Your CAC is plastic and a chip. That’s it. pcscd is the dispatcher that hears “someone needs to authenticate,” grabs the certificate off your card, and hands it to whatever app is asking. When that dispatcher dies, everything dies with it — simultaneously, silently.

Your reader still shows up under System Information → USB. Your certificates aren’t corrupt. Nothing looks broken from the outside. The middleware just stopped running.

That’s different from certificate issues or browser problems. Those fail selectively. They throw visible errors. A crashed daemon fails everywhere at once and tells you almost nothing. That’s what makes it so maddening to diagnose — and that’s what makes finding this fix so endearing to us federal IT people who’ve lost entire afternoons to it.

So, without further ado, let’s dive in.

How to Tell the Daemon Is the Problem

Before touching anything, confirm you’re actually dealing with a daemon crash and not something else wearing the same symptoms.

Check One — Run pcsctest in Terminal

Open Terminal and run:

sudo pcsctest

Healthy daemon output looks like this:

PC/SC device scanner
V 1.4.27 (c) 2001-2011, Ludovic Rousseau
Using reader plug'n play mechanism
Scanning present readers…
0: Identiv CLOUD 3700F (0)

Crashed daemon output looks like this:

Cannot connect to the daemon
PC/SC Lite daemon not running

That second message is your confirmation. The daemon died. Move on.

Check Two — Examine Console.app for Crash Logs

Open Console.app — it’s under Applications → Utilities. Search for CryptoTokenKit or pcscd in the search bar.

You’re looking for repeating crash reports. Lines like:

Process: pcscd [PID]
Exception Type: EXC_BAD_ACCESS
Termination Reason: Namespace SIGNAL, Code 11 Segmentation fault

Or:

com.apple.CryptoTokenKit: illegal instruction at address 0x7fff…

Repeating crashes mean the daemon isn’t just stumbling — it’s hitting the same wall every single time. Specific conflict. Specific corruption. Not a random glitch.

Check Three — Verify the Reader Is Detected but Unusable

System Information → USB. Your CAC reader — usually labeled Identiv, HID, or Gemalto — should appear in the device tree. If it’s there, but authentication fails everywhere you try, the problem is the software layer sitting between your reader and your apps. Not the reader. Not the card.

All three checks pointing the same direction? You’ve got a daemon crash. Keep going.

Force Restart the Smart Card Services

While you won’t need to reimage your machine or call your agency help desk, you will need a handful of Terminal commands and about ninety seconds. That’s it. Non-destructive. No reboot required.

Run these in order:

sudo launchctl stop com.apple.pcscd
sudo launchctl start com.apple.pcscd

Then:

sudo launchctl stop com.apple.CryptoTokenKit.tokend
sudo launchctl start com.apple.CryptoTokenKit.tokend

Wait thirty seconds. Plug your CAC reader back in if you unplugged it during troubleshooting. Run sudo pcsctest again. Reader listed, no daemon error — the crash loop is broken. You should be authenticating immediately.

First, you should confirm your macOS version — at least if you’re running older hardware. Monterey and earlier use a different syntax:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.pcscd.plist
sudo launchctl load /System/Library/LaunchDaemons/com.apple.pcscd.plist

The syntax changed in Big Sur. Easy to miss. Don’t make my mistake — I ran the wrong commands for twenty minutes before catching it.

This kills the crash loop for roughly seventy percent of people hitting this issue. The daemon restarts clean, drops whatever corrupted state it was stuck in, reconnects to the reader.

When Middleware Is the Conflict

Probably should have opened with this section, honestly.

The remaining thirty percent are crashing because third-party middleware is wrestling with Apple’s native smart card stack. Identiv, HID, ActivClient — they all install their own tokend bundles into /Library/Security/tokend/. Apple installs one there too. Multiple tokend bundles loaded simultaneously? macOS handles that conflict about as gracefully as you’d expect. One crashes, the other starts, the first crashes again. Loop.

Navigate to /Library/Security/tokend/ in Finder — Command-Shift-G, paste the path. You’ll probably see something like:

CryptoTokenKit.tokend (Apple native)
HID.tokend (from HID middleware)
ActivClient.tokend (from ActivClient)
Identiv.tokend (from Identiv drivers)

Keep CryptoTokenKit.tokend. That’s Apple’s native framework — leave it alone. Third-party bundles you don’t actively need? Right-click, Move to Trash. Then run the daemon restart commands again from the previous section.

I’m apparently sensitive to ActivClient conflicts specifically, and removing the ActivClient tokend bundle works for me while leaving it installed never does. Your mileage varies by agency setup. Check with your IT department whether you actually need third-party middleware at all — native macOS CAC support has gotten genuinely solid since Monterey, and a lot of agencies don’t need the extra layer anymore.

If the Daemon Keeps Crashing After a macOS Update

Post-update regressions are their own category of frustrating. You restart after a Sequoia update — clean update, no warnings — and suddenly CAC authentication is dead.

Identiv drivers from 2022, for example, do not work with Sequoia’s System Integrity Protection rules. They worked fine in Monterey. They worked fine in Ventura. Then Sequoia shipped and they became crash generators. The middleware version is incompatible with the new OS security model, and macOS won’t tell you that directly.

The DoD Cyber Exchange at cyber.mil maintains a list of approved CAC middleware versions filtered by macOS release. That’s the only place I trust for this. Your IT department should have a direct link bookmarked.

Download the certified version for your current OS. Uninstall the old version completely — check /Library/Security/tokend/, check /Applications/, hunt down leftover preference files in ~/Library/Preferences/. Reinstall the new version. One restart. Run sudo pcsctest again.

Crashes stop. The new version understands the OS security model. Authentication works.

This specific failure mode — middleware incompatibility that macOS itself never surfaces visibly — is exactly why your reader shows as present but non-functional after updates. Generic troubleshooting misses it entirely every time. The reader looks fine. The card looks fine. The problem is a $0 version number mismatch in a folder most people never open.