SafeNet Authentication Client: Setup, PINs, and Fixing Token Errors

What is SafeNet Authentication Client, and why do you need it?

SafeNet Authentication Client is the software layer that lets Windows talk to a SafeNet USB token. The token holds your private key; SAC is what turns a plugged-in bit of plastic into something SignTool, jarsigner, or a browser can actually use. Without SAC installed, Windows lists the reader but not the certificate on it, and every signing command fails at the first step.

Physically the package includes four pieces: a Cryptographic Service Provider and a Key Storage Provider that plug into the Windows crypto API, a PKCS#11 library that Linux and Java signing tools call directly, a small monitor service that watches for tokens being inserted and removed, and the Client Tools application you open to change PINs and view certificate details. Most of the time you never look at any of them individually. When something goes wrong you almost always end up in Services.msc looking for one specific monitor, or in Client Tools counting failed PIN attempts.

The reason so many code signing setups now revolve around this one piece of middleware is a policy change. CA/Browser Forum ballot CSC-17 came into force on June 1, 2023, and requires the private key of every publicly trusted code signing certificate to be generated inside hardware meeting FIPS 140-2 Level 2 or Common Criteria EAL 4+, with the key marked non-exportable. The Baseline Requirements make no exception for OV certificates, which had previously been issued as soft PFX files. That delivered a lot of teams onto USB tokens for the first time, and SAC is the middleware nearly all of them ship with.

Cloud signing services do not use SAC at all: they replace the token with a network-attached HSM and swap SAC out for a different provider library. Everything below applies to teams still holding a physical token, whether from Certum, DigiCert, Sectigo, or another CA that ships on the SafeNet 5110 family.

Which SafeNet token model do you have?

Three models turn up in code signing shipments today, and they are worth telling apart before you plan an algorithm: the SafeNet 5110 CC (the (940) revision), the SafeNet 5110 FIPS, and the SafeNet 5110+ FIPS. The middleware is the same on all three. What differs is the hardware certification and the key algorithms each one will actually store.

The 5110 CC (940) is certified under Common Criteria EAL 5+, and it stores both RSA (up to 4096 bits) and ECC P-256 keys. CAs that ship EV code signing tokens across Europe, Certum among them, use this model by default, and it is the safest bet if you do not know what your CA will accept. The 5110 FIPS carries FIPS 140-2 Level 3 certification, and stores ECC P-256 keys only — no RSA, in either 2048 or 4096. The 5110+ FIPS extends the FIPS 140-2 Level 3 hardware with RSA support, which is useful when a policy specifically calls for FIPS certification and you cannot use ECC.

Two things follow from this. If you plan to issue an RSA 4096 certificate, do not order the 5110 FIPS; SAC will initialise the token cheerfully and only fail later when the CSR generation returns an unsupported algorithm error. And if your CA is silent about which model they ship, ask before you buy: a token you cannot use is not a token you can return, because the initialisation flow is a one-way trip.

How do you install SafeNet Authentication Client on Windows?

Download SAC from the CA that issued your certificate, or from Thales's DigiCert-hosted knowledge base if your CA points there. As of 2026 the current release is SAC 10.9 R1, and it lists Windows 10, Windows 11, and Windows Server 2019 and 2022 as supported. The installer is a normal MSI, so if you push software with a configuration management tool it deploys the same way as anything else.

Two setup choices matter more than any other. Choose Typical unless you specifically know you need PKCS#11 exposed — the Custom path adds the PKCS#11 library that Java and Linux signing tools want, and it is easy to forget to tick if you are not planning for jarsigner. And reboot after the install completes: SAC registers a CSP and a KSP, and Windows only picks up new providers when it starts fresh. Skipping the reboot is why a first-time install often looks broken to SignTool while working fine in the SAC Client Tools GUI.

One trap on Windows 11: a fresh install sometimes leaves the Smart Card credential provider active, and plugging a token into the sign-in screen throws up a PIN prompt that has nothing to do with signing. It is harmless — the token still works — but it is confusing, and Microsoft's own guidance is to disable the credential provider through Group Policy if nobody in your organisation logs on with a smart card. Look under Computer Configuration → Administrative Templates → System → Logon → Turn off picture password sign-in and its neighbours; the specific policy varies by build.

If a previous SafeNet Minidriver is already on the machine, uninstall it first. SAC and the Minidriver both try to expose the same token to Windows, and having both installed produces duplicate certificate objects that then compete for SignTool's attention. This is one of the most common causes of a signing command that works one day and fails the next after Windows Update quietly reinstalled the Minidriver.

How do you initialize the token and set the User PIN?

Initialisation happens once, from the CA's own certificate installer. Do not use SAC's built-in initialise option on a token that arrived with a certificate already on it: that option wipes the token, and on a code signing token the private key was generated during issuance and cannot be regenerated on your side. If in doubt, open SAC Client Tools and check under the token's slot for an existing certificate before you touch anything else.

