SA-4(10): Use of Approved PIV Products

The sa-4(10): use of approved piv products requirement is a supply chain and architecture constraint disguised as an identity control. It does not ask you to “support PIV.” It asks you to constrain what products you are allowed to buy, integrate, and run when those products implement PIV capability inside your systems. That distinction matters because many environments drift over time: a team adds a new smart card middleware, a reader driver, an identity module in a third-party application, or a managed service that claims PIV support, and suddenly your PIV implementation depends on a component that was never verified against the FIPS 201-approved list.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat SA-4(10) as a repeatable procurement-and-configuration rule: identify the PIV capability boundary, standardize approved components, make exceptions rare and time-bound, and retain evidence that ties each deployed PIV component back to an approved listing. This page gives you requirement-level, audit-ready steps, artifacts, and common pitfalls to avoid, grounded in the control text (NIST SP 800-53 Rev. 5 OSCAL JSON; NIST SP 800-53 Rev. 5).

Regulatory text

Requirement (verbatim): “Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator translation (what you must do):

1. Define what counts as “PIV capability” in your environment. This includes products that issue, read, validate, or authenticate PIV credentials, or that provide the middleware, modules, or services that enable those functions.
2. Ensure every product used for that PIV capability is on the FIPS 201-approved products list. “Works with PIV” is not the same as “approved.”
3. Prohibit or remove non-approved products where they provide PIV capability. If you keep them for non-PIV functions, document the boundary so auditors can see the non-approved component is not in the PIV path.
4. Make it repeatable. Put the check into procurement intake, architecture review, and change management so compliance does not depend on institutional memory.

Citations above are to the control’s source and NIST’s publication context (NIST SP 800-53 Rev. 5 OSCAL JSON; NIST SP 800-53 Rev. 5).

Plain-English interpretation of the requirement

SA-4(10) is a constraint on your technology supply chain for identity verification. If a system implements PIV, you cannot “mix and match” arbitrary readers, card middleware, PKI modules, or identity components unless they are on the approved list for FIPS 201 PIV products. Auditors will typically treat this as an allowlist requirement: approved in, not approved out.

The practical compliance question is: “Show me the list of PIV-capable products you run, and show me how you confirmed each one was FIPS 201-approved.” If you cannot answer both parts with evidence, you will struggle even if PIV appears to function correctly.

Who it applies to (entity and operational context)

This requirement is most relevant when you are:

• Operating federal information systems where PIV is used for authentication or identity verification (NIST SP 800-53 Rev. 5).
• A contractor running systems that handle federal data and implementing PIV capability as part of your security architecture or contractual requirements (NIST SP 800-53 Rev. 5).

Operationally, it applies across:

• Identity and access management (IAM) and workforce authentication flows that rely on PIV.
• Endpoint and physical/virtual access tooling where PIV readers, drivers, middleware, or authentication agents sit on the access path.
• Third-party products and managed services that embed PIV features (for example, a remote access gateway or VDI stack that performs PIV-based auth inside the product).

What you actually need to do (step-by-step)

1) Set the scope boundary for “PIV capability”

Create a short scope statement that answers:

• Which systems use PIV (or are required to)?
• Where PIV is enforced (workstations, VPN, privileged access, cloud console, bastions)?
• Which components participate (cards, readers, middleware, CSP/PKCS components, validation services, connectors)?

Output: “PIV Capability Architecture Boundary” (1–2 pages) referencing the control statement (NIST SP 800-53 Rev. 5 OSCAL JSON).

2) Build an authoritative inventory of PIV-capable products

Inventory at the level auditors can test:

• Product name, publisher, version, deployment location
• Function in the PIV flow (reader, middleware, authentication agent, validation module)
• Owner (team) and lifecycle status (standard, legacy, pending retirement)

If you already maintain a software/hardware inventory, add a “PIV capability” flag and a “FIPS 201 approval reference” field.

Output: PIV Product Inventory (spreadsheet or CMDB view).

