Derived PIV Credentials Guide (NIST SP 800-157r1)

A PIV Card is a strong authenticator, but it cannot be inserted into most phones, tablets or thin laptops, so federal users fall back to weaker methods on exactly the devices they use most. Derived PIV credentials solve this by issuing a second, separate credential to a person who already holds a valid PIV Card, bound to the same PIV identity account. NIST SP 800-157 (final, December 2014) defined PKI-based derived credentials for mobile devices; its Revision 1, published as a final public draft on 14 November 2024, widens the scope to any device type and adds non-PKI authenticators such as WebAuthn. This guide is for federal identity, ICAM and endpoint teams, and for contractors who support them. It covers the two credential models, issuance, lifecycle and revocation, form factors, and how to run a programme. For the PIV Card itself, see the Smart Card and PIV/CAC Authentication Guide.

Key takeaways

Possession of a valid PIV Card is the root. A derived PIV credential is issued only to someone who proves control of their PIV Card (or meets the FIPS 201 Section 2.8 identity requirements in person), and it lives in the same PIV identity account.
Revision 1 adds non-PKI credentials. The SP 800-157r1 final public draft allows both PKI-based credentials (a derived PIV Authentication certificate) and non-PKI cryptographic authenticators, such as WebAuthn, that authenticate to the home agency and federate elsewhere under SP 800-217.
Every derived credential must be phishing-resistant. Both AAL2 and AAL3 derived credentials must meet the phishing resistance requirements of SP 800-63B, so one-time codes and push approvals do not qualify.
AAL3 means hardware and no key export. PKI-based AAL3 credentials need key generation on the device, FIPS 140 Level 2 or higher with Level 3 physical security, and no export. Syncable authenticators use exportable keys, which SP 800-63B-4 forbids at AAL3.
Lifecycle is tied to the account, not the card. Replacing or losing the PIV Card does not by itself kill derived credentials, but terminating the PIV identity account must invalidate all of them, and a lost card should trigger a review of recent bindings.

What a derived PIV credential is, and its status

SP 800-157r1 defines derived PIV credentials as credentials issued on the basis of possession and control of a PIV Card, recorded in the home agency's PIV identity account, and issued under that publication. They give PIV-grade authentication on endpoints where using the card is impractical. Identity assurance is inherited from the PIV identity account at IAL3, so no fresh identity proofing is needed when the cardholder already has a valid card.

The history explains the two-model structure. FIPS 201-2 introduced PKI-based derived credentials for mobile devices, and SP 800-157 (2014) specified them. FIPS 201-3 (January 2022) widened the concept to non-PKI credentials and other device types, and SP 800-157r1 follows that. The Revision 1 change log lists the main changes: derived credentials are no longer limited to mobile devices, non-PKI credentials may be bound at AAL2 and AAL3, assurance levels move from the old LOA terms to AALs, invalidation is no longer linked directly to the PIV Card, and a new appendix covers physical access.

Status as checked in November 2026: the NIST CSRC page shows SP 800-157 Rev. 1 as a final public draft dated 14 November 2024, with comments closed on 10 January 2025, and lists no final version. SP 800-157 (December 2014) remains the final publication on CSRC. SP 800-63B-4, which Revision 1 draws on for authenticator requirements, became final on 31 July 2025. Credentials issued under the 2014 PKI model remain valid under the draft. Treat details unique to the draft as likely but not settled, and check CSRC before you finalise policy. For the SP 800-63 side, see the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.

The two credential models compared

The single most important design decision is whether a derived credential is PKI-based or non-PKI-based. The table summarises the SP 800-157r1 final public draft.

Aspect	PKI-based derived credential	Non-PKI-based derived credential
What is issued	A derived PIV Authentication certificate and private key	A cryptographic authenticator registered to the PIV identity account, for example a WebAuthn credential or client-authenticated TLS key
Where it is verified	Anywhere that trusts the Federal PKI, the same way as the card's PIV Authentication certificate	At the home agency identity management system; other agencies rely on it through federation under SP 800-217
Authenticator type (SP 800-63B)	Multi-factor cryptographic authenticator (Section 3.1.7.1)	Multi-factor cryptographic (3.1.7.1), or single-factor cryptographic (3.1.6.1) plus a password meeting Section 3.1.1 (password not needed for physical access use)
AAL3 requirements	Key pair generated on the device; FIPS 140 Level 2 or higher with Level 3 physical security; no key export; certificate policy id-fpki-common-pivAuth-derived-hardware	SP 800-63B AAL3 requirements, including a non-exportable key and phishing resistance
AAL2 requirements	FIPS 140 Level 1 or higher; the CA may generate the key and send it over an authenticated protected channel, then promptly delete its copy; policy id-fpki-common-pivAuth-derived	SP 800-63B AAL2 cryptographic requirements
Maintenance	Rekey and certificate modification under the certificate policy, over a mutually authenticated session	No rekeying: invalidate the old authenticator and bind a new one
Termination	Certificate revocation; the draft says revocation SHALL occur unless the key is in non-exportable hardware that is collected and zeroised or destroyed (then SHOULD)	Remove the authenticator reference from the PIV identity account; collecting the device is optional

