CAC and PIV signing relies on the physical card and a reader to authenticate the user and access the signing certificate. Derived credentials move that trusted identity into an issued device such as a smartphone or tablet, reducing dependence on the card itself. The difference is mainly in how the credential is stored and used, not in the assurance goal.
Why the Credential Model Changes, Even When the Assurance Goal Does Not
CAC and PIV smart card signing are card-centered: the user proves possession of the physical card, typically with a reader, and the certificate and private-key use are tied to that card lifecycle. Derived credentials shift that same trusted identity to a managed mobile device, so the assurance target stays similar while the trust anchor, storage location, and operational dependency change.
The practical difference is not whether the signer is trusted, but where the trusted material lives and what must be present at signing time. That changes usability, offline access, device loss handling, renewal patterns, and how tightly the credential is bound to a specific form factor.
When organizations move from card signing to mobile derived credentials, they are usually trading a hardware-dependent workflow for a device-managed workflow. That makes the identity experience more portable, but it also changes which failure modes matter most: reader availability, card custody, mobile device protection, and lifecycle synchronization.
What CAC and PIV Smart Card Signing Depend On
With CAC and PIV signing, the card is the primary possession factor and the signing certificate is accessed through the card and reader combination. The operating assumption is that the private key remains protected by the card hardware, which limits where the credential can be copied or reused. For government identity programs, that model is tightly aligned with the broader workforce identity controls described in Public Sector Identity Security Guide and the physical-card authentication guidance in Workforce Identity Security Guide.
This model is strongest where a controlled reader, a managed endpoint, and a deliberate user action are all available. It is less flexible in mobile-first or field environments because the signing event is coupled to the card, the middleware, and the host system that can talk to the reader.
In practice, CAC and PIV signing works best when the organization wants a clear, hardware-backed boundary around credential use. The main operational constraint is that the trust model depends on the card being present and usable at the moment of signing.
What Derived Credentials on Mobile Devices Change
Derived credentials preserve the identity assurance objective but move the credential material into an issued smartphone or tablet, usually under stronger device management and policy enforcement. That means the user can sign from a mobile device without relying on a separate card reader, while the organization shifts trust to the device, its secure storage, and its lifecycle controls. The same general pattern appears in mobile credential and token handling guidance such as Token and Session Security Guide.
The key design difference is portability. Derived credentials can improve convenience, reduce friction, and support remote or mobile workflows, but they also make endpoint integrity more important because the device becomes part of the credential boundary. If the phone is compromised, mismanaged, or not properly wiped at offboarding, the assurance story weakens even if the original identity proofing was strong.
For practitioners, this means mobile derived credentials should be evaluated as a device trust problem as much as an identity problem. The question is not just whether the user was properly issued a credential, but whether the device carrying that credential is still within policy, still protected, and still uniquely tied to the intended user.
How to Choose Between Them in Practice
Use CAC or PIV smart card signing when the workflow benefits from a tangible hardware factor, strict physical custody, and a familiar government card ecosystem. Use derived credentials when mobility, remote signing, and lower user friction matter more, provided the device management stack is mature enough to absorb the added responsibility.
That trade-off is not cosmetic. A card model pushes assurance into the card reader and card custody process, while a derived credential model pushes assurance into the mobile device, its secure enclave or equivalent, and its enrollment, renewal, and revocation processes. The best choice depends on which dependency you can operate more reliably.
For organizations already handling certificates, rotation, and lifecycle risk, the same control logic that governs credential rotation and lifecycle discipline applies here: if you cannot reliably provision, bind, renew, and revoke the credential at scale, the portability benefits of derived credentials can create more operational risk than they remove.
Risk and Threat Considerations
The main risk is assuming the assurance model is identical because both options use trusted identity, when the actual attack surface shifts from a card-centric workflow to a device-centric one. In mobile deployments, compromise, loss, cloning, or poor device hygiene can turn a convenient credential into an easier persistence point or abuse path.
Failure mechanism: Card signing fails when physical custody, reader access, or card middleware breaks down; derived credential signing fails when the mobile device is compromised, unmanaged, or not properly revoked. In both cases, lifecycle gaps and weak revocation are the most common ways assurance erodes.
Impact: The likely consequence is unauthorized signing, reduced trust in the certificate event, and slower incident containment because teams must determine whether the problem is the user, the device, or the credential issuance process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers authenticator assurance and phishing-resistant identity used in CAC/PIV and derived credentials. |
| Recommendation — Align the credential model to the required assurance level and authenticator type. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Applies to lifecycle handling of signing credentials, including issuance, renewal, rotation and revocation. |
| IA-2 — Identification and Authentication (Organizational Users) | Relevant because CAC/PIV and derived credentials both authenticate workforce users before signing. | |
| IA-9 — Service Identification and Authentication | Applies when device-bound or managed credential flows authenticate non-human endpoints or services. | |
| Recommendation — Manage issuance, renewal and revocation for both card and mobile credentials. Require strong authentication before allowing certificate-backed signing. Bind machine or device authentication to the intended trust boundary. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | Supports access decisions and authentication governance for card and mobile credential workflows. |
| Recommendation — Apply consistent identity and access controls across card and mobile signing. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Covers lifecycle governance of identities and credentials that underpin CAC/PIV and derived credentials. |
| Recommendation — Maintain ownership and lifecycle control for all signing identities and credentials. | ||
Practitioner Guidance
What to verify: Confirm where the private key is stored, what hardware or secure storage protects it, and what must happen for revocation to take effect. A strong design should make it obvious which control fails first if the card or device is lost.
Decision rule: If the use case demands maximum physical assurance and controlled workstation access, favor card-based signing; if it demands mobility and field usability, use derived credentials only when mobile device management, attestation, and offboarding are consistently enforced.
Practitioner takeaway: Treat CAC/PIV signing and derived mobile credentials as two different trust envelopes for the same identity objective, and choose the one whose lifecycle and failure handling your environment can actually operate well.
Related resources from NHI Mgmt Group
- What is the difference between using a smart card for digital signing and using it for message decryption on iOS?
- What is the difference between derived PIV credentials and FIDO2 credentials in a government access stack?
- What is the difference between FIDO-based login and Smart Card/PIV authentication in enterprise access?
- What is the difference between shared mobile devices and 1-to-1 devices in clinical care?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
