Skip to main content
This is not an official U.S. federal government website. The Federal Modernization Workbook is independent technical analysis. It does not represent the position of, and has not been reviewed or endorsed by, any federal agency.

Federal Modernization Workbook · Book 07 · What

Chapter 09 — Federal Workforce Credentials: PIV, Derived PIV and Cloud Authentication

The PIV credential as the federal workforce credential that cloud authentication sits under: HSPD-12 and FIPS 201-3, the PIV authentication certificate and the card’s lifecycle, derived PIV credentials for mobile devices, how Entra certificate-based authentication accepts the credential, Federal PKI trust and PIV interoperability, federation with other agencies and partners, NIST SP 800-63-4 assurance levels, and the evidence the ISSO keeps.

The cloud doesn’t replace the federal workforce credential; it’s one more place the agency accepts it, and every acceptance has to end the day the card does.

NoteIn this chapter

What the PIV credential is under HSPD-12 and FIPS 201-3: the PIV authentication certificate, the link to the background investigation, and the card’s issuance, reissuance and termination, tied to the HR leaver gate. Derived PIV credentials under NIST SP 800-157 and its unfinished revision, and how Intune and Entra ID use them. How Entra certificate-based authentication accepts the PIV authentication certificate, and why that’s acceptance, not replacement. Federal PKI trust, accepting another agency’s PIV and PIV-I, and federation with other agencies and partners through Entra B2B or SAML. The NIST SP 800-63-4 assurance levels as they apply, and the records the ISSO keeps, mapped to SP 800-53 Moderate controls.

The rest of this book is about the certificates the agency issues and renews itself. This chapter is about the one it mostly doesn’t: the certificate on the PIV card. Chapter 04 placed the Federal PKI in the target as an issuer the program trusts but doesn’t run, and Chapter 06 configured Entra certificate-based authentication (CBA) to validate it. Neither says what the credential is, who stands behind it, or how it works when the person signing in belongs to another agency.

That matters because a migration can quietly change the answer to “how does this person sign in?” A program moving from AD FS to Entra ID, or from smart card logon to the domain to cloud sign-in, can come to think of CBA as the credential. It isn’t. HSPD-12 and FIPS 201-3 define the credential; the Federal PKI issues its certificates; the agency’s credentialing office proofs, issues and terminates it. Entra ID is a relying party that checks it, as the domain controllers were. The program’s job is to make that check faithful to the credential: trust the right CAs, notice revocation, map the certificate to one person, and refuse sign-ins that don’t meet the phishing-resistant bar.

A top-to-bottom flow. A violet card, HSPD-12 and FIPS 201-3, one credential for employees and contractors that M-19-17 makes primary, points down to a blue card, PIV card, holding the PIV authentication certificate from a Federal PKI issuing CA under the Common Policy root. The PIV card points right to a blue card, derived PIV credential, bound by proving possession of the card and delivered to a phone through Intune. Both credentials point down to a blue card, Entra certificate-based authentication, with a trust store and a CRL per CA, username binding and authentication binding; the edges are labeled PIV auth certificate and own policy OID. To its left a red card, HR leaver gate, separation: disable and revoke sessions now, and revoke the card and every derived credential. Dashed red arrows run from it to the PIV card, labeled revoke then CRL, and to Entra CBA. Entra CBA points down to a green card, Conditional Access, requiring the phishing-resistant MFA authentication strength. Two slate cards feed Conditional Access with dashed arrows: on the left, another agency's Entra tenant, B2B collaboration with inbound trust of its MFA claim; on the right, a partner SAML or WS-Fed provider, guest federation with the MFA grant control rather than a strength. Conditional Access points down to a green card, agency applications, using SAML or OIDC with Entra as the agency's identity provider.
Figure 1: The PIV credential sits under cloud authentication: policy defines it, the Federal PKI issues it, Entra CBA accepts it, and Conditional Access enforces the strength, for the agency’s own users and for users arriving from other agencies and partners. The HR leaver gate blocks sign-in at once and revokes the card.

HSPD-12 and FIPS 201-3: what the PIV credential is

The policy

Homeland Security Presidential Directive 12, signed August 27, 2004, set a government-wide standard for secure and reliable identification issued to federal employees and contractors. The identification must be issued on sound criteria for verifying identity, resist fraud, tampering and counterfeiting, be rapidly authenticated electronically, and come only from providers whose reliability has been established by an official accreditation process. Agencies must require it, to the maximum extent practicable, for access to federally controlled facilities and federal information systems.1

FIPS 201-3 (January 2022) is that standard. It establishes the Personal Identity Verification (PIV) system that meets HSPD-12’s control and security objectives, covering identity proofing, credential interoperability and the accreditation of issuers.2 OMB M-19-17 keeps both in force: HSPD-12 “remains the Government-wide policy,” FIPS 201 (or its successor) remains the standard, and agencies “shall require PIV credentials … as the primary means of identification and authentication” to federal information systems and facilities for employees and contractors.3 The memo also describes a PIV credential as the aggregate output of proofing, vetting and binding a person to an authenticator, and asks agencies to manage the lifecycle of identities rather than of credentials.4 That’s the reason this workbook ties the credential to the HR record (Book 03, Chapter 09).

The PIV authentication certificate

A PIV card holds several keys. At a minimum it stores the PIV authentication key and the asymmetric card authentication key with their certificates; it also stores a digital signature key and a key management key unless the cardholder has no government email account at issuance.5 For logical access the one that matters is the PIV authentication key:6

  • It’s generated on the card and can’t be exported. Its operations work over the contact interface (or the virtual contact interface), never the contactless one.
  • Its X.509 certificate carries the card’s FASC-N and card UUID in the Subject Alternative Name, expires no later than the card, and may carry the background investigation indicator, which records the investigation’s status at issuance.
  • The certificate must assert the id-fpki-common-authentication policy of the Federal Common Policy, and the CA that issues it must participate in the Common Policy hierarchy run by the Federal PKI Management Authority. CAs can be agency-run or outsourced to approved PKI shared service providers.

Two consequences follow for the cloud. The policy OID is what Entra’s authentication binding keys on to treat the certificate as multifactor (Chapter 06). And the card authentication certificate, which works contactless and without a PIN, is a physical-access credential: Microsoft says a certificate should count as multifactor only if a PIN or biometric protects it,7 so the authentication binding should give multifactor to the PIV authentication policy only (design guidance).

