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

SA-4(10) requires you to allow only FIPS 201-approved products to provide Personal Identity Verification (PIV) capability in your systems. Operationally, that means you must (1) inventory every PIV component in scope, (2) verify each product is on the FIPS 201-approved products list, and (3) block procurement, deployment, and renewals for anything not approved ¹.

Key takeaways:

• Scope “PIV capability” broadly: cards/credentials, middleware, readers, and supporting identity components tied to PIV use cases.
• Build a procurement and architecture gate that checks the FIPS 201-approved products list before purchase and before production deployment.
• Keep audit-ready evidence: product list checks, approvals, exceptions, and an up-to-date system/component inventory mapped to PIV functions.

SA-4(10) sits in the System and Services Acquisition (SA) family because the fastest way to lose control of identity assurance is to buy or integrate the wrong components. If your organization issues, accepts, or relies on PIV credentials, you are expected to constrain the technology stack to products that have been approved for FIPS 201 PIV capability ¹.

For a CCO, GRC lead, or security compliance operator, the practical challenge is rarely the policy statement. It is execution: figuring out where PIV capability exists (including “hidden” integrations), proving that each product is on the approved list at the time you bought and deployed it, and preventing teams or third parties from introducing non-approved alternatives through refresh cycles, emergency purchases, or “temporary” pilots.

This requirement page gives you a runbook you can put into motion immediately: applicability, scoping, step-by-step implementation, evidence to retain, and the audit questions that typically surface. The goal is a control that operates continuously through acquisition and change management, not a one-time certification exercise ².

Regulatory text

Requirement (SA-4(10)): “Employ only information technology products on the FIPS 201-approved products list for Personal Identity Verification (PIV) capability implemented within organizational systems.” ¹

Operator meaning: if any system implements PIV capability, every IT product you rely on for that PIV capability must be selected from the FIPS 201-approved products list. This is an acquisition and integration constraint: you are limiting what can be bought, renewed, installed, and connected when it touches PIV.

What you must be able to show an assessor:

• You know which systems and components provide PIV capability.
• You verified those specific products against the FIPS 201-approved products list.
• You have gates that prevent non-approved products from entering (procurement and technical change control).
• You manage exceptions explicitly, with documented risk acceptance and a path to remediation.

Plain-English interpretation (what SA-4(10) is really testing)

SA-4(10) tests whether your organization treats PIV as a high-assurance identity function that cannot be implemented with “close enough” tools. If teams can swap in a non-approved smart card reader, middleware package, or PIV-related integration without detection, you will struggle to defend the integrity of your identity proofing and authentication chain.

In practice, this control fails in two ways:

1. Unknown sprawl: PIV is used in more places than the security team realizes (physical access integrations, remote access, privileged admin workstations, shared kiosks).
2. Acquisition drift: approved at one point, then replaced during refresh, renewal, or a third-party managed service upgrade without re-checking the approved list.

Who it applies to

Entity types (typical):

• Federal information systems.
• Contractor systems handling federal data, where PIV is part of the required authentication and identity assurance posture ¹.

Operational contexts where SA-4(10) becomes “real”:

• Issuing or managing PIV credentials (or consuming them for authentication).
• Integrating PIV with identity providers, access gateways, PAM tooling, VDI, workstation logon, or secure admin enclaves.
• Any procurement or third-party arrangement where PIV-related components can be selected by someone outside your security engineering team (IT procurement, facilities/physical security, managed service providers).

Scoping note you should document: define what “PIV capability” means in your environment. Keep it concrete: “components that generate, validate, read, middleware-process, or enforce PIV credentials for access decisions.”

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

Step 1: Assign ownership and create a “control card”

Write a one-page control card so this does not live as a policy sentence. Minimum fields:

• Control owner (named role) and backup.
• In-scope systems (or link to the inventory view).
• Trigger events: new purchase, renewal, system change, new integration, incident-driven replacement.
• Required checks and approvers.
• Exception criteria and who can approve exceptions.

