USB PKI Tokens and eTokens: PINs, DSC and Lifecycle

A USB PKI token keeps a private key inside tamper-resistant hardware so it can sign or authenticate without ever being copied, but that protection is undone by default PINs, shared tokens, tokens left plugged in and certificates nobody revokes when people leave. USB cryptographic tokens, often called eTokens after one widely used product line, carry digital signature certificates for filing documents and signing contracts, code signing certificates for software publishers, and authentication certificates for Windows logon, VPN and web portals. This guide explains how the token, its middleware and its certificates fit together, how regulated schemes such as India's Digital Signature Certificates and the CA/Browser Forum code signing rules require hardware keys, and how to set PIN policy, issue, use, renew and retire tokens safely. It is for IT, PKI and security teams who issue tokens, and for finance, legal and engineering teams who hold them. Card-based PIV and CAC programmes are covered in the Smart Card and PIV/CAC Authentication Guide; this page focuses on USB tokens and signing use.

Key takeaways

The key never leaves the token. The token generates the key pair and performs signing on-chip; the computer only sends data to be signed and receives the result, so stealing the laptop does not yield the key.
The PIN is the second factor and the weakest link. Change factory PINs at issue, keep the retry limit low (NIST SP 800-63B allows no more than 10 consecutive failures for activation secrets), and never write the PIN on the token.
Regulation often requires hardware. India's Controller of Certifying Authorities requires Class 2 and Class 3 signature keys to be held in FIPS 140-2 Level 2 validated hardware, and the CA/Browser Forum has required hardware key storage for code signing certificates since 1 June 2023.
A token is an identity, not a piece of kit. Assign each token to one named person or one documented service, record serial numbers, and revoke the certificate when the holder leaves or the token is lost.
Plan the FIPS 140-2 transition. NIST's CMVP moves FIPS 140-2 validated modules to the Historical list after 21 September 2026; check what your policies and regulators require before buying replacement tokens.

How a USB PKI token works

A USB PKI token is a smart card chip and reader combined in one USB device. It stores one or more private keys and their X.509 certificates, and it performs cryptographic operations internally once the holder enters a PIN. Applications reach it through layers of middleware.

Layer	What it does	Examples
Token hardware	Generates and stores keys, enforces PIN and retry counters, signs and decrypts on-chip	USB cryptographic tokens; FIDO2 and PIV-capable security keys
Token middleware or driver	Exposes the token's keys to the operating system and applications, provides PIN change and unblock tools	Vendor authentication clients; Windows smart card minidrivers; macOS CryptoTokenKit
Standard interface	Lets any compliant application use any compliant token	OASIS PKCS #11 (current version 3.1, OASIS Standard of 23 July 2023); Windows CNG and CryptoAPI providers
Applications	Request a signature or authentication	PDF and document signing tools, government e-filing portals, code signing tools, VPN clients, Windows logon
Certificate authority	Issues and revokes the certificate bound to the token's key	Licensed or public CAs; enterprise CAs such as AD CS

PKCS #11 models a token as having a Security Officer (CKU_SO) and a normal user (CKU_USER), each with their own PIN. The standard defines token flags for a user PIN that must be changed at first use (CKF_USER_PIN_TO_BE_CHANGED), during which only the PIN change function works, and for locked user and Security Officer PINs (CKF_USER_PIN_LOCKED, CKF_SO_PIN_LOCKED). In practice: the Security Officer or administrator PIN initialises the token and unblocks the user PIN; the user PIN authorises signing. On PIV-based tokens the equivalent pair is the PIN and the PUK, plus a management key that controls key generation and certificate loading.

USB token compared with the alternatives