The card’s lifecycle

The PIV card’s lifecycle under FIPS 201-3
Stage What FIPS 201-3 requires Where this workbook runs it
Sponsorship and proofing A credential is issued only after a proper authority authorizes it, the person’s identity is verified, and two identity source documents are presented, one a federal or state government picture ID (§2.1) The HR joiner or contractor sponsorship event starts the request (Book 03, Chapter 09)
Background investigation Eligibility rests on a favorably adjudicated investigation, at minimum Tier 1. With no prior investigation, the investigation must be initiated and its FBI National Criminal History Check portion completed and favorably adjudicated before the card is issued; the final determination is reported to the Central Verification System (§2.2) The personnel security office, outside the tenant; the program records the proofing outcome as data (Book 03, Chapter 09)
Issuance Only through accredited issuers; the card is valid for no more than six years (§2.8) The card management system, which also writes the Entra binding (Chapter 06)
Renewal and reissuance Reissuance replaces a card nearing expiry, after a status or attribute change, or when compromised, lost, stolen or damaged, without repeating full proofing if the enrollment record holds biometrics; a later expiry date or changed data needs an adjudicative entity’s authorization (§2.9.1) A reissue changes the certificate, so the binding is rewritten and the old value removed (Book 03, Chapter 09)
Termination The card is terminated when the employee separates, a contractor no longer needs access, the cardholder dies, eligibility is denied, or the identity is fraudulent. Collect and destroy it if possible; otherwise revoke the PIV authentication and card authentication certificates, and the signature and key management certificates if present; update the Central Verification System and the card management system; invalidate every derived credential. If the card can’t be collected, finish within 18 hours of notification (§2.9.4) The HR leaver gate, below

Revocation at separation is the HR leaver gate’s job

FIPS 201-3 counts separation from federal service as a termination event and sets the 18-hour clock for a card that can’t be collected.8 M-19-17 adds that agencies must be able to revoke access privileges and revoke or destroy credentials in a timely manner when an employee or contractor separates.9 In this workbook both run from one trigger: the HR leaver gate in the HR-Driven Identity guide, Step 6, which follows the canonical leaver sequence.

The order matters because of how the cloud learns about a revocation. Entra caches each CA’s CRL and doesn’t see a newly revoked certificate until a newer base or delta CRL loads; it doesn’t use OCSP, and Microsoft recommends revoking the user’s sessions as well whenever a certificate is revoked.10 So the leaver gate disables the account and revokes sessions first, which ends cloud sign-in at once, and revokes the card and its derived credentials in parallel, which ends it everywhere else when the issuing CA next publishes. The evidence records both times: separation to block, and separation to the CRL that carried the revocation (Book 03, Chapter 09). A contractor’s card follows the same path from the contractor source’s end date (Chapter 04).

Derived PIV credentials

What they are, and which document governs them

A derived PIV credential is an additional PIV credential issued on proof of possession and control of a valid PIV card. It isn’t on the card; it’s stand-alone or built into a device, for places where the card is hard to use.11 FIPS 201-3 sets the rules that matter to a migration:12

  • Issuance is a post-enrollment binding of an authenticator under SP 800-63B, using a valid PIV card to establish the cardholder’s identity in line with SP 800-157. The cardholder is notified of the binding through an independent channel.
  • The credential must meet AAL2 or AAL3. One that meets only AAL2 may be used only at AAL2.
  • Only the agency that manages the cardholder’s PIV identity account may bind a derived credential to it.
  • Derived credentials are invalidated on the cardholder’s request, on loss, suspected compromise or fraud, and whenever the PIV card is terminated, in which case every derived credential on the account goes. If the private key of a derived PIV authentication certificate can’t be zeroized, the certificate is revoked.

The governing guideline is still NIST SP 800-157 (December 2014), which covers PKI-based derived credentials issued to people who hold a valid PIV card; its CSRC page lists it as final with no successor.13 SP 800-157 Revision 1 is a final public draft dated November 14, 2024, whose comment period closed January 10, 2025; as of November 2, 2026, CSRC lists no final version.14 The draft widens derived credentials to non-PKI, phishing-resistant authenticators whose attributes come from the home agency’s PIV identity account, issued at AAL2 or AAL3 and IAL3 without repeating proofing.15 Plan for both forms, but configure to the 2014 final until the revision is published (design guidance).

When they’re used

OMB M-19-17 requires agencies to use derived PIV credentials where applicable and to make applications and devices accept them.16 The common case is mobile. GSA’s Phishing-Resistant Authenticator Playbook notes that card readers are optimized for desktops and laptops, that derived PIV is typically used where the card is hard to accommodate, such as on mobile devices, and that it depends on the user already holding a PIV card.17 M-22-09 names PIV “including Derived PIV” as, for many systems, the simplest way to meet its phishing-resistant requirement.18

How Intune and Entra ID relate to them

Intune and Entra ID play different parts, and neither is the issuer:

  • Intune delivers the credential. Microsoft describes Intune derived credentials as an implementation of SP 800-157: a certificate derived from the user’s smart card is provisioned to the mobile device by a supported derived credential issuer, after the user authenticates to that issuer with the card on a computer. Intune supports a short list of issuers and only one per tenant, and deleting the issuer stops every derived credential set up through it. Supported platforms are Android Enterprise fully managed and corporate-owned work profile, iOS/iPadOS and Windows; profiles such as Wi-Fi, VPN, email, app authentication and S/MIME can name the derived credential as their authentication method.19 The issuer is an agency procurement decision; this book doesn’t recommend one.
  • Entra ID accepts it. Entra CBA on iOS supports on-device and derived PIV certificates in Safari and in Microsoft apps that use the latest MSAL or Microsoft Authenticator. Microsoft also notes that iOS doesn’t support hardware-protected keys out of the box, so customers can keep certificates on external devices instead.20 On Android, Entra CBA likewise supports on-device and derived PIV certificates in Microsoft apps and third-party apps that use the latest MSAL or Microsoft Authenticator, and smart cards or security keys only from supported vendors.21
  • The authentication binding has to know about it. A derived credential whose policy OID differs from the card’s doesn’t inherit the card’s multifactor rule; Microsoft’s own example shows the derived credential falling to single-factor and the user being asked for a second factor.22 Give the derived credential its own rule, multifactor only if its key protection and activation meet AAL3, and use CA scoping where a separate CA issues it (Chapter 06) (design guidance).

