Help CenterSmart Card

Digital Signature Not Working on Windows 11 — Full Stack Diagnostic After Feature Updates

9 min readWritten by Sachida N Sharma, Senior PKI Consultant (ex-Railtel / NIC) · Updated June 2026

Quick Answer

If your digital signature stopped working after a Windows 11 update, the update almost certainly reset PKI settings — the Smart Card and Certificate Propagation services flip back to Manual and third-party token drivers lose their registration. Set both services to Automatic and Running, run your token middleware's Repair option, replug the card, and fully restart the browser.

15–30 min Intermediate
🇺🇸 Get US same-day remote help fixing Windows 11 signing after an update

Symptom fingerprint

The exact strings, error codes, and UI surfaces that map to this issue:

UI messageSurfaceCode
Digital signature could not be appliedAcrobat / DocuSign / Office signing UI
Smart card service not runningservices.msc after 23H2/24H2 upgradeSCardSvr Manual
Certificate appears in certmgr but not in DocuSignCurrentUser\My present, signing app blind

Why Windows 11 updates break signing

Windows 11 feature updates (23H2 in late 2023, 24H2 in 2024) quietly reset several PKI-relevant settings. The Smart Card and Certificate Propagation services return to Manual instead of Automatic, third-party CSPs occasionally lose their registry registration, and the WUDF driver host gets reinstalled — which can re-claim USB CCID devices from your vendor's middleware.

The result is a token that worked perfectly on Friday and throws signing errors on Monday, with nothing having changed except an update you didn't consciously install. Almost every case resolves at the local layer; you rarely need to roll anything back.

  • Smart Card / Certificate Propagation services flipped from Automatic back to Manual.
  • Vendor CSP/KSP registration dropped, so Windows falls back to a generic driver that can't sign.
  • Browser or app caching a pre-update credential enumeration, so it stays blind even after the fix.

Step-by-step fix

Work these in order — the first step alone resolves a big share of post-update cases.

[IMAGE: services.msc showing SCardSvr and CertPropSvc both Running with Startup type Automatic — alt text: "Windows Services window with Smart Card and Certificate Propagation services running and set to automatic"]

  • 1. Reset the PKI services. Open services.msc → Smart Card (SCardSvr) and Certificate Propagation (CertPropSvc): set both to Startup type Automatic and Start them. In an admin PowerShell: Set-Service SCardSvr -StartupType Automatic; Start-Service SCardSvr (repeat for CertPropSvc).
  • 2. Repair the token middleware. Reinstall or run the "Repair" option in SafeNet Authentication Client / IDPrime / ePass to re-register the CSP/KSP the update dropped.
  • 3. Replug the card or token so Windows re-enumerates it under the vendor driver rather than the generic one.
  • 4. Confirm the certificate store scope. certmgr.msc → Personal → Certificates must show the certificate under Current User — signing apps read CurrentUser\My, not Local Machine.
  • 5. Fully restart the browser or app. Chrome: chrome://restart. Edge: close every window. Acrobat/DocuSign desktop: quit completely, then reopen so it re-reads CAPI.
  • 6. Re-sync the clock. Run w32tm /resync, or Settings → Time & language → Date & time → "Set time automatically".

Signing in one app but not another?

If certmgr and certutil see the certificate but only one application is blind, the problem is app-layer caching or a managed policy — not the token. Worth a quick human aside: the most stubborn case I've hit was an Edge tenant page stuck in IE Mode that simply refused to enumerate the token until IE Mode was turned off for that site.

  • DocuSign/Acrobat blind but CAPI sees it: fully restart the app; enumeration caches per session.
  • Managed browsers can hide the signing extension via Group Policy — check Edge/Chrome managed extension policies.
  • Firefox keeps its own PKCS#11 store; after an update, re-load the token module under about:preferences#privacy → Security Devices.

Still not working?

Windows 11 signing is a stack of six to eight independent layers — USB → service → middleware → CSP → CAPI store → app enumeration → browser cache → clock. When the quick fixes above don't land it, the fault is usually buried in one specific layer, and the diagnostic sequence below walks each one so you can stop at the first failing expectation.