This is the operational glue auditors look for when they ask, “How do you know it keeps working?” ¹

Step 2: Build and validate the PIV component inventory

Create an inventory that is specific enough to test compliance. At minimum, track:

• System name and owner.
• PIV function (e.g., “workstation logon,” “remote access,” “door reader integration,” “certificate validation service”).
• Product name, version, vendor/manufacturer, and deployment location.
• Procurement channel (internal procurement, reseller, third party).
• Date last verified against the approved list and who verified.

Practical approach:

• Start from architecture diagrams and IAM/PAM tooling inventories.
• Pull endpoint management catalogs for smart card middleware and reader drivers.
• Ask facilities/physical security for the list of card readers and access control integrations if they intersect with logical access decisions.

Step 3: Define the authoritative “approved list check” procedure

Your procedure should answer three questions clearly:

• Where do you check (the FIPS 201-approved products list reference your team uses)?
• What is the match logic (product family, exact model, version constraints, validated configuration notes)?
• When do you check (before purchase, before install, before production cutover, and during renewal/major upgrade cycles)?

Store a screenshot or exported record of the list entry at the time of approval. If the list changes later, you need to show what you relied on when you made the decision.

Step 4: Put gates in procurement and change management

You need two enforcement points; one alone is fragile.

Procurement gate (pre-purchase / pre-renewal)

• Add a required security compliance field in purchase requests: “PIV capability component: Yes/No.”
• If “Yes,” require attachment of the approved-list evidence and security approval.
• If a third party purchases on your behalf, add contract language and an intake requirement: they must provide proof the product is on the approved list before deployment.

Change management gate (pre-deploy)

• Add a standard change control checklist item: “Introduces/modifies PIV capability components?”
• Require security sign-off with the approved-list evidence before the change can be scheduled.

This is where many programs fail: they only check at procurement, then engineering swaps components later through a change window.

Step 5: Manage exceptions with discipline (rare, time-bounded, documented)

SA-4(10) is written as “employ only,” so exceptions should be rare and treated as risk decisions. Create an exception template with:

• Business justification and impacted systems.
• Why no approved product works (technical constraint, interoperability issue).
• Compensating controls (additional monitoring, limited scope, restricted users).
• Sunset criteria: what event ends the exception (approved product available, contract renewal, system replacement).
• Risk acceptance sign-off by an accountable executive.

Track exceptions like findings. If you cannot show a plan to eliminate exceptions, auditors will treat them as a persistent control failure.

Step 6: Run recurring control health checks

At a practical minimum, do periodic checks that reconcile:

• Your PIV component inventory vs. what is actually deployed (endpoint scans, software catalogs, configuration management).
• New purchase orders and renewals vs. approvals on file.
• Changes tagged as PIV-related vs. the evidence bundle.

Daydream tip (where it fits naturally): teams often lose time chasing evidence across procurement, ITSM, and architecture tools. Daydream can be the single workflow to intake PIV component requests, attach approved-list proof, route approvals, and produce an audit-ready evidence bundle mapped to SA-4(10).

Required evidence and artifacts to retain

Keep evidence tied to a specific decision, not just a general policy.

Minimum evidence bundle (recommended):

• SA-4(10) control card (owner, triggers, steps, exception rules).
• PIV component inventory (current as of last review).
• For each in-scope product:
  • Approved-list proof (capture of the entry, date-stamped).
  • Approval record (ticket, email approval, GRC workflow approval).
  • Deployment record (change ticket ID, implementation notes, rollout date).
• Procurement artifacts:
  • Purchase request with PIV flag and approval attachment.
  • Renewal approvals for PIV-related maintenance/support contracts.
• Exception register:
  • Approved exception forms, compensating controls, and closure evidence.

Retention: store evidence in a system that preserves timestamps and approver identity. If you rely on chat approvals, you will have trouble proving control operation later.

Common exam/audit questions and hangups

Expect these questions and prepare concise answers with links to artifacts:

1. “Show me your FIPS 201-approved products verification for each PIV component.”
   Hangup: teams show a policy statement, not per-product proofs.