Option	Key exportable?	Strengths	Weaknesses	Typical use
Software certificate file (PFX or PKCS #12)	Yes, copy the file	Cheap, no hardware	Any breach that reaches the file and its password gets the key	Low-assurance signing; not allowed for India Class 2/3 or public code signing
USB PKI token	No, generated on-chip	Portable, person-bound, meets hardware requirements	Can be lost, shared or left inserted; one person per token	Individual digital signatures, code signing by small publishers, logon
Smart card with reader	No	Can double as a photo badge	Needs readers on every device	Government and large enterprise logon
HSM or cloud signing service	No	Shared, audited, scriptable, highly available	Cost, operational complexity; India's CCA states HSMs do not meet its Class 2 and Class 3 subscriber requirement	CI/CD code signing, organisational document signing at volume
FIDO2 security key or passkey	No	Phishing-resistant login with no certificates to manage	Authentication only, does not produce legally recognised document signatures	Web and workforce sign-in

Where USB tokens are required

India: Digital Signature Certificates (DSC)

Under India's Information Technology Act, 2000, the Controller of Certifying Authorities (CCA) licenses Certifying Authorities, and those CAs issue DSCs to individuals and organisations. The CCA's guidance states that digital signatures are on a par with handwritten signatures under the Act. Points practitioners need:

Key storage by class: the CCA states Class 1 keys may be stored in software, but Class 2 and Class 3 keys must be kept in a hardware cryptographic device validated to FIPS 140-2 Level 2 and in the subscriber's custody, which is why DSCs are delivered on USB tokens. The CCA publishes "Security Requirements for Crypto Devices" (CCA-CRYPTO, version 2.1 of 23 February 2024) for these devices.
Assurance of identity: Class 3 is the higher-assurance class; the CCA describes physical appearance before the CA or video verification for the paper-based route, and Aadhaar eKYC (OTP or biometric) based issuance types.
Document Signer certificates: intended for an organisation's software to sign automated responses; the CCA states they do not replace the signature of an authorised signatory.
Leavers: the CCA advises that certificates should be revoked when a subscriber leaves an organisation. A director's or authorised signatory's token held by a company secretary or accountant is a common gap.
Validity of past signatures: the CCA states a signature is verified against the time it was affixed, so revoking a leaver's certificate does not invalidate documents properly signed earlier.
Interoperability: the CCA has issued an advisory to application owners on mandatory acceptance of valid DSCs issued by any licensed CA, and publishes Interoperability Guidelines for DSC (CCA-IOG).

For broader Indian regulatory context see the India DPDP Act Guide.

Public code signing certificates

The CA/Browser Forum Baseline Requirements for Code Signing Certificates (version 3.11.0 at the time of checking) state in section 6.2.7.4.2 that, from 1 June 2023, CAs shall ensure the subscriber's private key is generated, stored and used in a suitable hardware crypto module, verified by one of the methods the Forum approves. For a small publisher this usually means a USB token shipped by the CA; for a build pipeline it means an HSM or cloud signing service, because a token on one engineer's desk does not scale and invites sharing. See the Code Signing Security Guide.

Workforce logon and VPN

Certificate-based logon to Windows and Active Directory uses the same token and middleware. Kerberos PKINIT and certificate mapping are covered in the Kerberos PKINIT and Certificate Mapping Guide.

PIN policy

Setting	Recommended baseline	Source or reason
Factory PINs and keys	Change at issue, before loading certificates	Defaults are public: Yubico documents the PIV defaults as PIN 123456, PUK 12345678 and a published default management key
Force change at first use	On	PKCS #11 CKF_USER_PIN_TO_BE_CHANGED restricts the token to PIN change until done
User PIN length	At least 6 characters; 8 or more for signing tokens	NIST SP 800-63B Rev. 4: activation secrets SHALL be at least 4 and SHOULD be at least 6 characters
Retry limit	3 to 10 consecutive failures, then lock	SP 800-63B: no more than 10 consecutive failed attempts; Yubico PIV blocks after 3 by default
Common PINs	Block 123456, 000000, dates of birth	SP 800-63B recommends a blocklist of common activation secrets
Administrator PIN or PUK	Unique per token, held by the issuing team in a vault, never given to the holder of a signing token	Whoever holds the admin PIN can reset the user PIN
Both PINs blocked	Treat as a re-issue	On Yubico PIV a full reset deletes all keys and certificates
Windows removal behaviour	"Interactive logon: Smart card removal behavior" set to Lock Workstation (or Force Logoff on shared kiosks)	Microsoft Group Policy setting scremoveoption
Cached PINs	Enable "Prevent plaintext PINs from being returned by Credential Manager"	Microsoft policy DisallowPlaintextPin; test first, as Microsoft notes some cards may stop working

Signing tokens deserve a stricter rule than logon tokens: for document and code signing, configure the middleware or application so the PIN is required for every signature rather than cached for the session, where your token and software support it. A cached PIN on an unlocked laptop turns the token into a signing oracle for any malware running as the user.

Token lifecycle

Procure: choose tokens validated to the FIPS 140 level your scheme requires. NIST's CMVP states that FIPS 140-2 validated modules can be accepted by US federal agencies through 21 September 2026 and then move to the Historical list, usable only in existing systems; FIPS 140-3 validations have been accepted since 22 September 2020. India's CCA requirement still names FIPS 140-2 Level 2, so check the CA's current device list.
Register: record the serial number, holder, purpose, certificate serial and expiry in an asset register.
Initialise: set unique administrator PIN, force user PIN change, generate the key on the token. Never import a key generated elsewhere for a signing certificate; for public code signing the CA must verify on-token generation.
Issue in person or with verified identity: hand the token to the named holder; for DSCs the CA's verification process applies.
Use: plug in only when signing; remove afterwards. Never share a token between colleagues, even within a team.
Renew: track expiry centrally and renew 30 to 60 days ahead; a lapsed code signing or DSC certificate stops filings and releases.
Revoke and retire: on leaver, role change, loss or suspected misuse, revoke the certificate at the CA first, then reset or destroy the token and update the register.

Decision guidance

Small company with one or two signatories: personal USB tokens, held by the signatory, with a register and leaver checklist.
Finance or company secretarial team signing for directors: do not hold directors' tokens and PINs centrally; if signing is delegated, the delegate should hold their own certificate in their own name where the scheme allows.
Software publisher shipping daily: move signing to an HSM or cloud signing service behind the build pipeline, with approvals; keep tokens only for emergency or legacy releases.
Large enterprise logon: use a card management system to issue and track tokens, and consider FIDO2 for web sign-in where certificates are not required.

Where identity fits

Tokens are often bound to people but used by machines: a token left permanently in a build server so an unattended job can sign, or an organisational Document Signer certificate used by an application. These are non-human identities with a person's name on them. Give automated signing its own certificate held in an HSM or signing service, owned by a named team, with logging and approval, rather than a person's token with the PIN in a script. See the Machine Identity, PKI and Certificate Lifecycle Guide and the HSM Deployment and Operations Guide.

Detection and measurement

Signing logs: for code signing, log every signature with the file hash, signer certificate and requesting host; alert on signing outside release windows.
Certificate inventory: watch for certificates issued to your organisation's name that are not in the register, using CA portals and, for TLS, certificate transparency.
Windows logon: track smart card logon events and failed PIN events from the domain controllers and endpoints to spot shared or brute-forced tokens.
Leaver feed: reconcile the token register against HR leavers every month.

Metric	Target
Tokens with a named holder and current register entry	100%
Tokens still on factory PINs (sample audit)	0
Certificates of leavers revoked within 1 working day	100%
Certificates expiring within 30 days without a renewal ticket	0
Code signing operations performed from tokens rather than the managed signing service	Down, towards 0 for routine releases

Lessons from incidents

When Lapsus$ leaked NVIDIA code signing certificates in 2022, the leak included the private keys, which were then used to sign malware: keys that exist as copyable files can be taken in any breach that reaches the right share. Hardware-bound keys remove that class of theft, though not misuse through a compromised signing host. See the NVIDIA code signing certificate theft 2022 and the Compromised Code Signing Certificate Playbook.

Common failure patterns

Factory or shared PINs: tokens issued with the vendor default PIN, or one PIN used across the whole team.
Tokens left inserted: a signing token permanently in a laptop with the PIN cached is no better than a software key against malware.
Central custody of personal tokens: an office holding directors' DSC tokens and PINs in a drawer breaks the "subscriber's custody" requirement and the non-repudiation the signature relies on.
No revocation on leaving: certificates remain valid for months or years after the holder leaves.
Token on a build server: a person's code signing token used by an unattended pipeline, with the PIN in a script.
Expiry surprises: nobody tracks certificate expiry until a filing or release fails.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	IA-2 Identification and Authentication; IA-5 Authenticator Management; IA-5(2) Public Key-based Authentication; SC-12 Cryptographic Key Establishment and Management	PIN policy, certificate lifecycle, key protection
NIST CSF 2.0	PR.AA-03 users, services and hardware are authenticated	Token-based authentication
NIST SP 800-63B Rev. 4	Multi-factor cryptographic authenticators; activation secrets	PIN length and retry limits
MITRE ATT&CK	T1552.004 Private Keys; T1649 Steal or Forge Authentication Certificates; T1588.003 Code Signing Certificates; T1553.002 Code Signing	The theft and misuse that hardware keys prevent or limit

Practitioner checklist

Keep a register of every token: serial, holder, purpose, certificate serial and expiry.
Change all factory PINs, PUKs and management keys before issue.
Force user PIN change at first use and set a retry limit of 10 or fewer.
Generate keys on the token; never import signing keys from files.
Set smart card removal behaviour to lock the workstation.
Require the PIN per signature for signing tokens where supported.
Revoke certificates on leaving, loss or role change within one working day.
Move routine code signing to an HSM or signing service with approvals and logs.
Track certificate expiry centrally with 30 to 60 days' notice.
Check FIPS 140 validation status of current and replacement tokens against your scheme's rules.

USB PKI tokens and eTokens guide: PINs, signing certificates and token lifecycle explained