Be wary of anyone offering a single "magic" registry fix for this — there isn't one. If you'd rather not work through eight layers alone, I can run the sequence with you on a screen-shared session and deliver a written note on exactly which layer failed and why.

Windows vs macOS — what differs

Windows 10 / 11

  • Run the SCardSvr / CertPropSvc check first — it resolves 30%+ of post-update cases.
  • Re-run the vendor middleware installer 'Repair' option — fastest way to re-register CSP/KSP after an update.
  • Check for stuck WUDF instances: Device Manager → View → Devices by connection → look for duplicate Usbccid entries.

macOS Sonoma / Sequoia

  • Sonoma 14.4 and Sequoia introduced stricter SmartCard pairing — first insertion after update prompts for pairing approval that must not be dismissed.
  • Run 'sc_auth list' to confirm pairings; re-pair with 'sc_auth pair' if missing.

Browser-specific behaviour

  • Chrome

    After Windows feature update, restart Chrome fully (chrome://restart) before concluding the token is broken — Chrome caches the CAPI enumeration.

  • Edge

    Same — Edge caches as well. Restart fully, not just close-and-reopen the tab. Disable IE Mode for signing sites.

  • Firefox

    Windows update can remove the previously-loaded PKCS#11 module from Firefox's Security Devices list. Re-load manually.

Diagnostic sequence

Run each step in order. Stop at the first failing expectation — that's where the root cause lives.

  1. 1. Confirm services

    Get-Service SCardSvr,CertPropSvc | Format-Table Name,Status,StartType

    Expected: Both Running, both Automatic.

  2. 2. Confirm middleware tray

    Expected: Vendor middleware (SAC, IDPrime, ePass) shows token as Inserted / Logged In.

  3. 3. Confirm CAPI enumeration

    certutil -scinfo

    Expected: Reader, token serial, and certificate(s) listed.

  4. 4. Confirm app-layer visibility

    Expected: Open DocuSign signing panel or Acrobat → Sign with Certificate → certificate appears in the chooser.

  5. 5. If app blind but CAPI sees it — restart the browser/app fully

    Expected: Re-enumeration triggers on next launch.

  6. 6. Confirm clock

    w32tm /query /status

    Expected: Last successful sync within last 24h, offset < 5s.

Frequently asked questions

Why did my digital signature stop working after a Windows 11 update?

Feature updates reset PKI settings: the Smart Card and Certificate Propagation services go back to Manual, and vendor drivers can lose their registration. Set both services to Automatic and Running, run your token middleware's Repair option, replug the card, and restart the browser — that clears most cases.

Should I roll back the Windows 11 update to fix signing?

Almost never necessary. The service reset plus a middleware repair resolves the vast majority of post-update signing regressions in under 15 minutes, and rolling back just delays the same problem to the next update.

Why does my coworker's identical setup sign fine and mine doesn't?

Usually one of three things: their middleware was reinstalled after the update and yours wasn't, their certificate is under Current User while yours landed in Local Machine, or their browser was fully restarted post-update and yours is still caching the old enumeration.

Is there one command that fixes Windows 11 signing?

No. Signing runs through six to eight independent layers, and a real fix walks each one. Anyone selling a single one-line registry fix for this should be treated with suspicion.

Related services

Explore the consulting hub for this issue, or review session pricing.

You might also need

More fix guides in Smart Card and related areas.

Still seeing this error?

If these steps don't isolate the root cause inside your environment, an independent consultant can run a structured PKI diagnostic with you over a screen-shared session and deliver a written report identifying root cause, remediation, and — where relevant — the next responsible party (CA, internal IT, or software vendor).

Live supportBook a remote diagnostic →

Includes a written diagnostic summary. Independent consulting engagement — not affiliated with DocuSign, Adobe, or Microsoft.

Comments

Loading comments…

Leave a comment

Comments are reviewed before publishing.