Category: Identity & Access Management

Derived PIV Credential

Also known as: Derived Personal Identity Verification Credential, Derived Credential

Simply put

A Derived PIV Credential is a digital identity credential that is issued to a person based on their already-verified government PIV Card, so they can prove who they are on devices where inserting a physical smart card is impractical, such as a mobile phone. Rather than repeating the full identity-proofing process, it relies on the trust established when the original PIV Card was issued. It generally lets the holder authenticate securely in situations that do not easily accommodate a traditional PIV Card.

Formal definition

A Derived PIV Credential is an identity credential issued based on proof of possession of a valid Personal Identity Verification (PIV) Card, leveraging the identity proofing already performed for the parent credential rather than requiring a new proofing event. As addressed in NIST SP 800-157 (including the Revision 1 effort, which as of the applicable revision expands scope beyond mobile devices), these credentials may be either PKI-based, analogous to the PIV Card's certificate-based authentication, or non-PKI-based phishing-resistant multi-factor credentials. Derived PIV credentials are typically deployed in environments that do not readily accommodate a physical PIV Card, such as mobile devices. This entry does not cover specific issuance workflows, assurance levels, lifecycle management requirements, or agency-specific implementation and policy details, which practitioners should verify against the current authoritative text of the governing NIST publication and applicable federal ICAM policy.

Why it matters

Physical PIV Cards are the foundation of strong, phishing-resistant authentication across federal civilian and defense environments, but the smart card form factor does not fit every use case. Mobile devices, tablets, and other endpoints frequently lack integrated smart card readers, which historically left a gap between the assurance a PIV Card provides and the realities of a mobile workforce. Derived PIV credentials address this gap by extending the trust established during the original PIV issuance to devices where inserting a physical card is impractical, allowing organizations to maintain strong authentication without repeating full identity proofing for each new device or credential.

The compliance significance is that a Derived PIV Credential is not a separate, independently proofed identity; it inherits its trust from the parent PIV Card. This dependency matters for practitioners because the security posture of the derived credential is tied to the validity and lifecycle of the credential from which it was derived, and it must be governed accordingly. The NIST SP 800-157 Revision 1 effort reflects an evolving scope: as of the applicable revision, derived PIV credentials are addressed not only as PKI-based credentials analogous to the PIV Card's certificate-based authentication, but also as non-PKI-based phishing-resistant multi-factor credentials, reflecting broader use beyond mobile devices.

Practitioners should treat the specifics of assurance levels, issuance, and lifecycle management as governed by the current authoritative NIST text and applicable federal ICAM policy rather than by any single fixed interpretation. Because guidance in this area continues to evolve across revisions, and because agency-specific tailoring is common, organizations should confirm requirements against the current published guidance rather than relying on prior assumptions about scope.

Who it's relevant to

ICAM Program Managers and Identity Architects

Those responsible for identity, credential, and access management planning need to understand how derived PIV credentials extend PIV-based trust to mobile and other endpoints. They should track how the scope of derived credentials has expanded under the NIST SP 800-157 Revision 1 effort, including the recognition of non-PKI-based phishing-resistant multi-factor credentials, and align program design with the current authoritative guidance and applicable federal ICAM policy.

Information System Security Managers (ISSMs) and Security Officers

Security personnel must account for the fact that a derived credential inherits its trust from the parent PIV Card, meaning its assurance and lifecycle are tied to that relationship. They should verify how issuance, revocation, and lifecycle requirements are addressed in the governing NIST publication and agency policy rather than assuming a derived credential is an independent identity.

Mobile and Endpoint Engineering Teams

Teams deploying mobile devices and other endpoints that cannot accommodate a physical smart card are the primary implementers of derived PIV credentials. They should confirm implementation-specific details, including supported credential types (PKI-based versus non-PKI-based phishing-resistant multi-factor credentials), against current authoritative sources and vendor documentation rather than relying on generalized descriptions.

Compliance Officers and Auditors

Those assessing federal identity controls should understand that derived PIV credentials leverage prior identity proofing rather than repeating it, and that governing requirements continue to evolve across NIST revisions. Assessors should anchor findings to the current authoritative NIST SP 800-157 text and applicable federal ICAM policy, and confirm that assurance levels and lifecycle controls meet the specific requirements applicable to the system under review.

Inside Derived PIV Credential

Derived PIV Credential (DPC)

A credential issued to a subscriber who already holds a valid Personal Identity Verification (PIV) card, intended for use on devices such as mobile platforms where a traditional PIV smart card and reader are impractical. It derives its trust from the identity proofing already performed for the underlying PIV card. Practitioners should verify current issuance requirements against the applicable NIST guidance.

Underlying PIV Card Dependency

The derived credential's validity is tied to the status of the subscriber's existing PIV card. If the underlying PIV card is revoked or terminated, the derived credential is generally expected to be invalidated as well. Confirm the specific linkage requirements in the governing NIST publication and issuer policy.

Cryptographic Authentication Key

The DPC typically contains a private key and corresponding certificate used for authentication in place of the PIV Authentication certificate on the physical card. Implementation details, including whether additional keys such as digital signature or encryption keys are provisioned, vary by issuer and assurance level.

Assurance Level / Token Considerations

Derived PIV Credentials may be implemented across different assurance levels and token types, including hardware-backed and software-based tokens, depending on the risk tolerance and applicable federal guidance. The specific levels and permitted token types should be verified against the current NIST guidelines, as these have evolved across revisions.