How Entra CBA uses the PIV authentication certificate

Acceptance, not replacement

Entra CBA is how the agency’s cloud tenant accepts the PIV credential. It doesn’t issue the credential, proof the person or decide eligibility; the card management system and the credentialing office still do all three, and Microsoft describes moving from AD FS certificate authentication to CBA as changing where revocation and authentication are checked, not the credential or the PKI (Chapter 06). SP 800-53 has a control for exactly this: IA-2(12), “Accept and electronically verify Personal Identity Verification-compliant credentials.”23 CBA is the tenant’s implementation of it. A cloud authenticator that isn’t bound to the PIV identity account, such as a passkey registered on the user’s own word, isn’t PIV acceptance, however strong it is; under M-22-09 it’s a permitted phishing-resistant alternative where PIV isn’t practical, and should be centrally managed and tied to the enterprise identity.24

The four settings that make acceptance faithful

Chapter 06 has the full configuration; for the PIV certificate it comes down to four settings, each checked by the HR guide’s Gate 5 and its workbook chapter on CBA checks:

  1. Trust the issuing CAs, each with its CRL. Upload every root and intermediate in the Federal PKI path that issues the agency’s PIV certificates. Entra supports one HTTP or HTTPS CRL endpoint per CA, recommends HTTP, checks CRLs for up to 10 CAs from the leaf, and fails CBA for a CA whose configured CRL it can’t download within 10 seconds or within 20 MB (commercial, including GCC) or 45 MB (Azure Government) at interactive sign-in. Require CRL validation so a CA without a CRL fails closed.25 IDManagement.gov’s CBA guide points to the Federal PKI’s list of PIV issuing CAs for which ones to upload.26
  2. Bind the certificate to one person. Username bindings map a certificate field to a user attribute. PrincipalName, RFC822Name, Subject and IssuerAndSubject are low affinity; SKI, SHA1PublicKey and IssuerAndSerialNumber are high affinity.27 The program requires high affinity in certificateUserIds, written by the card management system on every issuance and reissue, and departs on Microsoft’s advice from IDManagement.gov’s low-affinity PrincipalName recommendation (Chapter 06).
  3. Make the PIV authentication certificate multifactor. The tenant default is single-factor; an authentication binding rule by issuer and policy OID raises the PIV authentication certificate to multifactor, which Microsoft says is appropriate only for certificates protected by a PIN or biometric.28 IDManagement.gov’s guide recommends keeping the default single-factor rather than switching the whole tenant to multifactor,29 which a targeted rule respects.
  4. Require the phishing-resistant strength. The built-in Phishing-resistant MFA authentication strength accepts Windows Hello for Business or a platform credential, FIDO2 security keys, and multifactor CBA; single-factor CBA satisfies none of the built-in strengths.30 FIDO2 security keys are device-bound passkeys whose private key never leaves the key.31 A custom strength’s advanced options can require a certificate from particular issuers or with particular policy OIDs, for example only the PIV authentication policy for the most sensitive applications.32

Phishing-resistant MFA under M-22-09

M-22-09’s identity actions require phishing-resistant MFA for agency staff, contractors and partners, enforced at the application layer; agencies must stop supporting, for routine self-service access, methods that register phone numbers for SMS or voice, supply one-time codes or use push notifications.33 Microsoft’s own M-22-09 guidance lists Entra CBA, including PIV, CAC and derived PIV for mobile devices, among the phishing-resistant options.34 So the requirement and the configuration come together in one place: a Conditional Access policy requiring the phishing-resistant strength, satisfied by the PIV card through CBA. The policy library that holds it is Book 04, Chapter 07.

Administrators: the PIV certificate in the privileged strength

The Zero Trust Assessment’s privileged-authentication checks ask whether privileged accounts have phishing-resistant methods registered and whether Conditional Access targets the privileged roles with a phishing-resistant strength.35 The policy that enforces it is Book 04’s CA003, with its pilot, report-only phase, rings, rollback and exclusions; this book’s part is to make the PIV certificate a method that policy can count on for an administrator, and to keep the evidence that it did. FIDO2 security keys and Windows Hello for Business stay in the same strength for administrators without a PIV card or a reader.

Authority: Mandated for phishing-resistant MFA (M-22-09, above); Microsoft-recommended for the method (phishing-resistant methods for privileged accounts and, for emergency access accounts, a passkey or, where the agency already runs a PKI, certificate-based authentication36). The certificate settings below are the program’s position, risk-based recommended. Applies: all tenants. Environment-dependent: certificate-based authentication and Conditional Access are listed as available in Azure for US Government,37 and the certificate authentication endpoint differs by cloud (Chapter 06).

What makes the PIV certificate count for an administrator, beyond the four settings above:

Setting Rule for administrators Why
The account the certificate binds to The administrator’s separate cloud-only admin account gets its own high-affinity value in certificateUserIds, written by the admin-account request process, not by sync Privileged accounts are cloud-only (Book 04, Chapter 04); a binding on a synced attribute can be changed by whoever administers the sync server (Chapter 06)
The certificate the strength accepts CA003’s custom strength requires, under its advanced options, the PIV authentication certificate’s issuer and policy OID, so a software certificate from the same CA doesn’t qualify A custom strength can require particular issuers or policy OIDs (above)
The authentication binding Multifactor for the PIV authentication policy OID only Single-factor CBA satisfies no built-in strength (above)
Emergency access accounts Excluded from CA003 and every blocking policy, and registered with a method different from the administrators’ own: where administrators use PIV, the emergency accounts use FIDO2 security keys Book 04, Chapter 04 carries the design, on Microsoft’s emergency access guidance

Pilot, report-only, enforcement, rollback and exclusions are CA003’s (Book 04, Chapter 07); the trust store and binding steps they depend on are Chapter 06’s sequence, run for the admin accounts first.

The registration and sign-in evidence, read-only:

#Requires -Modules Microsoft.Graph.Users, Microsoft.Graph.Identity.DirectoryManagement
# Which members of the privileged roles have a certificate binding? (Global Administrator shown; repeat per role)
Connect-MgGraph -Scopes 'RoleManagement.Read.Directory','User.Read.All' -NoWelcome
$role = Get-MgDirectoryRole -Filter "displayName eq 'Global Administrator'"
Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id | ForEach-Object {
    $u = Get-MgUser -UserId $_.Id -Property 'userPrincipalName,onPremisesSyncEnabled,authorizationInfo'
    [pscustomobject]@{ UPN = $u.UserPrincipalName; Synced = [bool]$u.OnPremisesSyncEnabled
        CertificateBindings = ($u.AuthorizationInfo.CertificateUserIds -join '; ') }
}
// Privileged sign-ins in the last 30 days and the method used; every row should show a phishing-resistant method
SigninLogs
| where TimeGenerated > ago(30d)
| where ConditionalAccessPolicies has "CA003-Admins-RequirePhishResistantMFA"
| mv-expand AuthenticationDetails
| extend Method = tostring(AuthenticationDetails.authenticationMethod)
| summarize SignIns = count() by UserPrincipalName, Method

authenticationMethod reads X.509 Certificate for a CBA sign-in. A synced admin account, an admin with no binding and no FIDO2 key, or a privileged sign-in by any other method is a finding.

Control states.

State This page Evidence
Designed The table above, and CA003’s design in Book 04 The admin authentication standard
Configured Trust store, bindings, authentication binding rule, custom strength CBA configuration export; the binding report above
Enforced CA003 On (Book 04) Policy export in the enforcing state; exclusion register
Evidenced A test admin sign-in with the PIV card, and a blocked sign-in with a password and a one-time code The two sign-in log entries
Operated Monthly binding report and sign-in query Report history; findings closed

A finding this page addresses is ready for closure when every applicable state has evidence; the authorizing official or assessor decides.

Evidence checklist

NoteAssessment mapping
  • Microsoft Zero Trust pillar: Identity
  • CISA ZTMM pillar: Identity
  • Depends on: the Federal PKI trust chain and CRLs (Chapter 04); Book 04’s CA003 and its emergency access design; Devices, for card readers on privileged access workstations
  • Attack chain interrupted: Initial Access and Privilege Escalation: a phished password and one-time code replayed against an administrator account

PIV interoperability and federation

Federal PKI trust

Every PIV certificate chains to the Federal Common Policy CA G2 (FCPCAG2), the Federal PKI’s root and the government’s trust anchor. The Federal Bridge CA (currently G4) maps the policies of other PKIs that use comparable but different certificate policies so their certificates can validate to that root; cross-certified CAs are audited annually. Non-Federal Issuers cross-certified with the Bridge issue PIV-Interoperable (PIV-I) cards to business partners who aren’t members of the federal workforce. The Federal PKI Management Authority operates both top-level CAs. FCPCAG2 isn’t in the Microsoft, Mozilla or Apple trust stores by default, so agencies add it to government-managed devices and servers.38 FIPS 201-3 allows agencies that run their own PKI cross-certified with the Bridge or Common Policy to assert their own mapped policies.39 The trust decisions for the program’s own devices are in Chapter 04.

Accepting another agency’s PIV

M-19-17 asks agencies to accept and electronically verify existing, valid PIV credentials issued by other agencies rather than issuing new ones, for logical and physical access where authorized, and to support cross-government federation, with agreements where required.40 SP 800-53 carries the same obligation as IA-8(1): “Accept and electronically verify Personal Identity Verification-compliant credentials from other federal agencies.”41

FIPS 201-3 offers two ways and recommends one. An agency can accept another agency’s card directly, by trusting its issuing CA and validating the certificate; but “the recommended interoperability mechanism for most agencies is to use a federation protocol,” in which the cardholder authenticates with the card at the home agency’s identity provider and the relying party receives an assertion, never the certificate.42 Federation gives the relying party a stable identifier across card reissues, attributes chosen for it, and simpler validation, and the IAL, AAL and FAL must be known to the relying party at the end of the transaction. Many derived credentials can only be verified by their issuer, which makes them better suited to federation too.43 NIST’s PIV federation guideline, SP 800-217, is a final public draft dated November 14, 2024; CSRC lists no final version.44

In Entra terms, direct acceptance would mean putting another agency’s issuing CAs in the agency’s trust store and binding their certificates to guest accounts. The program doesn’t do that (design guidance): the trust store is a blast radius (Chapter 06), the CRL limits apply to every CA added, and the binding would have to be kept current through someone else’s card reissues. It federates instead.

Federation with other agencies and partners

Microsoft documents two workforce-tenant patterns, and they map onto FIPS 201-3’s federation model:

  • Another agency on Entra ID: B2B collaboration with cross-tenant access settings. The guest signs in at their home tenant, with their own PIV through their own CBA. The resource tenant’s inbound trust settings decide whether its Conditional Access trusts the home tenant’s MFA, compliant-device and hybrid-joined claims; by default they aren’t trusted. Organization-specific settings take precedence over defaults, need Entra ID P1 in the tenant that configures them, and every change is logged under the audit category CrossTenantAccessSettings.45 With MFA trust on, a Conditional Access policy can require the phishing-resistant strength of the guest, and CBA counts only when it was done in the home tenant; with trust off, the guest must do MFA in the resource tenant, where CBA isn’t an available method.46 So for PIV-backed guests, turn on inbound MFA trust for that agency’s tenant only, in an organization-specific setting, and require the phishing-resistant strength for guests (design guidance). Collaboration between Azure commercial and Azure Government tenants, which includes GCC High, uses Microsoft cloud settings; B2B direct connect isn’t supported across clouds.47
  • A partner with its own SAML or WS-Fed identity provider: SAML/WS-Fed IdP federation. This is for partners with their own IdP-managed organizational accounts and no Entra presence; a guest account is still created in the resource tenant.48 Authentication strength policies apply only to external users who authenticate with Entra ID; for SAML/WS-Fed users, Conditional Access can use only the Require multifactor authentication grant control.49 Whether the partner’s IdP used a PIV or PIV-I card is therefore something the federation agreement must establish, not something the policy can see (design guidance).

Custom OpenID Connect identity-provider federation is documented for Entra External ID external tenants (customer scenarios), not for guest sign-in to a workforce tenant, whose invited guests use Entra accounts, Microsoft accounts, email one-time passcodes, Google or SAML/WS-Fed federation.50 OIDC still matters in the other direction: the agency’s Entra tenant is the identity provider for its own applications over SAML or OIDC, which is the FIPS 201-3 model with the agency as the home IdP.

A partner person’s credential is not an agency-issued credential. The partner issues it and runs its lifecycle, the agency does not issue it, and PIV scope stays federal employees and contractors; this chapter never treats a partner credential as PIV-equivalent. What the agency decides is which assurance it accepts for each transaction, as Book 03, Chapter 15 sets out.

