Your smartcard signs you into EMIS or SystmOne fine. You start to authorise a prescription, get prompted for the PIN, type it correctly, and the system rejects it. Same card, same PIN, same morning — works one minute, broken the next. Frustrating, especially when there’s a queue of scripts waiting.
You’re not the only one this happens to, and it’s almost always the same fix. Here’s what’s going on and how to clear it in the right order.
What you’re actually seeing
NHS smartcards do two jobs:
- Authentication — proving who you are when you log in to clinical systems. This is the bit that’s working.
- Digital signing — applying a non-repudiable signature to specific actions, like authorising prescriptions, Mental Capacity Act decisions, or pathology requests. This is the bit that’s failing.
The signing path uses different drivers and certificates to the authentication path, even though it’s the same card and the same PIN. So a card can sign you in correctly and still fail on signing — they’re not the same operation under the hood. That’s usually the first thing that throws people. The card is fine.
What’s most likely causing it
In our experience supporting NHS smartcard estates, three causes account for the vast majority of “PIN works to log in but not to sign” incidents. We’ve ranked them in the order we check.
1. Smartcard middleware (driver) out of date — by far the most common
The middleware is the bit of Windows software that translates between your physical smartcard reader and the clinical applications. NHS England pushes updates to it through the year, and signing breaks first when it falls behind because the signing path uses newer cryptographic libraries than the basic login path.
This is the cause we see about 8 times out of 10.
How to check: open *Settings → Apps* (or *Programs and Features* on older builds) and look for the smartcard middleware. The current supported version is published by NHS England — if the version on the machine is older than the current released version, that’s almost certainly the issue.
How to fix: uninstall the old version, download the current released version from the NHS smartcard portal, install it, restart the machine. The fix is usually that quick.
2. Certificate close to or past expiry
The signing certificate on the card has its own expiry, separate from the card’s main expiry. It typically lasts around two years and is refreshed automatically when the user authenticates from a properly configured machine, but if the user has been working remotely or on shared devices the refresh may not have happened.
How to check: open the Smartcard Manager (Care Identity Service / CIS) and look at the certificate status. If it shows expired, expiring within 30 days, or “renewal required”, that’s likely it.
How to fix: the user signs in to a machine that’s connected to the NHS network with the current middleware installed. The certificate refresh runs automatically. After a successful refresh, signing comes back without restarting anything.
3. Reader firmware out of date
Less common, but the smartcard reader itself has firmware — and on older Gemalto, HID Omnikey and Reiner devices, very old firmware can cause signing to fail intermittently while letting login succeed. Symptom looks identical to cause 1 but persists after a middleware update.
How to check: make a note of the reader model (printed on the underside) and check the vendor’s support page for the current firmware version. Compare to what’s on the device — typically shown in *Device Manager → Smart card readers → Properties*.
How to fix: vendor-specific. Each manufacturer ships a small firmware utility. The update is fast but you need an admin account, so practice managers usually need IT support to apply it.
In what order to try these
- Confirm the symptom — log in works, signing fails on the same card.
- Update the middleware to the current released version. If that fixes it, you’re done.
- If middleware update doesn’t fix it, check certificate status in CIS and let it refresh.
- If both above are clean, check reader firmware. This is the rare one.
If you’ve worked through all three and signing is still failing, the smartcard itself may need re-issue — but in practice that’s a much lower probability than the three above. Don’t reach for the re-issue until you’ve ruled out the easy fixes.
What to send to whoever’s helping
If you’re raising this with internal IT or an external IT provider, include:
- The user’s smartcard CN (the long number on the card)
- Which clinical application is involved (EMIS, SystmOne, Vision, etc.)
- The exact error message shown when signing fails
- The Windows build and reader model
- Whether the user has signed prescriptions successfully recently — if so, roughly when it last worked
This lets the support team skip 20 minutes of triage and get straight to the fix.
A quick note on whether to keep working
While signing is broken the user can still sign in and review records, but they shouldn’t manually work around it by asking a colleague to sign on their behalf — that’s a clinical governance issue regardless of how well-intentioned. The right move is to switch the user to read-only tasks until signing’s restored, which is usually under 30 minutes.
If those three didn’t fix it
If you’ve worked through the middleware update, the certificate refresh and the reader firmware and signing is still failing, the next step is usually a smartcard re-issue via your local Registration Authority. The order above clears it about 19 times out of 20 though, so don’t reach for the re-issue too early.
If you’re seeing a different signing error that doesn’t match the symptom above, drop a note via the contact page — your edge case might be worth adding to this guide for the next person searching for it.
Did one of the three steps above get you back to signing?