Choosing between them

Choose PKI-based when: relying systems already accept the PIV Authentication certificate (Windows smart card logon, mutual TLS, VPNs, signing and email encryption), or the credential must work across agencies without a federation relationship.
Choose non-PKI when: the main targets are web and SaaS applications behind the agency identity provider, where WebAuthn is native and certificate plumbing on phones is costly to run.
Many agencies run both: a PKI-based credential on managed laptops and a non-PKI credential on phones, both bound to one identity account so a single termination removes everything.

Form factors, and where synced passkeys fit

The draft is deliberately device neutral. It names embedded authenticators built into the endpoint and removable or wireless authenticators that connect over USB or a contactless interface.

Embedded hardware: keys held in the device's hardware-protected key store. For AAL3, SP 800-63B-4 requires a non-exportable key held in a hardware-isolated environment or separate processor, and the PKI AAL3 policy requires FIPS 140 Level 2 overall with Level 3 physical security. Check the actual validation certificate of the module, not the platform marketing name.
Removable and wireless tokens: normative Appendix B defines a derived PIV application with a data model, mandatory certificate objects and a command interface that mirrors the PIV Card's. Its activation secret is 6 to 8 bytes, alphanumeric, padded with 0xFF. Revision 1 also adds secure messaging and virtual contact interface capabilities for these tokens. See the Hardware Security Keys Guide.
Physical access: new Appendix D covers using derived credentials at PACS readers, with card authentication certificates under id-fpki-common-devices (FIPS 140 Level 1 or higher) or id-fpki-common-devicesHardware (Level 2 or higher), and secure messaging keys that must not be exportable.
Syncable authenticators: SP 800-63B-4 allows exportable keys at AAL1 and AAL2 and says they SHALL NOT be used at AAL3. The SP 800-157r1 draft text does not discuss syncable authenticators by name. Read together, a synced passkey can at most be considered as a non-PKI AAL2 derived credential, and only where agency policy accepts the sync fabric. For AAL3, use a device-bound key. See the FIDO Credential Exchange Passkey Portability Guide for how synced keys move between providers.

Issuance: what the draft requires

Issuance follows the post-enrolment binding model in SP 800-63B. The PIV Card is the proof that the applicant is an eligible cardholder.

Authenticate with the PIV Card: the applicant authenticates using the PIV Authentication key (PKI-AUTH, FIPS 201 Section 6.2.3.1), which also confirms the card is still valid and the person still eligible. Binding happens through a PIV-authenticated endpoint, a direct card connection, or the external authenticator binding procedure in SP 800-63B Section 4.1.2.2.
Check the device against policy: issuers must document device and credential trust policies. AAL3 credentials may be placed only on devices the home agency has determined were issued to the cardholder, which in practice means a managed device recorded in the asset inventory.
Generate or provision the key: for PKI AAL3, generate the key pair on the device, send a certificate signing request, and have the CA retain a copy of the certificate. For non-PKI, the applicant registers an approved authenticator and sets its activation factor.
Set activation: the private key must be usable only after the correct activation secret or a matching biometric. SP 800-63B-4 treats a biometric only as an activation factor, never as an authenticator on its own.
Notify the cardholder: issuers must promptly notify the cardholder at an address of record. This is the main control against an attacker who briefly gained use of a card and PIN.
Record and limit: record each derived credential against the PIV identity account. Issuers may cap the number of active credentials per person.

Issuance without a PIV Card is allowed in person or at a supervised remote station once FIPS 201 Section 2.8 requirements are met. Because later bindings need the card, the draft advises issuing all anticipated credentials at that session.

Lifecycle, invalidation and key recovery

Event	What the SP 800-157r1 draft says	Operational action
PIV identity account terminated	All derived credentials are invalidated; issuers must monitor account status continuously	Drive invalidation from the identity account record, not from a separate device list
Subscriber no longer eligible for a PIV Card	All derived credentials revoked or invalidated	Link HR separation and clearance changes to the identity account
PIV Card reissued or replaced	No effect on derived credentials	Do not mass-revoke; avoids locking users out of mobile email
PIV Card lost or compromised	Derived credentials generally stay, but the issuer SHOULD review derived credentials bound in roughly the previous seven days	Run a binding report for that window and contact the cardholder
Derived credential lost, stolen or damaged	Must be invalidated	Self-service report plus helpdesk path; revoke the certificate or remove the authenticator reference
Subscriber details on certificate change	PKI credential must be reissued	Name changes trigger a new certificate

Key management keys: Appendix A allows a copy of a key management (encryption) private key to be placed in a derived keystore so the user can still decrypt older email and files, provided the certificate policy permits the target module's FIPS 140 level. Key recovery mechanisms are encouraged. Digital signature keys are never copied; a new key pair and certificate are issued instead.

Implementation: a phased rollout