GSA’s FICAM playbooks

GSA’s IDManagement.gov publishes the government-wide implementation guidance; each playbook says it isn’t official policy and supplements OMB and NIST.515253

GSA FICAM playbooks that apply to this chapter
Playbook What it adds here
Enterprise Single Sign-On Playbook, version 1.3 (March 18, 2026) Federation as sharing and accepting identities managed by other agencies; inter-agency federation through the enterprise SSO service under a CIO-signed federation agreement; prefer OIDC, fall back to SAML for legacy applications54
Cloud Identity Playbook, version 1.3 (March 17, 2026) Cross-agency federation needs a legal agreement and a technical exchange, with a template for required attributes; “A smart card is not automatically a PIV”; Federal PKI members sign a memorandum of agreement with the Federal PKI Policy Authority55
Phishing-Resistant Authenticator Playbook, version 1.1 (February 22, 2024) PIV “remains the primary authenticator for federal users”; derived PIV, PIV-I and FIDO2 as alternatives where the card is impractical56
Certificate-Based Authentication on Microsoft Entra ID Guide, version 2.0 (March 2026) The CBA setup steps for PIV, including the Federal PKI list of PIV issuing CAs; the program departs from its low-affinity binding (Chapter 06)57

The identity lifecycle side is GSA’s Identity Lifecycle Management Playbook, which Book 03, Chapter 09 already follows.

NIST SP 800-63-4 assurance levels as they apply

SP 800-63-4, Digital Identity Guidelines, is final: NIST published it in July 2025, superseding SP 800-63-3, with volumes 63A-4, 63B-4 and 63C-4.58 It measures three things separately:59

SP 800-63-4 assurance levels and the PIV credential
Level What it measures How the PIV credential lands
IAL (identity assurance) How rigorously the person was proofed. IAL3 adds an on-site, attended session with a trained representative and collection of at least one biometric PIV proofing meets IAL3; derived credentials inherit it from the card rather than repeating proofing60
AAL (authentication assurance) Confidence that the person controls the authenticator. AAL2 must offer phishing-resistant options; AAL3 requires a public-key authenticator with a non-exportable private key that provides phishing resistance The PIV authentication key is generated on the card and can’t be exported (above); derived credentials are AAL2 or AAL3, and AAL2-only ones may be used only at AAL261
FAL (federation assurance) Protection of the assertion in a federated transaction: FAL1 against forged assertions, FAL2 also against injected assertions, FAL3 also against identity provider compromise Set per relying party, independent of the credential; a PIV credential may be used at any FAL, and the IAL, AAL and FAL must be known to the relying party62

Microsoft maps Entra methods to AALs and lists smart cards among the multifactor cryptographic hardware that can meet AAL3’s FIPS 140 requirements.63 Record each person’s proofing level and authenticator assurance as attributes, as Book 03, Chapter 09 sets out, so that an assessor can see which users reach which level without reading the card system.

The evidence the ISSO keeps

Three records

  1. A credential inventory. One row per person: the person key, the PIV card’s issuing CA and expiry, the certificate identifier written to certificateUserIds (never the full certificate), each derived credential with its issuer and device, and the proofing and authenticator assurance attributes. The card management system is the source; the inventory is an export, dated, not a hand-kept list. Alongside it, the list of trusted CAs in the Entra trust store with each CRL URL, and the cross-tenant organizations whose MFA claims are trusted.
  2. Issuance and revocation records. Each issuance joined to its sponsorship or HR event; each reissue joined to the binding change; each termination joined to the HR leaver or contractor end date, with the separation-to-block and separation-to-revocation intervals, the revocation record and the CRL that published it, and the invalidation of every derived credential (HR guide, Gate 6).
  3. Authentication strength policy exports. The X.509 certificate method configuration (bindings, required affinity, authentication binding rules, CRL validation), the authentication strength policies with their CBA advanced options, the Conditional Access policies that require them, and the cross-tenant access settings, all exported through Microsoft Graph and dated. The HR workbook’s CBA checks produce most of the configuration half as code.

Federal requirements and evidence

Controls are NIST SP 800-53 Rev. 5 (release 5.2.0), all in the Moderate baseline.6465 Indicators are FedRAMP 20x Key Security Indicators, taken only from this repository’s verified mappings in Book 13, Appendix A and Book 04, Chapter 10. Which record supports which control is the program’s reading (design guidance).

Chapter 09 requirements and evidence
What the record proves Requirement it supports KSI it aligns to Who keeps it
The tenant accepts and electronically verifies PIV: every issuing CA in the trust store, each with a CRL, and Require CRL validation on IA-2(12) Acceptance of PIV Credentials; IA-5(2) Public Key-based Authentication (path validation and revocation data) IA-2(12): no indicator pairing in this repository’s verified mappings. IA-5(2): KSI-IAM-APM, KSI-IAM-ELP, KSI-IAM-SNU, KSI-SVC-ASM Identity team: the trust store export and CRL measurements
Each certificate maps to one person through a high-affinity binding written by the card system IA-5(2) (map the authenticated identity to the account) KSI-IAM-APM, KSI-IAM-ELP, KSI-IAM-SNU, KSI-SVC-ASM Identity team: the X.509 method export; certificateUserIds change history
Only approved trust anchors are trusted: FCPCAG2 distributed to managed devices, the Federal PKI CAs and no others in the Entra trust store SC-17 Public Key Infrastructure Certificates KSI-SVC-ASM Endpoint engineering: the Intune trusted certificate profiles. Identity team: the trust store export (Chapter 08)
Phishing-resistant MFA is required: PIV authentication policy OID mapped to multifactor, and Conditional Access requiring the phishing-resistant strength; M-22-09 IA-2, IA-2(1), IA-2(2) KSI-IAM-APM, as Book 04, Chapter 10 maps it Identity team: authentication strength and Conditional Access exports; sign-in logs showing the strength satisfied
The credential inventory is generated from the card system, not kept by hand IA-5 Authenticator Management; CM-8 for the trusted CAs as components, as the program reads it IA-5: no indicator pairing in this repository’s verified mappings. CM-8: KSI-PIY-GIV Credentialing office and ISSO: the dated inventory export
Cards are issued only after sponsorship, proofing and the investigation step IA-12 Identity Proofing; FIPS 201-3 §2.1–2.2 No indicator pairing in this repository’s verified mappings Credentialing office: issuance records joined to the HR or contractor event
A leaver’s access is blocked and the card and every derived credential revoked within the agreed interval and FIPS 201-3’s 18 hours PS-4 Personnel Termination; AC-2 Account Management; FIPS 201-3 §2.9.4 and §2.10.2 PS-4: no indicator pairing in this repository’s verified mappings. AC-2: KSI-IAM-APM, KSI-IAM-JIT, KSI-IAM-SNU, KSI-IAM-SUS Security, which owns the leaver path: the intervals, the revocation record and the CRL
Users from other agencies are uniquely identified, and their PIV-backed MFA is accepted only from named tenants IA-8 Identification and Authentication (Non-organizational Users); IA-8(1) Acceptance of PIV Credentials from Other Agencies; IA-8(2) Acceptance of External Authenticators No indicator pairing in this repository’s verified mappings Identity team: cross-tenant access settings export; CrossTenantAccessSettings audit events; the federation agreements