Governing Framework

Derived PIV Credentials fall within the broader federal PIV framework established under HSPD-12 and implemented through FIPS 201 and associated NIST Special Publications. Federal Identity, Credential, and Access Management (ICAM) modernization is framed by OMB Memorandum M-19-17. Readers should confirm the current controlling revisions, as this guidance is periodically updated.

Common questions

Answers to the questions practitioners most commonly ask about Derived PIV Credential.

Is a Derived PIV Credential a separate identity that replaces my PIV card?

No. A Derived PIV Credential is not a new or separate identity, and it does not replace the PIV card. It is an additional credential derived from the identity proofing and vetting already established for an existing, valid PIV card. The underlying PIV card generally remains the authoritative credential, and the derived credential leverages that prior vetting rather than initiating a new enrollment. If the base PIV credential is revoked or the underlying identity is no longer valid, the derived credential's continued validity should be reassessed accordingly. Confirm the specific lifecycle linkage requirements against current NIST guidance and your agency's implementation.

Does issuing a Derived PIV Credential mean the device it lives on is compliant and secure?

No. Provisioning a Derived PIV Credential to a device addresses authentication of the user's identity; it does not by itself make the device or the overall system compliant or secure. Compliance and security depend on additional controls beyond the credential itself, such as device configuration, protection of the credential's private key, and the broader authorization posture of the system. Treating credential issuance as equivalent to compliance is a common error. The derived credential is one element within a larger identity, credential, and access management approach and must be evaluated alongside the other applicable controls.

On what types of devices can a Derived PIV Credential typically be provisioned?

Derived PIV Credentials are generally intended for use on devices where a traditional PIV card reader is impractical, most commonly mobile devices such as smartphones and tablets. The credential may be stored in different ways depending on the platform and the assurance requirements. The specific device types, storage mechanisms, and any assurance-level distinctions vary by implementation and by the applicable NIST guidance revision, so verify the currently supported configurations against the authoritative text and your agency's ICAM policy before deployment.

How is the private key for a Derived PIV Credential protected?

Protection of the derived credential's private key depends on the assurance level and the storage approach selected, which may range from software-based protection to hardware-backed storage. Higher-assurance implementations generally call for stronger key protection mechanisms. Because the acceptable protection methods and their mapping to assurance levels are defined in NIST guidance and can change across revisions, and because agencies may tailor these choices, confirm the required key protection approach against the current authoritative guidance and your organization's policy rather than assuming a single method applies.

What happens to a Derived PIV Credential when the underlying PIV card is revoked or expires?

Because a Derived PIV Credential is tied to the identity established for the base PIV card, the status of the base credential is relevant to the derived credential's validity. In most implementations, revocation or invalidation of the underlying identity is expected to trigger reassessment or revocation of the associated derived credential. The exact lifecycle rules, timing, and automation depend on your credential management system and applicable guidance. Verify the specific revocation and lifecycle linkage requirements in the current authoritative sources and your agency's procedures.

How does a Derived PIV Credential fit into an agency's broader ICAM program?

A Derived PIV Credential is one component of an agency's identity, credential, and access management (ICAM) capabilities, extending strong authentication to contexts where the physical PIV card is impractical. Federal ICAM modernization has been framed by OMB policy guidance, including OMB Memorandum M-19-17 (issued May 21, 2019), which addresses ICAM policy for federal agencies. Agencies should align derived credential use with their overall ICAM strategy, governance, and the applicable NIST technical guidance. Because policy and technical guidance evolve, confirm the current requirements and any agency-specific interpretations against the authoritative sources.

Common misconceptions

A Derived PIV Credential is a separate, independent identity that stands on its own.

A DPC derives its trust from an already-issued and valid PIV card. Its lifecycle is generally bound to that underlying credential, so revocation or termination of the PIV card is expected to affect the derived credential. It is not an independently proofed identity.

A Derived PIV Credential is a full digital replica of the physical PIV card containing all the same certificates and data objects.

A DPC typically provisions an authentication capability suited to devices like mobile platforms and does not necessarily replicate every certificate or data element on the physical card. The specific contents depend on issuer policy, token type, and the applicable NIST guidance.

Any single OMB memorandum comprehensively governs Derived PIV Credentials and can be treated as the sole authority.

The technical requirements for PIV and derived credentials originate primarily from HSPD-12, FIPS 201, and associated NIST Special Publications, while ICAM policy direction is framed by OMB M-19-17. No single memorandum should be cited as the complete authority; practitioners should consult the current controlling NIST and OMB documents directly.

Best practices

Verify the status of the underlying PIV card as part of the derived credential lifecycle, and ensure processes are in place to invalidate the DPC when the PIV card is revoked or terminated.

Confirm the applicable assurance level and permitted token types against the current NIST guidance rather than assuming a fixed configuration, since these requirements have changed across revisions.

Anchor policy and implementation decisions to the governing framework, HSPD-12, FIPS 201, associated NIST Special Publications, and OMB M-19-17 for ICAM direction, and confirm you are referencing the current controlling revisions.

Do not treat a Derived PIV Credential as a standalone identity; document and enforce its dependency on the subscriber's valid PIV card.

Coordinate DPC issuance with your organization's credential management and continuous monitoring processes so that credential status changes propagate promptly across relying systems.

Consult your issuer's official policy and current authoritative sources before finalizing implementation, contractual, or configuration decisions, as agency-specific interpretations may differ.