How should organisations use smart cards for OpenPGP keys in a multi-device setup?

Security teams should treat smart cards as a way to keep private cryptographic keys off general-purpose devices while still using the same identity across endpoints. That reduces extraction risk if a laptop is lost or compromised. The main operational requirement is disciplined backup, recovery planning, and support for the workflows users actually need, such as email encryption and SSH authentication.

Why This Matters for Security Teams

Using smart cards for OpenPGP keys is less about “stronger passwords” and more about moving private keys into a tamper-resistant boundary that is harder to copy from a laptop, mailbox, or build agent. For teams managing the same identity across multiple devices, the real risk is not the card itself but the operational drift around issuance, PIN management, recovery, and revocation. That is why the problem belongs in identity governance, not just endpoint hardening. Current guidance suggests treating the card as a controlled key container, with the associated identity lifecycle handled as deliberately as any other privileged credential. The broader NHI risk picture reinforces that discipline: the Ultimate Guide to NHIs notes that 71% of NHIs are not rotated within recommended time frames, and 97% carry excessive privileges, which is a warning sign for any cryptographic workflow that becomes “set and forget.” Security leaders should align this practice with the NIST Cybersecurity Framework 2.0 by making key custody, recovery, and revocation part of a repeatable control model. In practice, many security teams encounter smart card failures only after a lost device, a broken token, or a stalled recovery request has already interrupted access.

How It Works in Practice

In a multi-device setup, the goal is to keep the OpenPGP private key on the smart card while allowing several endpoints to use the same public identity. That usually means the user carries one card or token, enrolls each device with the necessary client software, and ensures every workstation can talk to the card through the appropriate reader, middleware, and agent configuration. The private key never leaves the card; signing and decryption operations happen on-card, and the device only receives the result. This model improves extraction resistance, but it shifts the operational burden to recovery and portability.

Good implementations separate three things: the card-bound private key, the local device configuration, and the backup or escrow process for recovery. A practical setup should answer these questions up front:

• What happens if the card is lost, blocked by too many PIN attempts, or physically damaged?
• How is a replacement card provisioned without creating an unmanaged duplicate identity?
• Which devices are authorised to use the identity, and how is that list revoked?
• How are email, SSH, and signing workflows supported without encouraging users to export keys to disk?

For teams already formalising NHI governance, the same lifecycle thinking applies to cryptographic identities used by people and machines. The Ultimate Guide to NHIs is useful here because it frames lifecycle control, visibility, and offboarding as core disciplines rather than afterthoughts. For identity assurance and access governance, the NIST Cybersecurity Framework 2.0 is the better anchor for policy, ownership, and recovery planning. These controls tend to break down when users need frequent cross-device switching without a standard enrolment and revocation process, because the card becomes either a usability bottleneck or a shadow backup risk.

Common Variations and Edge Cases

Tighter smart card controls often increase support overhead, requiring organisations to balance stronger key custody against user mobility and help desk load. That tradeoff is most visible in mixed environments, where some users rely on macOS, others on Linux, and some on managed mobile devices that do not support the same OpenPGP stack. There is no universal standard for this yet, so best practice is evolving around consistency rather than one perfect client model.

Two edge cases matter most. First, teams sometimes issue a second smart card as a “backup” but never document whether it is a true recovery token, a spare for travel, or a duplicate identity. That ambiguity weakens revocation discipline. Second, organisations often assume card custody solves all key exposure problems, but local caches, agent forwarding, and exported subkeys can still create recovery or leakage paths if device policies are loose. Where SSH is involved, some teams use the card for authentication while keeping separate policies for encryption and signing, since the operational consequences of failure differ. Where email encryption is involved, users may need more careful migration planning because mailbox recovery and archived decryption often outlive device replacement cycles. The safest approach is to define card issuance, replacement, and retirement as one governed process, not a series of user workarounds.

Related resources from NHI Mgmt Group

• Why do smart cards still matter when organisations already use MFA?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?