How should teams use PIV cards in a modern identity programme?

Why PIV Cards Belong in a Modern Identity Programme

PIV cards are not just an authentication factor, they are a governance mechanism for high-assurance identity. In practice, they make the strongest sense where an organisation must bind a verified person to both physical entry and logical access, and where phishing-resistant authentication matters more than convenience. The programme question is less about whether cards are “modern” and more about whether their issuance, assurance level, and lifecycle can be kept consistent with the rest of the identity stack.

Teams should treat PIV as part of a broader identity architecture, not as a standalone badge strategy. That means aligning proofing, card issuance, PIN policy, renewal, and revocation with directory state, access policy, and downstream credentials so that a cardholder’s trust level stays coherent even when the authentication method changes.

PIV also works best when the organisation has a clear boundary for where high assurance is required. If a system only needs a low-friction login, forcing card use often creates workarounds. If a workflow involves administrative access, regulated operations, or sensitive facilities, PIV cards can provide the assurance baseline that passcodes and consumer MFA cannot match. For teams designing that boundary, the identity programme should define where PIV is mandatory, where it is optional, and where another control is more appropriate.

How PIV Cards Fit with Derived Credentials and Other Factors

The main design challenge is continuity across form factors. A modern identity programme may use the PIV card as the root of trust, then issue derived credentials to phones, laptops, or application sessions so users are not forced to carry the card for every interaction. The important point is that the derived credential should inherit the same identity assurance, not become a weaker parallel identity.

This is where lifecycle discipline matters. If the card is renewed, suspended, or revoked, teams need to know what happens to any derived credential that was issued from it. If the cardholder leaves, or the proofing event is invalidated, revocation must propagate quickly enough that the derived path does not outlive the original trust. NHIMG’s Identity Security Programme Guide is useful here because it frames identity governance as a programme-level capability rather than a single control.

Physical and logical use also raises policy questions. A card that opens a door may not automatically be the right control for application access unless the assurance level and credential binding are explicit. Teams should decide whether the same proofing event supports both use cases, or whether different relying systems need different policy rules. That decision is often more important than the card technology itself.

For public-sector and highly regulated environments, the operating model usually has to cover issuance authority, proofing evidence, card replacement, lost card handling, and exception handling as part of one end-to-end chain. NHIMG’s Public Sector Identity Security Guide is especially relevant when PIV is tied to government-grade assurance requirements and phishing-resistant access expectations.

What Good Governance Looks Like for PIV in Practice

A mature programme uses PIV cards as one assurance layer inside a controlled identity lifecycle. That means the card issuance event, the identity record, and any derived credentials all trace back to the same authoritative source of truth. It also means card issuance is not treated as an isolated facilities process, because the security outcome depends on access decisions in IAM, PAM, and privileged workflow tooling as much as it does on the card itself.

Identity teams should also pay attention to user experience and operational recovery. If card replacement, lost-card reporting, or help desk recovery is slow, users will pressure teams to create bypasses. Those bypasses are where assurance degrades. NHIMG’s Workforce Identity Security Guide helps connect PIV governance to phishing-resistant authentication, recovery, and session protection for employees and administrators.

When cards are part of a broader NHI and access governance model, the team should also decide how temporary credentials, service access, and break-glass paths are handled so they do not quietly become the real production access path. Even in a human-centric programme, the control objective is consistent assurance and revocation, not just possession of a physical token. NHIMG’s Regulatory and Audit Perspectives section is useful for thinking about evidence, accountability, and lifecycle controls across the wider identity estate.

Practitioner Guidance

What to prioritise: Define where PIV is the required assurance level, then make issuance, renewal, suspension, and revocation follow one shared lifecycle across physical and logical access. If those paths diverge, the card becomes symbolic rather than authoritative.

What to verify: Check that derived credentials, directory records, and access entitlements all update when the PIV status changes. The practical test is whether a revoked card can still support any meaningful access path.

Common mistake: Treating the card as the control and ignoring the surrounding governance. The control is the combination of proofing, binding, lifecycle, and enforcement, not the plastic token itself.

Practitioner takeaway: Use PIV cards when you need durable assurance, but judge the programme by whether identity state, revocation, and downstream access stay aligned after the card has been issued.

Related resources from NHI Mgmt Group

• How should government identity teams expand strong authentication beyond PIV cards without making remote access harder to use?
• How should security teams govern identity access in a modern GRC programme?
• How should security teams use DNS analytics in an identity programme?
• What metrics should security and identity teams use to judge loyalty programme effectiveness?