Decide the model and AAL per use case: list the relying systems (VPN, email, web SSO, Windows logon, PACS) and record whether each needs PKI or can accept WebAuthn, and whether it requires AAL3.
Confirm infrastructure: for PKI, check your shared service provider or agency CA supports the derived certificate policies and that relying parties chain correctly. For non-PKI, confirm the identity provider can bind authenticators to the PIV identity account and federate under SP 800-217. Confirm issuer authorisation under SP 800-79.
Prepare devices: enrol phones and laptops in mobile device management, apply SP 800-124r2 configuration, and record which device models have validated modules at the required FIPS 140 level. See the Mobile Device Management Security Guide.
Pilot with one group: issue to a small pilot ring (often ICAM staff and frequent travellers). Test issuance, activation, use at each relying party, cardholder notification and invalidation end to end.
Test termination first: before wide rollout, terminate a test identity account and prove that every derived credential stops working within your target time, including cached sessions.
Expand in rings: extend by organisation unit. Keep the PIV Card path working as the fallback so a broken derived credential never blocks work.
Rollback plan: if a device model or app fails, suspend new issuance for that model, invalidate the affected credentials, and fall back to the card with a reader or another approved phishing-resistant method.

Small and large organisations: a small agency usually consumes derived credentials from its shared service provider and spends its effort on device policy and termination. A large agency running its own issuance system also has to run issuer authorisation, certificate policy compliance and capacity planning for re-binding when devices are replaced.

Detection and measurement

Log each issuance, rebinding, rekey, activation lockout, invalidation and revocation with the PIV identity account identifier, device identifier and issuer operator. Alert on bindings from unusual locations, several bindings in a short period for one account, and bindings shortly before a card is reported lost.

Coverage: percentage of mobile and card-reader-less sign-ins made with a derived credential rather than a non-phishing-resistant method.
Termination latency: time from identity account termination to the last derived credential being unusable (target: same day or better).
Orphan rate: derived credentials bound to devices that are no longer in the asset inventory or MDM.
Credentials per person: distribution of active derived credentials per account, against your cap.
Lost card follow-up: percentage of lost or compromised card reports where the seven-day binding review was completed.

Framework mapping

Framework	Reference	How derived credentials apply
NIST SP 800-53 Rev. 5	IA-2(12) Acceptance of PIV Credentials	Relying systems accept PIV and derived PIV credentials
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management; IA-5(2) Public Key-based Authentication	Issuance, activation, rekey and revocation of derived authenticators
NIST SP 800-53 Rev. 5	IA-4 Identifier Management; IA-12 Identity Proofing	One PIV identity account; IAL3 inherited from the card's proofing
NIST SP 800-53 Rev. 5	AC-19 Access Control for Mobile Devices	Device trust policy and MDM for devices holding credentials
NIST CSF 2.0	PR.AA-01, PR.AA-02, PR.AA-03	Credentials managed, bound to proofed identities, used to authenticate
ISO/IEC 27001:2022 Annex A	5.17 Authentication information; 8.5 Secure authentication	Issuance and protection of authentication information; strong authentication on all devices
MITRE ATT&CK	T1111 Multi-Factor Authentication Interception; T1528 Steal Application Access Token	Phishing-resistant derived credentials remove the code interception path; tokens issued after sign-in still need protection

Common failure patterns

Treating derived credentials as a device problem: credentials tracked only in MDM survive the person's departure because nobody linked them to the PIV identity account.
Revoking on every card replacement: tying derived credentials to the card serial instead of the account causes mass lockouts each time cards are reissued, and pushes users to weaker fallbacks.
Calling a synced passkey AAL3: exportable keys are excluded from AAL3 by SP 800-63B-4; labelling them AAL3 in the identity provider overstates assurance to every relying party.
Skipping cardholder notification: without a notice to the address of record, a briefly stolen card and PIN can be turned into a long-lived phone credential that nobody notices.
Unvalidated key storage: placing AAL3 keys on a device whose module is not validated at the required FIPS 140 level, or allowing key export through backup.
Federation not set up for non-PKI: issuing WebAuthn derived credentials that work only at the home agency, then discovering partner agencies cannot accept them without an SP 800-217 federation arrangement.

Practitioner checklist

Record, per relying system, whether it needs a PKI-based or non-PKI derived credential and at which AAL.
Bind every derived credential to the PIV identity account and drive invalidation from account termination.
Require PIV-AUTH proof of possession of a valid card for each binding, through an approved binding path.
Restrict AAL3 issuance to agency-issued devices with key generation on a module validated at the required FIPS 140 level.
Do not label syncable authenticators as AAL3; decide in writing whether synced passkeys are accepted at AAL2.
Send a notification to the cardholder's address of record for every new binding.
Run a seven-day binding review whenever a PIV Card is reported lost or compromised.
Set and enforce a cap on active derived credentials per person.
Test end-to-end termination before each rollout ring, and keep the card path as a fallback.
Check the CSRC page for the final SP 800-157r1 and update policy when it is published.

Derived PIV Credentials: PIV-Grade Authentication on Phones and Laptops