2. “How do you prevent a non-approved component from being introduced by a third party or through an upgrade?”
   Hangup: no procurement gate for third-party purchasing; no change control trigger.

3. “Define what you mean by ‘PIV capability’ and show your system boundary.”
   Hangup: scope creep or vague scope; inventory not mapped to PIV functions.

4. “Who owns SA-4(10) and how do you know it is operating?”
   Hangup: unclear ownership, no review cadence, no health check record ¹.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Avoidance
Treating SA-4(10) as a procurement-only control	Components change after purchase	Add a change management gate tied to PIV scope
Inventory lists “PIV system” but not components	You cannot verify product-by-product approval	Inventory at component level with product/version
Relying on vendor attestations without internal verification	Attestation may not match exact model/version	Capture approved-list evidence yourself
Exceptions that never close	Becomes a permanent control gap	Require sunset criteria and track like findings
Facilities/physical security left out	PIV-related readers/integrations get missed	Include them in scoping and inventory interviews

Enforcement context and risk implications

No public enforcement cases were provided in the source material for SA-4(10). Your risk posture still matters because PIV is an identity assurance mechanism; a weak or non-approved component can degrade authentication integrity, complicate incident response, and create contract noncompliance exposure in federal and contractor environments ².

From an oversight standpoint, assessors typically treat this as a “show me” control: either your product stack is approved and provable, or it is not. Ambiguity in scope, missing proofs, or uncontrolled third-party changes are what drive findings.

A practical 30/60/90-day execution plan

First 30 days (stabilize and stop new drift)

• Name the SA-4(10) owner and publish the control card.
• Add the procurement intake question: “Does this purchase support PIV capability?”
• Add a change management checkbox for PIV-impacting changes.
• Start an initial PIV component inventory for the highest-risk systems (remote access, privileged access, workstation logon).

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

• Complete inventory coverage for all systems in scope.
• Verify each component against the FIPS 201-approved products list and capture evidence per product.
• Open remediation items for any non-approved components; document temporary exceptions only if needed and time-bound.
• Update third-party contract templates or onboarding checklists to require approved-list proof for PIV-related purchases.

Days 61–90 (make it durable)

• Formalize recurring health checks that reconcile inventory, procurement, and changes.
• Train procurement, ITSM, and architecture review boards on the PIV gates and the evidence they must collect.
• Run a mock audit: pick a system, trace every PIV component from inventory to approved-list proof to deployment ticket.
• If you use Daydream, configure an intake workflow and evidence bundle output so each request produces audit-ready artifacts without manual chasing.

Frequently Asked Questions

Does SA-4(10) apply if we only “accept” PIV for login and don’t issue cards?

Yes, if your systems implement PIV capability in any form, you must ensure the products providing that capability are on the FIPS 201-approved products list ¹. Scope it to the components that read/validate/enforce PIV-based authentication.

What counts as a “product” for this requirement?

Treat any hardware, software, or service component that enables PIV credential use as in scope, then verify it product-by-product against the approved list ¹. If you cannot map a component to an approved entry, flag it for remediation or exception review.

How do we operationalize this with third parties who manage parts of our environment?

Put the requirement in contracts and in your onboarding controls: third parties must provide proof of approved-list status before they deploy PIV-related components. Back it with your own change-management gate so upgrades cannot bypass review.

What evidence do auditors usually reject?

Generic policy statements, architecture diagrams without product identifiers, and vendor marketing claims. Provide per-product approved-list proof plus the approval and deployment records that show the component in production was reviewed.

We have an existing non-approved component. Are we automatically noncompliant?

You have a gap against SA-4(10) until it is replaced or covered by an approved exception with a defined remediation path. Document the decision, compensating controls, and the plan to migrate to an approved product ¹.

How do we keep this from becoming a one-time checklist exercise?

Tie the control to trigger events (purchase, renewal, change) and run periodic reconciliations between inventory, procurement, and change tickets. The evidence should show repeated operation over time, not a single snapshot ¹.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5