The installer will ask for three inputs. The Initialization Code is a one-shot value the CA gave you in the setup email or portal; it is only used during the first setup, and it is not the same thing as either PIN. The Administrator PIN manages the token afterwards — resetting the User PIN, changing policy — and should be set to something long and unique. The User PIN is what you will type on every signature. Both PINs are set during initialisation, and both have retry counters.

What a fresh User PIN should look like has to satisfy the token's policy, which by default on the 5110 CC is at least eight characters, mixing letters and digits, and rejecting common patterns. Long User PINs are worth the effort here because losing a User PIN is annoying but recoverable, and short ones invite the sort of mistyping that eats the retry counter faster than you would expect. Once both PINs are set, store the Administrator PIN in a password manager the same day. Two people should know how to reach it, ideally in separate vaults, because a single person losing access is the same outcome as losing the PIN altogether.

Why is the SafeNet token not detected?

A token that used to work and now does not is almost always one of four things, and the order to check them in is the same whether you are on a laptop or a build agent. The first is whether Windows itself sees the reader, which happens at the driver layer and has nothing to do with SAC yet.

The middle checks — SAC Monitor running, and Client Tools showing the slot — are where a normal install goes wrong. SAC Monitor is a Windows service; if it stopped for any reason, no application will see the token even though the hardware is fine. Open services.msc, find SafeNet Authentication Service or SAC Monitor (the name varies slightly by version), and start it. Set the startup type to Automatic while you are there.

Duplicate installs are the other repeat offender. If you imported the token on this machine before, or if the SafeNet Minidriver ever shipped through Windows Update, you may have two SafeNet stacks on disk. Uninstall both, reboot, and reinstall only the current SAC. It is worth the ten minutes: mixed installs cause exactly the intermittent works, then does not work failures that are impossible to reproduce reliably.

One environment worth calling out on its own: Remote Desktop. A token plugged into your local machine is not automatically visible to a remote session, and SAC has to be running on the remote side to see it. Enable Smart Cards under the Local Resources tab of the RDP client before you connect. On a Terminal Server or shared build host, this is where signing on the developer's own machine works and the same command on the shared host silently fails.

When the same detection failure keeps coming back on a machine that has no person in front of it, the sensible response is to change the delivery model. Physical tokens are designed for a desk; they are not designed for a build agent that reboots itself on a nightly schedule. Our comparison of cloud code signing and USB tokens covers the trade-offs in more detail, but the short version is that a networked key you never lose the middleware for saves a great deal of pipeline maintenance.

How do you reset a lost SafeNet PIN?

A forgotten User PIN is a routine problem. Open SAC Client Tools, click the token, choose Change Password, and you will be offered a User PIN reset that asks for the Administrator PIN. The counter clears, the User PIN is set to whatever new value you type, and signing resumes as before. No CA involvement is needed, and the certificate on the token is unaffected.

A forgotten Administrator PIN is a very different situation, and there is no gentle way to write it: the token is finished. Nobody outside the person who set the Administrator PIN can recover it. Not the CA, not the reseller, not Thales. The counter on wrong Administrator PIN attempts is short, and once it is exhausted the token locks itself irreversibly. The private key inside is destroyed by design, because a key that could be reached without the Administrator PIN would not have passed the FIPS or Common Criteria certification the whole model rests on.

What happens next is the same as if the token had been lost physically. You order a new token and a re-issuance from the CA, repeat the organisation validation for EV, and pay for the certificate again — a re-issuance on a dead token is not free because the CA has to redo the paperwork. Timelines vary by CA, but plan for at least a week even in the smooth case. If your CA has an option to add token replacement insurance at purchase time, the calculation is simple: the insurance is cheaper than the certificate.

Everything about this argues for prevention rather than recovery. Write the Administrator PIN down before the first signing session, store it in the same password manager as your CA account credentials, and share the vault with at least one other person. It is worth doing on the day the token arrives, because the moment when it feels least urgent is exactly the moment when losing it is cheapest.

What are the common SafeNet errors and what causes each one?

Five error strings account for nearly every SafeNet incident in a code signing setup. Two of them come from SAC itself, two come from SignTool but trace back to SAC, and one is a Windows-level failure that pretends to be a token failure. Working out which family you are in is the whole diagnostic job; the fix follows from there.

The SignerSign() failure with 0x80090016 deserves a note, because it is where SafeNet and SignTool troubleshooting overlap. The hex code is a Windows Keyset does not exist value, and it fires when the certificate in the Personal store points at a provider — SAC — that is not currently answering. Restarting SAC Monitor usually clears it. If the problem persists after a restart, the certificate binding itself is stale, and re-registering the certificate through the CA's installer beats trying to fix the store by hand. Our guide to SignTool errors walks through the same failure from the command line side, including the other two HRESULTs that look similar and turn out to be different.

An error family the table does not cover is the timestamp path, because SAC has nothing to do with timestamping. If signtool sign wrote a signature and only the timestamp request failed, the file on disk is already signed and the token has already done its work; retry with signtool timestamp /tr <url> /td SHA256 app.exe and leave SAC out of the diagnosis.