3) Verify each product against the FIPS 201-approved products list

For each in-scope product:

• Confirm it is on the approved list for the relevant category.
• Capture proof that shows what you checked, when you checked it, and what matched (product name, model, version family if applicable).

Control intent: “Employ only…products on the…approved products list” means you need more than a reseller quote or marketing datasheet (NIST SP 800-53 Rev. 5 OSCAL JSON).

Output: “FIPS 201 Approval Verification Pack” attached to each inventory line item.

4) Put an enforceable gate in procurement and intake

Update your procurement and third-party intake so teams cannot buy or onboard a non-approved PIV component:

• Add a required question: “Does this product implement PIV capability in our systems?”
• If “yes,” require the approval reference before purchase approval.
• Route to IAM/security architecture for review.

For third parties (including SaaS) that provide embedded PIV functionality, treat the third party’s PIV component as in-scope. If they cannot demonstrate that the PIV component is an approved product, document a compensating design decision (for example, remove PIV from that product’s responsibilities and shift PIV enforcement upstream) or block the acquisition.

Output: Procurement checklist + intake workflow requirement.

5) Bake the requirement into architecture standards and change management

Add a standard such as:

• “All PIV-capable components must be selected from the FIPS 201-approved list.”
• “Changes to PIV components require security architecture review and evidence refresh.”

Then operationalize:

• Change ticket template includes: product, version, PIV function, approval reference, rollback plan.
• CAB or security review verifies the approval reference is attached.

Output: Architecture standard + change template + a sample approved change record.

6) Handle exceptions as time-bound risk decisions

If you have a legacy component that is not approved but currently sits in the PIV path:

• Record it as an exception with business justification.
• Assign an owner, remediation path, and target retirement milestone.
• Require a design that reduces exposure (for example, constrain where it runs, limit to non-privileged use cases) until replaced.

This does not “waive” SA-4(10); it documents governance while you remove the gap.

Output: Exception register entries tied to the inventory.

7) Monitor drift

Your main failure mode is drift: versions change, new endpoints appear, or a third party updates their stack.

• Reconcile PIV inventory against procurement and change records.
• Require evidence refresh when a PIV-related product version changes or when a new deployment is added.

Output: Periodic reconciliation report and updated verification packs.

Required evidence and artifacts to retain

Auditors typically want artifacts that prove both design and operation:

Core artifacts (keep current):

• PIV Capability Architecture Boundary document (ties system PIV flows to components) (NIST SP 800-53 Rev. 5 OSCAL JSON)
• PIV Product Inventory (with owner, version, deployment scope)
• FIPS 201 approval verification evidence per product (screenshots/PDF exports/links captured at time of review)
• Procurement intake checklist showing the approval gate for PIV-capable products
• Change management records for PIV component changes with approval references attached
• Exceptions register entries for any non-conforming components, with planned remediation

Nice-to-have (reduces audit time):

• A single “SA-4(10) control implementation procedure” mapping owners, steps, and recurring evidence artifacts (NIST SP 800-53 Rev. 5 OSCAL JSON).

Daydream can help by turning those artifacts into a repeatable evidence schedule: control owner assignment, request cadences, and a single place to store the “approval verification pack” alongside the inventory entry, so audits do not turn into inbox archaeology.

Common exam/audit questions and hangups

Expect these questions from assessors testing sa-4(10): use of approved piv products requirement:

1. “Show me all products that implement PIV capability in System X.” Hangup: inventory is incomplete or not tagged for PIV.
2. “How do you confirm the product is on the FIPS 201-approved list?” Hangup: relying on vendor attestation without retaining proof of listing.
3. “What prevents a team from buying a non-approved PIV reader/middleware?” Hangup: policy exists, but procurement workflow has no hard gate.
4. “How do you handle upgrades and patches?” Hangup: version changes occur outside security review, breaking traceability.
5. “Do your third parties embed PIV capability?” Hangup: unmanaged SaaS features become part of the PIV chain without review.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Treating “PIV-compatible” as “FIPS 201-approved”	The requirement is an approval-list constraint (NIST SP 800-53 Rev. 5 OSCAL JSON)	Require evidence of inclusion on the approved list for each PIV-capable product
Scoping only card readers	Middleware, agents, and embedded modules can implement PIV functions	Map the full PIV flow and tag all participating components
No operational gate	People will bypass a policy under schedule pressure	Add approval reference checks to procurement and change templates
Evidence stored ad hoc	Evidence gets lost; audit becomes manual reconstruction	Standardize a “verification pack” and store it with the inventory line item
Ignoring third-party embedded PIV	You can end up depending on an unreviewed component	Treat embedded PIV as in-scope; redesign so PIV enforcement happens in an approved layer

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific control. Practically, the risk is assessment failure and loss of authorization posture: if PIV is a required identity mechanism and you cannot show approved-product use, assessors may record a control deficiency against SA-4(10) (NIST SP 800-53 Rev. 5 OSCAL JSON). Operationally, non-approved components also increase the chance of incompatible updates, weak validation paths, or undocumented trust decisions in your authentication chain.

A practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Assign a control owner (IAM lead or security architecture) and a compliance owner (GRC).
• Publish the PIV capability boundary for your highest-impact systems.
• Stand up the PIV Product Inventory with initial population from CMDB, endpoint management, and IAM documentation.
• Add a procurement intake question that flags PIV-capable purchases for security review.

Days 31–60 (prove compliance for what you run)

• Verify each inventoried product against the FIPS 201-approved list and build the verification pack per item.
• Identify non-conforming items, then decide: replace, redesign to remove from PIV path, or document a time-bound exception.
• Update change templates and architecture standards so new PIV components cannot bypass the approval check.

Days 61–90 (make it durable)

• Reconcile inventory to real deployments (sample endpoints, key servers, remote access stack, VDI).
• Run a tabletop audit: have someone outside the IAM team ask the five audit questions above and see if evidence is one click away.
• Automate evidence collection reminders and ownership tracking in Daydream so the inventory, verification packs, and exceptions stay current.

Frequently Asked Questions

Does SA-4(10) apply if we use CAC instead of PIV?

If your environment implements PIV capability within organizational systems, SA-4(10) applies to the products providing that capability (NIST SP 800-53 Rev. 5 OSCAL JSON). If CAC is used as the credential but the system is implementing PIV functions, treat it as in-scope and validate product approval status.

What counts as an “information technology product” here?

Any hardware, software, or integrated component that provides PIV functionality in your systems can fall in scope under the control text (NIST SP 800-53 Rev. 5 OSCAL JSON). In practice, that includes readers, middleware, authentication agents, and embedded PIV modules in third-party platforms.

Do we have to re-check approval status after upgrades?

Yes as an operational matter, because upgrades can change what you have deployed and what you can prove. Make “approval verification refreshed for PIV-related version changes” part of your change requirements tied back to SA-4(10) (NIST SP 800-53 Rev. 5 OSCAL JSON).

Can we accept a vendor letter stating their product is approved?

A vendor letter can support your file, but auditors usually expect you to retain direct proof that the product appears on the FIPS 201-approved list at the time you selected it. Store that proof alongside the inventory entry so it is available during assessment (NIST SP 800-53 Rev. 5 OSCAL JSON).

What if our SaaS provider offers PIV login and we cannot control their components?

Treat the embedded PIV capability as a third-party dependency and require evidence that the PIV component is approved, or redesign so PIV enforcement happens in a layer you control and can verify. Document the decision and keep it with your third-party due diligence file and system boundary record (NIST SP 800-53 Rev. 5 OSCAL JSON).

How do we show “employ only” during an audit without drowning in screenshots?

Use three artifacts: a PIV-scoped inventory, a standardized verification pack per product, and procurement/change records that show the approval gate is consistently applied. Daydream helps by assigning ownership and collecting those artifacts on a schedule so evidence stays audit-ready.