Key Security Indicators are FedRAMP 20x indicators for cloud service providers: the agency aligns these records with what Microsoft and its other providers report against them for their own offerings, and doesn’t report KSIs itself (Book 00, Appendix B). HSPD-12, FIPS 201-3, M-19-17 and M-22-09 have no indicator of their own; they’re met through the controls in the same rows.

Where to go next

TipContinue the book

← Previous: Chapter 08 — Lifecycle, Monitoring and Decommissioning · Book index · Next: Appendix A — Cloud PKI and CBA Deployment Checklists →

  1. Department of Homeland Security, “Homeland Security Presidential Directive 12: Policy for a Common Identification Standard for Federal Employees and Contractors,” August 27, 2004, https://www.dhs.gov/homeland-security-presidential-directive-12 (accessed Nov 2, 2026).↩︎

  2. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  3. Office of Management and Budget, M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management, May 21, 2019, §III items 1–3 (PIV as primary means, derived PIV, timely revocation at separation, accepting other agencies’ PIV and cross-government federation) and §IV, “Architecture,” item 5 (federated acceptance of partners’ assertions), https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf (accessed Nov 2, 2026).↩︎

  4. Office of Management and Budget, M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management, May 21, 2019, §III items 1–3 (PIV as primary means, derived PIV, timely revocation at separation, accepting other agencies’ PIV and cross-government federation) and §IV, “Architecture,” item 5 (federated acceptance of partners’ assertions), https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf (accessed Nov 2, 2026).↩︎

  5. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  6. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  7. Microsoft Learn, “Microsoft Entra certificate-based authentication technical concepts” (username binding affinity; authentication binding policy; multifactor certificate authentication; derived credential policy OID example; CBA with authentication strength), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive (accessed Nov 2, 2026).↩︎

  8. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  9. Office of Management and Budget, M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management, May 21, 2019, §III items 1–3 (PIV as primary means, derived PIV, timely revocation at separation, accepting other agencies’ PIV and cross-government federation) and §IV, “Architecture,” item 5 (federated acceptance of partners’ assertions), https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf (accessed Nov 2, 2026).↩︎

  10. Microsoft Learn, “Microsoft Entra certificate-based authentication Certificate Revocation List (CRL)” (one HTTP or HTTPS endpoint per CA, HTTP recommended; 20 MB and 45 MB interactive limits, 10-second download; caching; no OCSP; revoke sessions on revocation; up to 10 CAs; Require CRL validation), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-certificate-revocation-list (accessed Nov 2, 2026).↩︎

  11. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  12. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  13. NIST, SP 800-157, Guidelines for Derived Personal Identity Verification (PIV) Credentials, December 2014 (document history: final, December 19, 2014; no later version listed), https://csrc.nist.gov/pubs/sp/800/157/final (accessed Nov 2, 2026).↩︎

  14. NIST, SP 800-157 Rev. 1 (Final Public Draft), Guidelines for Derived Personal Identity Verification (PIV) Credentials, November 14, 2024 (comments closed January 10, 2025; no final listed), https://csrc.nist.gov/pubs/sp/800/157/r1/fpd (accessed Nov 2, 2026).↩︎

  15. NIST, SP 800-157r1 final public draft, “Introduction” (PKI-based and non-PKI-based derived PIV credentials; attributes from the PIV identity account; issued at AAL2 or AAL3 and IAL3 on proof of possession of a valid PIV card), https://pages.nist.gov/800-157r1/introduction/ (accessed Nov 2, 2026).↩︎

  16. Office of Management and Budget, M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management, May 21, 2019, §III items 1–3 (PIV as primary means, derived PIV, timely revocation at separation, accepting other agencies’ PIV and cross-government federation) and §IV, “Architecture,” item 5 (federated acceptance of partners’ assertions), https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf (accessed Nov 2, 2026).↩︎

  17. GSA and Federal CIO Council, IDManagement.gov, Phishing-Resistant Authenticator Playbook, version 1.1, February 22, 2024, https://www.idmanagement.gov/playbooks/altauthn/ (accessed Nov 2, 2026).↩︎

  18. Office of Management and Budget, M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022, §A “Identity,” Actions 2 (phishing-resistant MFA for agency staff, contractors and partners; discontinue SMS, voice, one-time codes and push for routine self-service access; PIV including Derived PIV as the simplest path; non-PIV phishing-resistant authenticators permitted and centrally managed), https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf (accessed Nov 2, 2026).↩︎

  19. Microsoft Learn, “Use derived credentials with Microsoft Intune” (implementation of SP 800-157; supported platforms; one issuer per tenant; deleting the issuer), https://learn.microsoft.com/intune/device-security/certificates/derived-credentials (accessed Nov 2, 2026).↩︎

  20. Microsoft Learn, “Microsoft Entra certificate-based authentication on iOS and macOS” (on-device certificates and derived PIV; supported browsers and apps; hardware-protected keys), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-mobile-ios (accessed Nov 2, 2026).↩︎

  21. Microsoft Learn, “Microsoft Entra certificate-based authentication on Android devices,” sections “Prerequisites” and “Supported Microsoft Entra use cases” (Operating systems: certificate on-device/derived PIV supported; smart cards and security keys, supported vendors only), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-mobile-android (accessed Nov 9, 2026).↩︎

  22. Microsoft Learn, “Microsoft Entra certificate-based authentication technical concepts” (username binding affinity; authentication binding policy; multifactor certificate authentication; derived credential policy OID example; CBA with authentication strength), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive (accessed Nov 2, 2026).↩︎

  23. NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, release 5.2.0 catalog, controls IA-2(12), IA-5(2), IA-8, IA-8(1), IA-8(2), IA-12 and PS-4, https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; OSCAL catalog https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json (accessed Nov 2, 2026).↩︎

  24. Office of Management and Budget, M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022, §A “Identity,” Actions 2 (phishing-resistant MFA for agency staff, contractors and partners; discontinue SMS, voice, one-time codes and push for routine self-service access; PIV including Derived PIV as the simplest path; non-PIV phishing-resistant authenticators permitted and centrally managed), https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf (accessed Nov 2, 2026).↩︎

  25. Microsoft Learn, “Microsoft Entra certificate-based authentication Certificate Revocation List (CRL)” (one HTTP or HTTPS endpoint per CA, HTTP recommended; 20 MB and 45 MB interactive limits, 10-second download; caching; no OCSP; revoke sessions on revocation; up to 10 CAs; Require CRL validation), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-certificate-revocation-list (accessed Nov 2, 2026).↩︎

  26. GSA, IDManagement.gov, “Certificate-Based Authentication on Microsoft Entra ID Guide,” version 2.0 (reviewed March 17, 2026), Prerequisites and Steps 1, 3 and 4, https://www.idmanagement.gov/implement/cba-azure/ (accessed Nov 2, 2026).↩︎

  27. Microsoft Learn, “Microsoft Entra certificate-based authentication technical concepts” (username binding affinity; authentication binding policy; multifactor certificate authentication; derived credential policy OID example; CBA with authentication strength), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive (accessed Nov 2, 2026).↩︎

  28. Microsoft Learn, “Microsoft Entra certificate-based authentication technical concepts” (username binding affinity; authentication binding policy; multifactor certificate authentication; derived credential policy OID example; CBA with authentication strength), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive (accessed Nov 2, 2026).↩︎

  29. GSA, IDManagement.gov, “Certificate-Based Authentication on Microsoft Entra ID Guide,” version 2.0 (reviewed March 17, 2026), Prerequisites and Steps 1, 3 and 4, https://www.idmanagement.gov/implement/cba-azure/ (accessed Nov 2, 2026).↩︎

  30. Microsoft Learn, “Conditional Access authentication strengths” (built-in strengths and their method combinations), https://learn.microsoft.com/entra/identity/authentication/concept-authentication-strengths (accessed Nov 2, 2026).↩︎

  31. Microsoft Learn, “Authentication methods in Microsoft Entra ID - passkeys (FIDO2),” https://learn.microsoft.com/entra/identity/authentication/concept-authentication-passkeys-fido2; and “Sign in with a FIDO2 security key” (security keys are device-bound passkeys; the private key never leaves the key), https://learn.microsoft.com/entra/identity/authentication/how-to-security-key-sign-in (both accessed Nov 9, 2026).↩︎

  32. Microsoft Learn, “Create and manage custom Conditional Access authentication strengths,” section “Configure advanced options for certificate-based authentication,” https://learn.microsoft.com/entra/identity/authentication/concept-authentication-strength-advanced-options (accessed Nov 2, 2026).↩︎

  33. Office of Management and Budget, M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022, §A “Identity,” Actions 2 (phishing-resistant MFA for agency staff, contractors and partners; discontinue SMS, voice, one-time codes and push for routine self-service access; PIV including Derived PIV as the simplest path; non-PIV phishing-resistant authenticators permitted and centrally managed), https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf (accessed Nov 2, 2026).↩︎

  34. Microsoft Learn, “Meet multifactor authentication requirements of memorandum 22-09,” section “Phishing-resistant methods,” https://learn.microsoft.com/entra/standards/memo-22-09-multi-factor-authentication (accessed Nov 2, 2026).↩︎

  35. Microsoft Learn, “Configure Microsoft Entra for Zero Trust: Protect identities and secrets,” recommendations “Privileged accounts have phishing-resistant methods registered” and “Privileged Microsoft Entra built-in roles are targeted with Conditional Access policies to enforce phishing-resistant methods,” https://learn.microsoft.com/entra/fundamentals/zero-trust-protect-identities (accessed Nov 11, 2026).↩︎

  36. Microsoft Learn, “Manage emergency access accounts in Microsoft Entra ID,” section “Create emergency access accounts” (passkey (FIDO2) recommended; certificate-based authentication if the organization already has a PKI; exclude from Conditional Access policies that block or restrict sign-in), https://learn.microsoft.com/entra/identity/role-based-access-control/security-emergency-access (accessed Nov 11, 2026).↩︎

  37. Microsoft Learn, “Microsoft Entra feature availability” (Azure for US Government: certificate-based authentication and Conditional Access available), https://learn.microsoft.com/entra/identity/authentication/feature-availability (accessed Nov 11, 2026).↩︎

  38. GSA, IDManagement.gov, “Federal Public Key Infrastructure 101” (FCPCAG2 as root and trust anchor; Federal Bridge CA G4; Non-Federal Issuers and PIV-I; FPKI Management Authority; default trust stores), https://www.idmanagement.gov/university/fpki/ (accessed Nov 2, 2026).↩︎

  39. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  40. Office of Management and Budget, M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management, May 21, 2019, §III items 1–3 (PIV as primary means, derived PIV, timely revocation at separation, accepting other agencies’ PIV and cross-government federation) and §IV, “Architecture,” item 5 (federated acceptance of partners’ assertions), https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf (accessed Nov 2, 2026).↩︎

  41. NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, release 5.2.0 catalog, controls IA-2(12), IA-5(2), IA-8, IA-8(1), IA-8(2), IA-12 and PS-4, https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; OSCAL catalog https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json (accessed Nov 2, 2026).↩︎

  42. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  43. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  44. NIST, SP 800-217 (Final Public Draft), Guidelines for Personal Identity Verification (PIV) Federation, November 14, 2024 (comments closed January 10, 2025; no final listed), https://csrc.nist.gov/pubs/sp/800/217/fpd (accessed Nov 2, 2026).↩︎

  45. Microsoft Learn, “Overview: Cross-tenant access with Microsoft Entra External ID” (inbound trust settings; defaults; organizational settings; Microsoft cloud settings; P1 requirement; audit category), https://learn.microsoft.com/entra/external-id/cross-tenant-access-overview (accessed Nov 2, 2026).↩︎

  46. Microsoft Learn, “Authentication and Conditional Access for External ID,” section “Conditional Access for external users” (authentication strength only for external users who authenticate with Entra ID; MFA grant control for SAML/WS-Fed users; Table 1, CBA in the home tenant only), https://learn.microsoft.com/entra/external-id/authentication-conditional-access (accessed Nov 2, 2026).↩︎

  47. Microsoft Learn, “Overview: Cross-tenant access with Microsoft Entra External ID” (inbound trust settings; defaults; organizational settings; Microsoft cloud settings; P1 requirement; audit category), https://learn.microsoft.com/entra/external-id/cross-tenant-access-overview (accessed Nov 2, 2026).↩︎

  48. Microsoft Learn, “SAML/WS-Fed identity provider federation,” section “Key considerations for SAML/WS-Fed federation,” https://learn.microsoft.com/entra/external-id/direct-federation-overview (accessed Nov 2, 2026).↩︎

  49. Microsoft Learn, “Authentication and Conditional Access for External ID,” section “Conditional Access for external users” (authentication strength only for external users who authenticate with Entra ID; MFA grant control for SAML/WS-Fed users; Table 1, CBA in the home tenant only), https://learn.microsoft.com/entra/external-id/authentication-conditional-access (accessed Nov 2, 2026).↩︎

  50. Microsoft Learn, “Supported features in workforce and external tenants,” section “Identity providers and authentication methods”; and “Add OpenID Connect as an external identity provider” (applies to external tenants), https://learn.microsoft.com/entra/external-id/customers/concept-supported-features-customers and https://learn.microsoft.com/entra/external-id/customers/how-to-custom-oidc-federation-customers (accessed Nov 2, 2026).↩︎

  51. Federal CISO Council ICAM Subcommittee and GSA, IDManagement.gov, Enterprise Single Sign-On Playbook, version 1.3, March 18, 2026, Step 5 (federating application access) and Disclaimer, https://www.idmanagement.gov/playbooks/sso/ (accessed Nov 2, 2026).↩︎

  52. GSA, IDManagement.gov, Cloud Identity Playbook, version 1.3, March 17, 2026 (federation across agency domains; Federal PKI trust framework; Disclaimer), https://www.idmanagement.gov/playbooks/cloud/ (accessed Nov 2, 2026).↩︎

  53. GSA and Federal CIO Council, IDManagement.gov, Phishing-Resistant Authenticator Playbook, version 1.1, February 22, 2024, https://www.idmanagement.gov/playbooks/altauthn/ (accessed Nov 2, 2026).↩︎

  54. Federal CISO Council ICAM Subcommittee and GSA, IDManagement.gov, Enterprise Single Sign-On Playbook, version 1.3, March 18, 2026, Step 5 (federating application access) and Disclaimer, https://www.idmanagement.gov/playbooks/sso/ (accessed Nov 2, 2026).↩︎

  55. GSA, IDManagement.gov, Cloud Identity Playbook, version 1.3, March 17, 2026 (federation across agency domains; Federal PKI trust framework; Disclaimer), https://www.idmanagement.gov/playbooks/cloud/ (accessed Nov 2, 2026).↩︎

  56. GSA and Federal CIO Council, IDManagement.gov, Phishing-Resistant Authenticator Playbook, version 1.1, February 22, 2024, https://www.idmanagement.gov/playbooks/altauthn/ (accessed Nov 2, 2026).↩︎

  57. GSA, IDManagement.gov, “Certificate-Based Authentication on Microsoft Entra ID Guide,” version 2.0 (reviewed March 17, 2026), Prerequisites and Steps 1, 3 and 4, https://www.idmanagement.gov/implement/cba-azure/ (accessed Nov 2, 2026).↩︎

  58. NIST, SP 800-63-4, Digital Identity Guidelines, July 2025 (final; supersedes SP 800-63-3; parts SP 800-63A-4, 63B-4 and 63C-4), https://csrc.nist.gov/pubs/sp/800/63/4/final (accessed Nov 2, 2026).↩︎

  59. NIST, SP 800-63-4, Digital Identity Guidelines, base volume, assurance level definitions (IAL1–3, AAL1–3, FAL1–3), https://pages.nist.gov/800-63-4/sp800-63.html (accessed Nov 2, 2026).↩︎

  60. NIST, SP 800-157r1 final public draft, “Introduction” (PKI-based and non-PKI-based derived PIV credentials; attributes from the PIV identity account; issued at AAL2 or AAL3 and IAL3 on proof of possession of a valid PIV card), https://pages.nist.gov/800-157r1/introduction/ (accessed Nov 2, 2026).↩︎

  61. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  62. NIST, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, abstract; §2.1 (control objectives); §2.2 (credentialing requirements: Tier 1 minimum; with no prior investigation, initiation and a completed FBI NCHC before issuance); §2.8 (no more than six years); §2.9.1 (reissuance); §2.9.4 (termination, 18 hours); §2.10–2.10.2 (derived PIV issuance and invalidation); §3.3 (federation as the recommended interoperability mechanism); §4.2.2 and §4.2.2.1 (PIV authentication key and certificate); §5.1–5.2.1 (Common Policy hierarchy, id-fpki-common-authentication, cross-certified agency PKIs); §7.1–7.3 (federation, FAL, benefits); Appendix A.1 (accreditation of issuers), https://csrc.nist.gov/pubs/fips/201-3/final (accessed Nov 2, 2026).↩︎

  63. Microsoft Learn, “NIST authenticator assurance level 3 by using Microsoft Entra ID,” section “FIPS 140 validation,” https://learn.microsoft.com/entra/standards/nist-authenticator-assurance-level-3 (accessed Nov 2, 2026).↩︎

  64. NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, release 5.2.0 catalog, controls IA-2(12), IA-5(2), IA-8, IA-8(1), IA-8(2), IA-12 and PS-4, https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final; OSCAL catalog https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_catalog.json (accessed Nov 2, 2026).↩︎

  65. National Institute of Standards and Technology, SP 800-53B Moderate baseline, release 5.2.0 OSCAL profile, last modified October 22, 2026 (includes AC-2, CM-8, IA-2, IA-2(1), IA-2(2), IA-2(12), IA-5, IA-5(2), IA-8, IA-8(1), IA-8(2), IA-12, PS-4 and SC-17), https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_MODERATE-baseline_profile.json (accessed Nov 2, 2026).↩︎

Back to top